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. > > >
