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

[topping]

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

[jbonofre]

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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

[Tuomas Kiviaho]

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

[topping]

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.

[topping]

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

[Tuomas Kiviaho]

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