I have very little experience with OSGi (I toyed with it at home when we discussed the introduction of NARs several years ago but that's about it). But I have quite a lot of knowledge about NARs, so I thought I'd point out the key features/design points. OSGi may or may not cover all of these concepts, but if we are thinking about OSGi as a possible alternative (or a parallel), I think it's good to go ahead and call out these concepts. NARs map directly to a Java ClassLoader. Whatever your NAR depends on in its pom is what will be loaded into the Java ClassLoader. This makes understanding ClassLoading issues much easier, I think. A NAR can declare a "Parent NAR." That means that the parent of its ClassLoader will be the ClassLoader of the parent NAR. NARs can also provide a 'native' folder that houses native libraries. This provides native library isolation as well as class loading isolation. You are able to define a Controller Service interface in a 'service-api' nar and then have that NAR be the parent of say my-processor-nar and my-service-nar. The Processor can then call methods in the Controller Service via the interface. Even though the implementation lives in my-service-nar, we can cross that NAR boundary safely since we only interact with the interface (which is defined in the common parent).
> Date: Sun, 14 Dec 2014 18:44:05 -0500 > Subject: Re: nar plugin > From: [email protected] > To: [email protected] > > I wouldn't reject Maven Central off-hand. > > And I wouldn't reject keeping your own maven plugin and packaging, even if > it's a nearly complete fork of the maven-war-plugin. > > I think that Maven's handling of 'packaging' and such is less than delux, > and leads in this direction. You'd like to be able to take advantage of the > underlying function of the war plugin (or the assembly plugin) and still > get DRY by avoiding having your devs need to copy a complex assembly > descriptor or do something funny-looking with the war plugin, but I don't > know a way. So if you want a nice, clean, pom for 'build me a NiFi plugin', > you end up, I suspect, with .. a maven plugin. > > I've recently stuck my toes into the OSGi waters at work; I have a theory > of how to have an OSGi system while still cleaving closely to the Maven > dependency universe so as to avoid ending up adrift in OBR. The theory is > neither completely worked out nor proven in production, but I could write > it up such as it is. I'm still digesting some ideas from the Felix user > list. > > Basically, I think of OSGi as a generalization of 'war', and then I am > trying to work out a low-labor way to keep track of all the dependencies. > > > On Sun, Dec 14, 2014 at 6:30 PM, Tony Kurc <[email protected]> wrote: > > > there seem to be plenty of wars which include dependencies in > > repository.apache.org > > > > On Sun, Dec 14, 2014 at 5:59 PM, Sean Busbey <[email protected]> wrote: > > > > > > On Dec 14, 2014 4:25 PM, "Joe Witt" <[email protected]> wrote: > > > > > > > > OSGi was the most obvious choice at the time but we stayed away due to > > > the > > > > tooling/cost/benefit. > > > > > > > > > > Might be worth revisiting. I know the specter of OSGi is raised every > > time > > > classpath woes surface in Hadoop-land. > > > > > > > Our simple goal was for those building extensions to easily produce > > > bundles > > > > of their code and associated dependencies. > > > > > > > > Building uber jars was generally considered non-desirable because we > > did > > > > not want to change the structure of the extension or dependent jars. > > > > > > > > > > +1 for continuing to avoid uber jars. > > > > > > > The assembly plugin might in fact be totally sufficient for our > > purposes. > > > > It requires some extra steps for the client but those are probably > > > > completely automated by maven archetypes. > > > > > > > > > > Reworking things so that nar becomes a kind of assembly is an interesting > > > idea. Do we have docs on the expectations the runtime has for a nar? > > > > > > > In any event we recognize the current nar concept is problematic > > because > > > > nobody is going to want us publishing nar artifact bundles to maven > > > repos. > > > > So we're looking at what we should do. > > > > > > > > > > I don't see why publishing nars would be a problem. Other projects > > publish > > > tarballs (source and binary) and things go well. > > > > >
