Well, but does it really matter if maven fails with: "artifact not found" or if the karaf-maven-plugin fails with "artifact not found"?
Kind regards, Andreas On Wed, Mar 2, 2011 at 11:25 AM, Guillaume Nodet <[email protected]> wrote: > On Wed, Mar 2, 2011 at 09:33, Andreas Pieber <[email protected]> wrote: >> On Wed, Mar 2, 2011 at 9:27 AM, David Jencks <[email protected]> wrote: >>> 1. Supporters of the "don't need maven dependencies" idea almost had me >>> convinced for a while until I realized this would really be abusing maven. >>> It would be OK for an ant task where there's no expectation of any >>> structure, but one of the basic principles that makes maven work is that >>> the pom describes all the outside dependencies. Generally violating this >>> principal causes lots of unanticipated problems when you try to reason >>> about the broken pom downstream. >> >> I'm not with you here. You still have to define the versions >> somewhere; I see the features.xml more as an extension than an >> replacement. > > Yes, I agree, having all dependencies in maven ensure that your build > can be reproducible. I had problems with features that use > dependencies not available in any maven repository for example. That > make thing difficult to diagnose and work around. > >> >>> 2. The kar packaging already does a lot of things including extending an >>> existing features.xml (so you can have config properties etc) and including >>> arbitrary resources that get unpacked into the karaf server. I think if >>> there's documentation in a features.xml file it should be in elements so it >>> can be reasoned about and possibly displayed in the console. I'm sure >>> there are more things we can get it to do, and specific examples would >>> really help. >> >> But still, I have no problem if we allow both possibilities, but it >> should always be possible (imho) to create a kar file based on a >> features.xml >> >> Kind regards, >> Andreas >> >>> >>> thanks >>> david jencks >>> >>> On Mar 1, 2011, at 11:52 PM, Adrian Trenaman wrote: >>> >>>> 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] <[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 <[email protected]> >>>> 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: >>>>>>>> >>>>>>>> <dependencies> >>>>>>>> <dependency .../> >>>>>>>> <dependency .../> >>>>>>>> <dependency .../> >>>>>>>> <dependency .../> >>>>>>>> <dependency .../> >>>>>>>> <dependency .../> >>>>>>>> <dependency .../> >>>>>>>> <dependency .../> >>>>>>>> <dependency .../> >>>>>>>> <dependency .../> >>>>>>>> </dependendies> >>>>>>>> >>>>>>>> you simple have in the plugin >>>>>>>> <configuration> >>>>>>>> <features>myfeature</features> >>>>>>>> </configuration> >>>>>>>> >>>>>>>> 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: >>>>>>>>>>> >>>>>>>>>>> <project xmlns="http://maven.apache.org/POM/4.0.0"; >>>>>>>>>>> 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";> >>>>>>>>>>> >>>>>>>>>>> <modelVersion>4.0.0</modelVersion> >>>>>>>>>>> >>>>>>>>>>> <groupId>hibernate-osgi</groupId> >>>>>>>>>>> <artifactId>hibernate-osgi</artifactId> >>>>>>>>>>> <version>0.0.1-SNAPSHOT</version> >>>>>>>>>>> <packaging>kar</packaging> >>>>>>>>>>> <name>hibernate-osgi</name> >>>>>>>>>>> >>>>>>>>>>> <dependencies> >>>>>>>>>>> <!-- put in the bundles you want in the features.xml and kar as >>>>>>>>>>> dependencies --> >>>>>>>>>>> </dependencies> >>>>>>>>>>> >>>>>>>>>>> <build> >>>>>>>>>>> <plugins> >>>>>>>>>>> <plugin> >>>>>>>>>>> <groupId>org.apache.karaf.tooling</groupId> >>>>>>>>>>> >>>>>>>>>>> <artifactId>features-maven-plugin</artifactId> >>>>>>>>>>> <version>2.99.99-SNAPSHOT</version> >>>>>>>>>>> <extensions>true</extensions> >>>>>>>>>>> </plugin> >>>>>>>>>>> </plugins> >>>>>>>>>>> </build> >>>>>>>>>>> >>>>>>>>>>> </project> >>>>>>>>>>> >>>>>>>>>>> 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: >>>>>>>>>>>> <project xmlns="http://maven.apache.org/POM/4.0.0"; >>>>>>>>>>>> >>>>>>>>>>>> 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";> >>>>>>>>>>>> >>>>>>>>>>>> <modelVersion>4.0.0</modelVersion> >>>>>>>>>>>> >>>>>>>>>>>> <groupId>hibernate-osgi</groupId> >>>>>>>>>>>> <artifactId>hibernate-osgi</artifactId> >>>>>>>>>>>> <version>0.0.1-SNAPSHOT</version> >>>>>>>>>>>> <packaging>pom</packaging> >>>>>>>>>>>> <name>hibernate-osgi</name> >>>>>>>>>>>> >>>>>>>>>>>> <build> >>>>>>>>>>>> <plugins> >>>>>>>>>>>> <plugin> >>>>>>>>>>>> <groupId>org.apache.karaf.tooling</groupId> >>>>>>>>>>>> >>>>>>>>>>>> <artifactId>features-maven-plugin</artifactId> >>>>>>>>>>>> <version>2.99.99-SNAPSHOT</version> >>>>>>>>>>>> <executions> >>>>>>>>>>>> <execution> >>>>>>>>>>>> <id>archive-kar</id> >>>>>>>>>>>> <goals> >>>>>>>>>>>> >>>>>>>>>>>> <goal>archive-kar</goal> >>>>>>>>>>>> </goals> >>>>>>>>>>>> <configuration> >>>>>>>>>>>> <featuresFile>src/main/resources/features.xml</featuresFile> >>>>>>>>>>>> </configuration> >>>>>>>>>>>> </execution> >>>>>>>>>>>> </executions> >>>>>>>>>>>> </plugin> >>>>>>>>>>>> </plugins> >>>>>>>>>>>> </build> >>>>>>>>>>>> >>>>>>>>>>>> </project> >>>>>>>>>>>> >>>>>>>>>>>> Using this features.xml file: >>>>>>>>>>>> >>>>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?> >>>>>>>>>>>> <features> >>>>>>>>>>>> <feature name="hibernate" version="3.3.2.GA"> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:javax.xml.stream/com.springsource.javax.xml.stream/1.0.1</bundle> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:org.dom4j/com.springsource.org.dom4j/1.6.1</bundle> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:org.jboss.javassist/com.springsource.javassist/3.9.0.GA</bundle> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:javax.persistence/com.springsource.javax.persistence/1.0.0</bundle> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:org.antlr/com.springsource.antlr/2.7.7</bundle> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:net.sourceforge.cglib/com.springsource.net.sf.cglib/2.2.0</bundle> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:org.apache.commons/com.springsource.org.apache.commons.collections/3.2.1</bundle> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:org.apache.commons/com.springsource.org.apache.commons.logging/1.1.1</bundle> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:org.objectweb.asm/com.springsource.org.objectweb.asm/1.5.3</bundle> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:org.objectweb.asm/com.springsource.org.objectweb.asm.attrs/1.5.3</bundle> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:org.hibernate/com.springsource.org.hibernate/3.3.2.GA</bundle> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:org.hibernate/com.springsource.org.hibernate.annotations/3.3.1.ga</bundle> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:org.hibernate/com.springsource.org.hibernate.annotations.common/3.3.0.ga</bundle> >>>>>>>>>>>> >>>>>>>>>>>> <bundle>mvn:org.hibernate/com.springsource.org.hibernate.ejb/3.3.2.GA</bundle> >>>>>>>>>>>> </feature> >>>>>>>>>>>> </features> >>>>>>>>>>>> >>>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
