Hi,
On 12/15/14 12:44 AM, Benson Margulies wrote:
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.
If it fit the needs of the project better than other ways so of
course..go for it...I can offer my help.....
BTW: Something about the descriptor comes into my mind. I'm not sure if
this could be solution. Just define an complex descriptor and use it as
a remote-resource or as a predefined descriptor (works in
maven-assembly-plugin if it's the right choice). So only once you have
to write up such a complex descriptor and all other use it...but it
might not that comfortable in comparsion to a full fledged 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.
Yes that's absolutely true...
