Bundles parameter of features-maven-plugin:generate-features-xml

[Brian Topping <to...@codehaus.org>]

Hi all, hope everyone is doing well.  Happy spring to those of you in the northern hemisphere!

I'm just coming out of hibernation myself and looking at the features-maven-plugin and the generate-feature-xml goal in particular.  The main plugin page links to http://karaf.apache.org/manual/2.2.5/developers-guide/features-maven-plugin-generate.html, but it doesn't appear to to be quite accurate, for instance the goal in the example is shown as "generate" when the page that linked to this one said the page non-deprecated goal was "generate-features-xml".

Muddling through it, I see a lot of references to the "bundles" parameter around the net, but it never seems to get explained anywhere.  It appears to point to a properties file, but when I look at the code, it's just a list of artifacts in the form "g/a/v/type".  It was confusing because I've never seen properties files that are not "key=value" before.

I'm assuming that the file is a list of bundles that are not provided as dependencies in the POM.

What I'm guessing is that this is really all very irrelevant to what I am trying to do, which is cause Karaf to load a wrapped jar (postgresql to be specific).  It appears that is not possible because if the bundle metadata is not available, the jar is not added.  It might be useful instead to have such a jar added to the features as a "wrap:mvn:" protocol artifact.

$0.02...

Cheers, Brian

Re: Bundles parameter of features-maven-plugin:generate-features-xml

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Brian,

thanks for the hint. I will update the documentation.

Regards
JB

On 04/04/2012 08:47 PM, Brian Topping wrote:
> Hi all, hope everyone is doing well.  Happy spring to those of you in the northern hemisphere!
>
> I'm just coming out of hibernation myself and looking at the features-maven-plugin and the generate-feature-xml goal in particular.  The main plugin page links to http://karaf.apache.org/manual/2.2.5/developers-guide/features-maven-plugin-generate.html, but it doesn't appear to to be quite accurate, for instance the goal in the example is shown as "generate" when the page that linked to this one said the page non-deprecated goal was "generate-features-xml".
>
> Muddling through it, I see a lot of references to the "bundles" parameter around the net, but it never seems to get explained anywhere.  It appears to point to a properties file, but when I look at the code, it's just a list of artifacts in the form "g/a/v/type".  It was confusing because I've never seen properties files that are not "key=value" before.
>
> I'm assuming that the file is a list of bundles that are not provided as dependencies in the POM.
>
> What I'm guessing is that this is really all very irrelevant to what I am trying to do, which is cause Karaf to load a wrapped jar (postgresql to be specific).  It appears that is not possible because if the bundle metadata is not available, the jar is not added.  It might be useful instead to have such a jar added to the features as a "wrap:mvn:" protocol artifact.
>
> $0.02...
>
> Cheers, Brian

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Bundles parameter of features-maven-plugin:generate-features-xml

[Brian Topping <to...@codehaus.org>]

Ok, thanks guys!  :-)

On Apr 5, 2012, at 4:21 AM, Tuomas Kiviaho wrote:

> Hello all,
> 
> 
> Brian Topping wrote
>> 
>> What I'm guessing is that this is really all very irrelevant to what I am
>> trying to do, which is cause Karaf to load a wrapped jar (postgresql to be
>> specific).  It appears that is not possible because if the bundle metadata
>> is not available, the jar is not added.  It might be useful instead to
>> have such a jar added to the features as a "wrap:mvn:" protocol artifact.
>> 
> 
> I noticed the same thing while creating a patch for reference: protocol
> which would be handy with M2E's ability of resolving artifacts from Eclipse
> workspace prior they even reach the mvn: protocols visibility. But that's
> another story soon to be continued at JIRA
> 
> The code requires manifest in order to determine whether or not to use
> wrapping but I think that the trunk already contains a fix for this case so
> you might want to try out 3.0.0-SNAPSHOT. Artifact has to be a jar file for
> this to work and I don't think that Pax URL Wrap would even accept other
> than jars.
> 
> €0.02...
> 
> --
> Tuomas
> 
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Bundles-parameter-of-features-maven-plugin-generate-features-xml-tp3885138p3886583.html
> Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Bundles parameter of features-maven-plugin:generate-features-xml

[Tuomas Kiviaho <tu...@iki.fi>]

Hello again,

I am using the maven plugin and features service alone without other parts
of Karaf so what I'm saying here is purely from observational perspective. I
stopped using 2.x in the beginning because I didn't know how to override
config.properties that by default included only system packages from
jre-1.5. 


Brian Topping wrote
> 
> 2) Something that became more apparent is that test scope dependencies are
> not filtered out of the feature generation for either version of the
> plugin. Is this intentional? How does one generate a feature.xml without
> the test dependencies?
> 
The dependency resolution on 3.x relies on sonatype/eclipse aether instead
of maven plugins capability of delivering dependenciens as artifacts so
there is no direct relation to how maven handles dependencies (exclusion for
instance). The only way I could produce something useful was to turn off
transitive dependencies, because I do not understand the logic behind
different scope and type (bundle/jar) combinations. This way I am able to
leave out test scope dependencies that are not bundles (scope test: type
jar=excluded, type bundle=included). Validation seems to have a bit
different logic on how to handle dependencies and I already wrote my
observation on that couple of threads ago.

--
Tuomas

--
View this message in context: http://karaf.922171.n3.nabble.com/Bundles-parameter-of-features-maven-plugin-generate-features-xml-tp3885138p3896255.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Bundles parameter of features-maven-plugin:generate-features-xml

[Brian Topping <to...@codehaus.org>]

Hi guys,

On Apr 5, 2012, at 4:21 AM, Tuomas Kiviaho wrote:

> The code requires manifest in order to determine whether or not to use
> wrapping but I think that the trunk already contains a fix for this case so
> you might want to try out 3.0.0-SNAPSHOT. Artifact has to be a jar file for
> this to work and I don't think that Pax URL Wrap would even accept other
> than jars.


In trying o.a.k.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT it seems like I'm having a different set of questions:

1) While 3.0.0-SNAP wraps the jars that don't have bundle metadata, on the other hand, it generates a monolithic feature for all of the dependencies.  Has something changed in how it's intended to be run? In other words, if the intended use of the tool is now as a part of each bundle project as opposed to a single features generation project, then it would make sense to create a monolithic feature descriptor like that.  If so, my concern would be the number of feature URLs that would need to be added to the container.
2) Something that became more apparent is that test scope dependencies are not filtered out of the feature generation for either version of the plugin. Is this intentional? How does one generate a feature.xml without the test dependencies?
3) The older version of the plugin used to care about the reference to the kernel, and when it came across a dependency that was already a part of a kernel feature, it would just reference the feature. This seemed to be the most logical thing to do.
4) Related to (3), it seems like I must be missing something WRT the Mojo <inputFile> configuration parameter. Does providing some kind of base feature.xml alter the behavior significantly that these previous questions are completely irrelevant?

I'm going to start single stepping more through the tool to see if I can figure this out.  Jean-Baptiste has a great blog entry about how to use the tool and Jamie Goodyear talked about it some as well, but it all just seems so in flux that I'm starting to wonder if anyone really uses the tool for production yet.  That's not a poke by any means, I just want to make sure my expectations are aligned with the capabilities.  Input here is also welcome.

Thanks!!

Brian

Re: Bundles parameter of features-maven-plugin:generate-features-xml

[Tuomas Kiviaho <tu...@iki.fi>]

Hello all,


Brian Topping wrote
> 
> What I'm guessing is that this is really all very irrelevant to what I am
> trying to do, which is cause Karaf to load a wrapped jar (postgresql to be
> specific).  It appears that is not possible because if the bundle metadata
> is not available, the jar is not added.  It might be useful instead to
> have such a jar added to the features as a "wrap:mvn:" protocol artifact.
> 

I noticed the same thing while creating a patch for reference: protocol
which would be handy with M2E's ability of resolving artifacts from Eclipse
workspace prior they even reach the mvn: protocols visibility. But that's
another story soon to be continued at JIRA
 
The code requires manifest in order to determine whether or not to use
wrapping but I think that the trunk already contains a fix for this case so
you might want to try out 3.0.0-SNAPSHOT. Artifact has to be a jar file for
this to work and I don't think that Pax URL Wrap would even accept other
than jars.

€0.02...

--
Tuomas

--
View this message in context: http://karaf.922171.n3.nabble.com/Bundles-parameter-of-features-maven-plugin-generate-features-xml-tp3885138p3886583.html
Sent from the Karaf - User mailing list archive at Nabble.com.