You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Benjamin Reed <ra...@opennms.org> on 2012/05/29 23:33:21 UTC
karaf-maven-plugin and feature dependencies
I'm trying to figure out the best way to build a set of features.xml
files automatically in a multi-pom project.
I have things *almost* working using karaf-maven-plugin + inputFile
filtering, but I'm running into one last issue. Here is how the project
is set up:
here's the org.opennms.features.topology.api features.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0"
name="OpenNMS Topology APIs">
<feature description="OpenNMS Topology APIs"
version="1.11.1-SNAPSHOT" name="org.opennms.features.topology.api">
<details>APIs for topology manipulation and display.</details>
<bundle>mvn:org.opennms.features.topology/org.opennms.features.topology.api/1.11.1-SNAPSHOT</bundle>
<bundle>mvn:com.vaadin/vaadin/6.7.3</bundle>
<bundle>wrap:mvn:javax.servlet/servlet-api/2.5</bundle>
</feature>
</features>
In another project (org.opennms.features.topology.app) I have to depend
on the API to be able to compile:
---(pom.xml snip!)---
<dependency>
<groupId>org.opennms.features.topology</groupId>
<artifactId>org.opennms.features.topology.api</artifactId>
<version>${project.version}</version>
</dependency>
---(pom.xml snip!)---
...and then I use features-generate-descriptor to create a descriptor:
---(pom.xml snip!)---
<plugin>
<groupId>org.apache.karaf.tooling</groupId>
<artifactId>karaf-maven-plugin</artifactId>
<version>3.0.0-SNAPSHOT</version>
<extensions>true</extensions>
<executions>
<execution>
<id>generate</id>
<phase>generate-resources</phase>
<goals>
<goal>features-generate-descriptor</goal>
</goals>
<configuration>
<inputFile>src/main/features/features.xml.in</inputFile>
<outputFile>target/features.xml</outputFile>
<aggregateFeatures>true</aggregateFeatures>
</configuration>
</execution>
</executions>
</plugin>
---(pom.xml snip!)---
I use an inputFile so that org.opennms.features.topology.app can have a
"feature" dependency on the API:
---(features.xml.in snip!)---
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0"
name="OpenNMS Topology Application">
<feature name="org.opennms.features.topology.app"
version="${project.version}" description="OpenNMS Topology Application">
<details>The main Vaadin-based OpenNMS topology
application.</details>
<feature
version="${project.version}">org.opennms.features.topology.api</feature>
<bundle>mvn:${project.groupId}/${project.artifactId}/${project.version}</bundle>
</feature>
</features>
---(features.xml.in snip!)---
...but the resultant feature ends up containing both the api "feature"
and the mvn: dependency sniffed from the pom.
---(features.xml snip!)---
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0"
name="OpenNMS Topology Application">
<feature description="OpenNMS Topology Application"
version="1.11.1-SNAPSHOT" name="org.opennms.features.topology.app">
<details>The main Vaadin-based OpenNMS topology
application.</details>
<feature
version="1.11.1-SNAPSHOT">org.opennms.features.topology.api</feature>
<bundle>mvn:org.opennms.features.topology/org.opennms.features.topology.app/1.11.1-SNAPSHOT</bundle>
<bundle>mvn:org.opennms.features.topology/org.opennms.features.topology.api/1.11.1-SNAPSHOT</bundle>
<bundle>mvn:org.ops4j.pax.vaadin/service/0.1.0-SNAPSHOT</bundle>
<bundle>wrap:mvn:com.google.gwt/gwt-user/2.3.0</bundle>
<bundle>wrap:mvn:net.sf.jung/jung-api/2.0.1</bundle>
<bundle>wrap:mvn:net.sourceforge.collections/collections-generic/4.01</bundle>
<bundle>wrap:mvn:net.sf.jung/jung-graph-impl/2.0.1</bundle>
<bundle>wrap:mvn:net.sf.jung/jung-algorithms/2.0.1</bundle>
<bundle>wrap:mvn:colt/colt/1.2.0</bundle>
<bundle>wrap:mvn:concurrent/concurrent/1.3.4</bundle>
<bundle>wrap:mvn:net.sf.jung/jung-visualization/2.0.1</bundle>
</feature>
<feature description="OpenNMS Topology APIs"
version="1.11.1-SNAPSHOT" name="org.opennms.features.topology.api">
<details>APIs for topology manipulation and display.</details>
<bundle>mvn:org.opennms.features.topology/org.opennms.features.topology.api/1.11.1-SNAPSHOT</bundle>
<bundle>mvn:com.vaadin/vaadin/6.7.3</bundle>
<bundle>wrap:mvn:javax.servlet/servlet-api/2.5</bundle>
</feature>
</features>
---(features.xml snip!)---
Is there any way to make the karaf-maven-plugin properly sniff
dependencies, but ignore the API jar itself that is pulled in from the
inputFile version of the features.xml? I've tried various types of
scope, depending/not depending on the api bundle, feature, or both. I
can't seem to make it realize that it already has that api dependency
from the included feature without hand-crafting the entire features.xml,
which I'm trying to avoid, since the idea is to handle dependencies in a
reasonable way.
--
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/
Re: karaf-maven-plugin and feature dependencies
Posted by Benjamin Reed <ra...@opennms.org>.
On 5/30/12 4:37 AM, Christian Schneider wrote:
> Can you try to add the feature of the api to the dependencies of the
> other feature?
>
> We do a similar thing when we define the sprign feature in karaf:
> <dependency>
> <groupId>org.apache.karaf.features</groupId>
> <artifactId>standard</artifactId>
> <version>${project.version}</version>
> <classifier>features</classifier>
> <type>xml</type>
> <scope>provided</scope>
> </dependency>
Ah, yeah, I was already doing that (it's how the api stuff ends up in
features.xml), just hadn't been specific enough in my original mail.
Hopefully attachments are allowed here; attached are the poms and
features.xml files. If not, I'll post them somewhere public. :)
It all looks good *except* that app-features.xml ends up with that extra
"<bundle>mvn:org.opennms.features.topology/org.opennms.features.topology.api/1.11.1-SNAPSHOT</bundle>"
that it should be inheriting from the <feature /> reference to the API
bit instead.
--
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/
Re: karaf-maven-plugin and feature dependencies
Posted by Christian Schneider <ch...@die-schneider.net>.
Can you try to add the feature of the api to the dependencies of the
other feature?
We do a similar thing when we define the sprign feature in karaf:
<dependency>
<groupId>org.apache.karaf.features</groupId>
<artifactId>standard</artifactId>
<version>${project.version}</version>
<classifier>features</classifier>
<type>xml</type>
<scope>provided</scope>
</dependency>
Christian
Am 29.05.2012 23:33, schrieb Benjamin Reed:
> I'm trying to figure out the best way to build a set of features.xml
> files automatically in a multi-pom project.
>
> I have things *almost* working using karaf-maven-plugin + inputFile
> filtering, but I'm running into one last issue. Here is how the project
> is set up:
>
> here's the org.opennms.features.topology.api features.xml:
>
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0"
> name="OpenNMS Topology APIs">
> <feature description="OpenNMS Topology APIs"
> version="1.11.1-SNAPSHOT" name="org.opennms.features.topology.api">
> <details>APIs for topology manipulation and display.</details>
>
> <bundle>mvn:org.opennms.features.topology/org.opennms.features.topology.api/1.11.1-SNAPSHOT</bundle>
> <bundle>mvn:com.vaadin/vaadin/6.7.3</bundle>
> <bundle>wrap:mvn:javax.servlet/servlet-api/2.5</bundle>
> </feature>
> </features>
>
> In another project (org.opennms.features.topology.app) I have to depend
> on the API to be able to compile:
>
> ---(pom.xml snip!)---
> <dependency>
> <groupId>org.opennms.features.topology</groupId>
> <artifactId>org.opennms.features.topology.api</artifactId>
> <version>${project.version}</version>
> </dependency>
> ---(pom.xml snip!)---
>
> ...and then I use features-generate-descriptor to create a descriptor:
>
> ---(pom.xml snip!)---
> <plugin>
> <groupId>org.apache.karaf.tooling</groupId>
> <artifactId>karaf-maven-plugin</artifactId>
> <version>3.0.0-SNAPSHOT</version>
> <extensions>true</extensions>
> <executions>
> <execution>
> <id>generate</id>
> <phase>generate-resources</phase>
> <goals>
> <goal>features-generate-descriptor</goal>
> </goals>
> <configuration>
> <inputFile>src/main/features/features.xml.in</inputFile>
> <outputFile>target/features.xml</outputFile>
> <aggregateFeatures>true</aggregateFeatures>
> </configuration>
> </execution>
> </executions>
> </plugin>
> ---(pom.xml snip!)---
>
> I use an inputFile so that org.opennms.features.topology.app can have a
> "feature" dependency on the API:
>
> ---(features.xml.in snip!)---
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0"
> name="OpenNMS Topology Application">
> <feature name="org.opennms.features.topology.app"
> version="${project.version}" description="OpenNMS Topology Application">
> <details>The main Vaadin-based OpenNMS topology
> application.</details>
> <feature
> version="${project.version}">org.opennms.features.topology.api</feature>
>
> <bundle>mvn:${project.groupId}/${project.artifactId}/${project.version}</bundle>
> </feature>
> </features>
> ---(features.xml.in snip!)---
>
> ...but the resultant feature ends up containing both the api "feature"
> and the mvn: dependency sniffed from the pom.
>
> ---(features.xml snip!)---
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0"
> name="OpenNMS Topology Application">
> <feature description="OpenNMS Topology Application"
> version="1.11.1-SNAPSHOT" name="org.opennms.features.topology.app">
> <details>The main Vaadin-based OpenNMS topology
> application.</details>
> <feature
> version="1.11.1-SNAPSHOT">org.opennms.features.topology.api</feature>
>
> <bundle>mvn:org.opennms.features.topology/org.opennms.features.topology.app/1.11.1-SNAPSHOT</bundle>
>
> <bundle>mvn:org.opennms.features.topology/org.opennms.features.topology.api/1.11.1-SNAPSHOT</bundle>
> <bundle>mvn:org.ops4j.pax.vaadin/service/0.1.0-SNAPSHOT</bundle>
> <bundle>wrap:mvn:com.google.gwt/gwt-user/2.3.0</bundle>
> <bundle>wrap:mvn:net.sf.jung/jung-api/2.0.1</bundle>
>
> <bundle>wrap:mvn:net.sourceforge.collections/collections-generic/4.01</bundle>
> <bundle>wrap:mvn:net.sf.jung/jung-graph-impl/2.0.1</bundle>
> <bundle>wrap:mvn:net.sf.jung/jung-algorithms/2.0.1</bundle>
> <bundle>wrap:mvn:colt/colt/1.2.0</bundle>
> <bundle>wrap:mvn:concurrent/concurrent/1.3.4</bundle>
> <bundle>wrap:mvn:net.sf.jung/jung-visualization/2.0.1</bundle>
> </feature>
> <feature description="OpenNMS Topology APIs"
> version="1.11.1-SNAPSHOT" name="org.opennms.features.topology.api">
> <details>APIs for topology manipulation and display.</details>
>
> <bundle>mvn:org.opennms.features.topology/org.opennms.features.topology.api/1.11.1-SNAPSHOT</bundle>
> <bundle>mvn:com.vaadin/vaadin/6.7.3</bundle>
> <bundle>wrap:mvn:javax.servlet/servlet-api/2.5</bundle>
> </feature>
> </features>
> ---(features.xml snip!)---
>
> Is there any way to make the karaf-maven-plugin properly sniff
> dependencies, but ignore the API jar itself that is pulled in from the
> inputFile version of the features.xml? I've tried various types of
> scope, depending/not depending on the api bundle, feature, or both. I
> can't seem to make it realize that it already has that api dependency
> from the included feature without hand-crafting the entire features.xml,
> which I'm trying to avoid, since the idea is to handle dependencies in a
> reasonable way.
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: karaf-maven-plugin and feature dependencies
Posted by Benjamin Reed <ra...@opennms.org>.
On 5/30/12 9:58 AM, Brian Topping wrote:
> Have you tried this without <aggregateFeatures> ?
>
> JB recently applied a patch that hasn't gotten a lot of testing that is
looking at the dependencies of the transitives to determine how to
handle these situations, but I haven't had a lot of content to test it
with other than my own. I'm about to put together the files you sent
(thanks for those) and refine what you're getting out of it.
>
> More as I get it...
With or without aggregateFeatures it ends up with the same thing, only
without the extra <feature /> tag.
I notice in the code where it's adding dependencies, it says:
//TODO check for duplicates?
features.getFeature().addAll(includedFeatures.getFeature());
...are you saying there's a patch that fills that out? If so, I'd be
happy to help test it. Otherwise I was going to look into trying to
make it do so. :)
--
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/
Re: karaf-maven-plugin and feature dependencies
Posted by Brian Topping <to...@codehaus.org>.
Have you tried this without <aggregateFeatures> ?
JB recently applied a patch that hasn't gotten a lot of testing that is looking at the dependencies of the transitives to determine how to handle these situations, but I haven't had a lot of content to test it with other than my own. I'm about to put together the files you sent (thanks for those) and refine what you're getting out of it.
More as I get it...
Brian
On May 29, 2012, at 5:33 PM, Benjamin Reed wrote:
> I'm trying to figure out the best way to build a set of features.xml
> files automatically in a multi-pom project.
>
> I have things *almost* working using karaf-maven-plugin + inputFile
> filtering, but I'm running into one last issue. Here is how the project
> is set up:
>
> here's the org.opennms.features.topology.api features.xml:
>
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0"
> name="OpenNMS Topology APIs">
> <feature description="OpenNMS Topology APIs"
> version="1.11.1-SNAPSHOT" name="org.opennms.features.topology.api">
> <details>APIs for topology manipulation and display.</details>
>
> <bundle>mvn:org.opennms.features.topology/org.opennms.features.topology.api/1.11.1-SNAPSHOT</bundle>
> <bundle>mvn:com.vaadin/vaadin/6.7.3</bundle>
> <bundle>wrap:mvn:javax.servlet/servlet-api/2.5</bundle>
> </feature>
> </features>
>
> In another project (org.opennms.features.topology.app) I have to depend
> on the API to be able to compile:
>
> ---(pom.xml snip!)---
> <dependency>
> <groupId>org.opennms.features.topology</groupId>
> <artifactId>org.opennms.features.topology.api</artifactId>
> <version>${project.version}</version>
> </dependency>
> ---(pom.xml snip!)---
>
> ...and then I use features-generate-descriptor to create a descriptor:
>
> ---(pom.xml snip!)---
> <plugin>
> <groupId>org.apache.karaf.tooling</groupId>
> <artifactId>karaf-maven-plugin</artifactId>
> <version>3.0.0-SNAPSHOT</version>
> <extensions>true</extensions>
> <executions>
> <execution>
> <id>generate</id>
> <phase>generate-resources</phase>
> <goals>
> <goal>features-generate-descriptor</goal>
> </goals>
> <configuration>
> <inputFile>src/main/features/features.xml.in</inputFile>
> <outputFile>target/features.xml</outputFile>
> <aggregateFeatures>true</aggregateFeatures>
> </configuration>
> </execution>
> </executions>
> </plugin>
> ---(pom.xml snip!)---
>
> I use an inputFile so that org.opennms.features.topology.app can have a
> "feature" dependency on the API:
>
> ---(features.xml.in snip!)---
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0"
> name="OpenNMS Topology Application">
> <feature name="org.opennms.features.topology.app"
> version="${project.version}" description="OpenNMS Topology Application">
> <details>The main Vaadin-based OpenNMS topology
> application.</details>
> <feature
> version="${project.version}">org.opennms.features.topology.api</feature>
>
> <bundle>mvn:${project.groupId}/${project.artifactId}/${project.version}</bundle>
> </feature>
> </features>
> ---(features.xml.in snip!)---
>
> ...but the resultant feature ends up containing both the api "feature"
> and the mvn: dependency sniffed from the pom.
>
> ---(features.xml snip!)---
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0"
> name="OpenNMS Topology Application">
> <feature description="OpenNMS Topology Application"
> version="1.11.1-SNAPSHOT" name="org.opennms.features.topology.app">
> <details>The main Vaadin-based OpenNMS topology
> application.</details>
> <feature
> version="1.11.1-SNAPSHOT">org.opennms.features.topology.api</feature>
>
> <bundle>mvn:org.opennms.features.topology/org.opennms.features.topology.app/1.11.1-SNAPSHOT</bundle>
>
> <bundle>mvn:org.opennms.features.topology/org.opennms.features.topology.api/1.11.1-SNAPSHOT</bundle>
> <bundle>mvn:org.ops4j.pax.vaadin/service/0.1.0-SNAPSHOT</bundle>
> <bundle>wrap:mvn:com.google.gwt/gwt-user/2.3.0</bundle>
> <bundle>wrap:mvn:net.sf.jung/jung-api/2.0.1</bundle>
>
> <bundle>wrap:mvn:net.sourceforge.collections/collections-generic/4.01</bundle>
> <bundle>wrap:mvn:net.sf.jung/jung-graph-impl/2.0.1</bundle>
> <bundle>wrap:mvn:net.sf.jung/jung-algorithms/2.0.1</bundle>
> <bundle>wrap:mvn:colt/colt/1.2.0</bundle>
> <bundle>wrap:mvn:concurrent/concurrent/1.3.4</bundle>
> <bundle>wrap:mvn:net.sf.jung/jung-visualization/2.0.1</bundle>
> </feature>
> <feature description="OpenNMS Topology APIs"
> version="1.11.1-SNAPSHOT" name="org.opennms.features.topology.api">
> <details>APIs for topology manipulation and display.</details>
>
> <bundle>mvn:org.opennms.features.topology/org.opennms.features.topology.api/1.11.1-SNAPSHOT</bundle>
> <bundle>mvn:com.vaadin/vaadin/6.7.3</bundle>
> <bundle>wrap:mvn:javax.servlet/servlet-api/2.5</bundle>
> </feature>
> </features>
> ---(features.xml snip!)---
>
> Is there any way to make the karaf-maven-plugin properly sniff
> dependencies, but ignore the API jar itself that is pulled in from the
> inputFile version of the features.xml? I've tried various types of
> scope, depending/not depending on the api bundle, feature, or both. I
> can't seem to make it realize that it already has that api dependency
> from the included feature without hand-crafting the entire features.xml,
> which I'm trying to avoid, since the idea is to handle dependencies in a
> reasonable way.
>
> --
> Benjamin Reed
> The OpenNMS Group
> http://www.opennms.org/
>
>