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.
