|
NetKernel News Volume 4 Issue 20
August 16th 2013
Repository Updates
No updates this week.
Dynamic Introspected Maven Server
I think Jeremy Deane was the first to suggest a NetKernel maven repository, way back in the NK3 days. Today, in a world of diverging numbers of build and CI tool sets, the Maven repository structure has become the de facto standard Java build repository format. So its about time we did something to make NetKernel accessible to these tools.
The challenge has always been that NetKernel is self-hosting - we actually use NetKernel to build NetKernel and have our own in-house CI system (something we call "Apposite Master"). So publishing a static maven repository off our definitive builds was possible but would be fiddly and would mean we'd have to introduce a whole new level of release management to make sure any maven repo was actually stuff that really had gone into the NK builds and/or apposite repos. So the idea kind of got lost in the long grass.
Step forward Mr Brian Sletten with an elegant idea: What if we simply created a NetKernel module that dynamically introspected an NK instance to create its own Maven repository server?
What a great idea! So, that's what we've done...
The concept is that you deploy a NK Maven repository module in an NK instance so that your CI/Build tooling can build all your NK modules against a Maven repository of core NetKernel libraries that is dynamically conjured from the running instance of NetKernel. (NetKernel becomes the server of its own innards.)
We're pretty sure the Maven repository is well-formed and it has successfully been used to build projects with maven and the SBT build system, but for the moment we'll wait for some feedback and call this a "beta release". Once we're sure we've got it right we'll release it as an installable package via Apposite.
Here's the download link for the Beta 1 module...
urn.org.netkernel.introspect.maven-20130816-b1.jar
Here's a very basic maven test project to try - expand it and type "maven test" to see it use your localhost NK maven repo.
Feedback
Please let us know how you get on. We'd really like to know what build/CI system you're using and if this solution fits well. Once we're sure this is suitable/stable we'll make an official release as a package in the apposite repos.
Server Details
Finally, the documentation explains in detail how it all works...
Dynamic Maven Server
The dynamic Maven server provides a maven repository comprising the core NetKernel system libraries. The following parts of NetKernel are dynamically introspected and logically mapped into a maven repository REST structure.
- [ install ] / lib / *.jar - the core NetKernel foundation libraries including the NetKernel kernel, kernel API, layer0, standard module and cache.
- [ install ] / modules / urn.org.netkernel.*.jar - modules provided as part of the NKEE/NKSE installation which export a classpath.
Important Requirement
The Maven server will only introspectively discover jarred libraries and modules. It is therefore essential that if you are setting up a NetKernel as your maven repository server that when you install it, you do *not* choose the "expand jarred libraries" option in the installer.
Interface
The Maven repository runs on the Front-End-Fulcrum server at:
http://localhost:8080/netkernel-maven/
To use a repository with a CI or remote build system then make sure to replace "localhost" with the hostname of your NetKernel instance.
Core Libraries
The core libraries (discovered in lib/ ) can be found on the following logical maven path...
http://localhost:8080/netkernel-maven/urn/com/ten60/core/
Core libraries belong to the urn.com.ten60.core group. Each maven library artifact is named with a short name derived from the name of the introspected jar.
For example...
lib / urn.com.ten60.core.module.standard-x.x.x.jar
Appears in the maven repository as...
group: urn.com.ten60.core artifactId: module.standard version: x.x.x
Module Libraries
System modules that export a classpath can be found on the following path...
http://localhost:8080/netkernel-maven/urn/org/netkernel/
Module libraries belong to the urn.org.netkernel group. A maven module library artifact is named with a short name derived from the shipped jar.
For example...
modules / urn.org.netkernel.lang.groovy-x.x.x.jar
Appears in the maven repository as...
group: urn.org.netkernel artifactId: lang.groovy version: x.x.x
Please note, only jarred modules that export a classpath are considered for inclusion in the logical maven repository - since if a module doesn't export a classpath there would be no point attempting to build against it.
Expanded Module Jars
If a module contains jars in a lib/ directory then these are considered to be dependencies and mapped into the special group urn.org.netkernel.expanded.lib in the maven repository - the expanded lib jars are uniquely identified with the version number of the module from which they are exported. They can be found on the following path...
http://localhost:8080/netkernel-maven/urn/org/netkernel/expanded/lib/
Please note that if you build against a module that has expanded lib jars then these will be automatically included as classpath dependencies.
Dynamic Introspection
The Maven repository is a logical constuct that is created by transforming a "discovered library resource" that is provided by an accessor that actively introspects a live system. Since this resource is in the ROC domain it is cached and the logical maven repository resources are also cached.
Whenever updates to the NetKernel system are made (via apposite) then new libraries will be automatically discovered and immediately appear in the logical maven repository.
Acknowledgements
The idea of a dynamically introspected maven repository was first proposed by Brian Sletten. Both Brian and Randy Kahle provided feedback and testing during development.
RESTFest KeyNote: REST is just the beginning
Its great that Brian is getting the recognition he deserves. He's been announced as the keynote speaker at the upcoming RESTFest conference...
Keynote: REST is Just the Beginning
Deciding to build systems with REST isn't an endpoint. It isn't even really a goal. It is means to an end and a doorway to resource-oriented thinking. Hypermedia and Uniform Interfaces give us loosely-coupled and predictable systems but push the complexity of data integration to the client. The economic cost of integrating multiple sources remains high. Thin resource abstractions end at the HTTP boundary.
What are some patterns that emerge from thinking in resources? How can we reduce the economic cost of integration? What would a resource-oriented computing environment look like? This talk will be a quick journey through some next level thinking about REST, the Semantic Web, Linked Data and a resource-oriented software platform.
Hmmm, a resource-oriented software platform, I wonder what that could be?
NetKernel Architects Group
We were recently joined by Tom Mueck as a member of the team. Tom's job is to sort out our business development, improve our visibility and generally drive the next phase of the NetKernel story. He's an MBA, but lets not hold that against him - he did after all independently discover NetKernel and grok the potential of ROC.
I guess over time I'll be introducing Tom to some of you directly. However in the mean time, Tom is starting to breathe life into the entirely neglected NetKernel Architects Group on Linked-In. If you're not a member please consider joining to connect with like-minded ROC professionals. Our hope is that this group grows to be a strong professional network (it is absolutely not a direct marketing channel).
Have a great weekend. Enjoy the summer.
Comments
Please feel free to comment on the NetKernel Forum
Follow on Twitter:
@pjr1060 for day-to-day NK/ROC updates
@netkernel for announcements
@tab1060 for the hard-core stuff
To subscribe for news and alerts
Join the NetKernel Portal to get news, announcements and extra features.