Just to pitch in on this: I really like to write my own feature files
for Karaf. Generally, I want to create one features file that pulls
together artifacts from a whole set of projects, in a way that
creates features as meaningful 'applications' that an ops guy can
install/uninstall. While I appreciate that we could auto-generate the
features file from a Maven POM, I prefer to *design* my features so
that they're ergonomic. And, as has been mentioned earlier on this
trail, hand-crafted features allow me to add config, documentation,
etc. Any tooling we can write that helps the developer do this in an
easy, no fuss way (and maybe spots any missing dependencies) should
be preferred over a 'generate-from-Maven' approach, IMHO.
Cheers,
Ade
----- Original Message -----
From: Andreas Pieber [mailto:[email protected]]
Sent: Wednesday, March 02, 2011 02:33 AM
To: [email protected]
Subject: Re: KAR feature not doing what the docs say it should
Hey David
On Wed, Mar 2, 2011 at 8:09 AM, David Jencks wrote:
I'm trying to understand why you want to maintain a features.xml by
hand so that the versions in it will differ from those in your maven
project rather than generating the features.xml from your maven
project so the versions will match up.
I'm not sure why they should? You can easily wire them together by
filter the features.xml and use something like ${xyz.version} in your
features.xml. In addition you do not always want to use the same
artifacts as you reference in your pom. E.g. if you wrap Apache
Wicket, you typically have one package with all deps, but in the src
you really want to reference the single packages to help maven
finding
sources and jdoc.
I agree with KARAF-459 to the extent that if we keep the archive-kar
goal it should use more info from the supplied features.xml. I am
arguing that we should not keep it. Why is it a good idea to
encourage people to get their dependencies out of sync?
I don't think that we encourage them to do so, but using the
features.xml it is much easier to add config files, configurations,
required features, other repositories... All of that have to be
configured otherwise anyhow in the maven plugin and I think this will
make it much more complex.
If you convince me this is a good idea :-) then I think making the
kar packaging so it can start with a (possibly partial)
features.xml, add maven dependencies to it, and put all the
resulting dependencies into the generated kar would be a good idea.
I think this would solve KARAF-459?
I've tried ;)
Kind regards,
Andreas
I don't know what the add-features-to-repo goal does yet so I'm not
sure if I think it's useful :-)
thanks
david jencks
On Mar 1, 2011, at 10:34 PM, Jean-Baptiste Onofré wrote:
I'm not sure to follow you.
The kar goal is exactly as the add-features-to-repo goal: you start
from a features descriptor (that you wrote by hand) and the goal
package the descriptor and the bundles/dependencies into a repo
(kar or local).
Regards
JB
On 03/02/2011 07:34 AM, David Jencks wrote:
OK, but you are in a maven environment. You've now disconnected
the versions in the features.xml which you are presumably
maintaining by hand from those in your maven poms. I consider
that a non-starter.
My point is that you want to construct the features.xml from maven
dependencies in the first place. At the same time you can
construct the kar, including (some of) the dependencies.
happy to be convinced otherwise...
thanks
david jencks
On Mar 1, 2011, at 10:05 PM, Jean-Baptiste Onofré wrote:
The main advantage is that it starts from the features
descriptor. So you simply define the features what you want to
embed in the Kar and the plugin is responsible to download and
embed all bundle dependencies.
For instance, in place of having:
you simple have in the plugin
myfeature
So the POM is light, the version is defined in the features
descriptor and it manages transitive dependencies to others
features.
Regards
JB
On 03/02/2011 07:00 AM, David Jencks wrote:
I might understand what the archive-kar goal does now, from the
jira issue.
I would like to suggest that we eliminate this goal and just use
the kar packaging which generates both the features.xml and the
kar from the maven dependencies.
When would the archive-kar goal be useful compared to the kar
packaging?
thanks
david jencks
On Mar 1, 2011, at 9:47 PM, Jean-Baptiste Onofré wrote:
Hi guys,
The purpose of the kar goal is to take a features descriptor
and package the features descriptor and the related bundle into
a kar archive (that's it's a goal of the features maven
plugin).
The kar deployer create a repo for these bundles.
I raised KARAF-459 about that. At least, the kar goals should
take an argument to define if the bundle are embedded in the
kar or not.
But, if the kar doesn't embed the bundle, what's the advantage
of using a kar more than directly drop the features descriptor
into the deploy directory :)
Regards
JB
On 03/01/2011 11:40 PM, David Jencks wrote:
I couldn't quite understand what the docs expected. What I
think is usable is the (undocumented) kar packaging which
ought to look something like this:
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
hibernate-osgi
hibernate-osgi
0.0.1-SNAPSHOT
kar
hibernate-osgi
org.apache.karaf.tooling
features-maven-plugin
2.99.99-SNAPSHOT
true
This should generate a features.xml file inside the kar and
include the bundles you mentioned as entries in the
feature.xml and copied into the kar.
thanks
david jencks
On Mar 1, 2011, at 2:15 PM, karafman wrote:
To test the KAR feature, I compiled the trunk and executed
the following
pom.xml file:
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
hibernate-osgi
hibernate-osgi
0.0.1-SNAPSHOT
pom
hibernate-osgi
org.apache.karaf.tooling
features-maven-plugin
2.99.99-SNAPSHOT
archive-kar
archive-kar
src/main/resources/features.xml
Using this features.xml file:
<?xml version="1.0" encoding="UTF-8"?>
mvn:javax.xml.stream/com.springsource.javax.xml.stream/1.0.1
mvn:org.dom4j/com.springsource.org.dom4j/1.6.1
mvn:org.jboss.javassist/com.springsource.javassist/3.9.0.GA
mvn:javax.persistence/com.springsource.javax.persistence/1.0.0
mvn:org.antlr/com.springsource.antlr/2.7.7
mvn:net.sourceforge.cglib/com.springsource.net.sf.cglib/2.2.0
mvn:org.apache.commons/com.springsource.org.apache.commons.collections/3.2.1
mvn:org.apache.commons/com.springsource.org.apache.commons.logging/1.1.1
mvn:org.objectweb.asm/com.springsource.org.objectweb.asm/1.5.3
mvn:org.objectweb.asm/com.springsource.org.objectweb.asm.attrs/1.5.3
mvn:org.hibernate/com.springsource.org.hibernate/3.3.2.GA
mvn:org.hibernate/com.springsource.org.hibernate.annotations/3.3.1.ga
mvn:org.hibernate/com.springsource.org.hibernate.annotations.common/3.3.0.ga
mvn:org.hibernate/com.springsource.org.hibernate.ejb/3.3.2.GA
The .kar file created didn't contain any of the bundles, just
the
features.xml file. The expected behavior is to (according to
http://karaf.apache.org/manual/2.2.1-SNAPSHOT/users-guide/kar.html):
The kar-archive goal:
1. Reads all features specified in the features descriptor.
2. For each feature, it resolves the bundles defined in the
feature.
3. All bundles are packaged into the kar archive.
So, it appears the KAR feature is not doing what is stated in
the docs. I
suggest we either change the documentation, or the
archive-kar goal.
-----
Karafman
Slayer of the JEE
Pounder of the Perl Programmer
--
View this message in context:
http://karaf.922171.n3.nabble.com/KAR-feature-not-doing-what-the-docs-say-it-should-tp2606973p2606973.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
