KAR feature not doing what the docs say it should
Locked
12
12
Re: KAR feature not doing what the docs say it should
 
|
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 <[hidden email]> wrote: > On Wed, Mar 2, 2011 at 09:33, Andreas Pieber <[hidden email]> wrote: >> On Wed, Mar 2, 2011 at 9:27 AM, David Jencks <[hidden email]> 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:[hidden email]] >>>> Sent: Wednesday, March 02, 2011 02:33 AM >>>> To: [hidden email] <[hidden email]> >>>> 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 <[hidden email]> 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 > |
Re: KAR feature not doing what the docs say it should
|
It's more than that. If you end up being offline or with no internet
access for example (and we have customers that need to build offline for example), not having all dependencies as maven dependencies is really a problem, as you can't rely on any tooling anymore to grab all the dependencies. On Wed, Mar 2, 2011 at 11:30, Andreas Pieber <[hidden email]> wrote: > 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 <[hidden email]> wrote: >> On Wed, Mar 2, 2011 at 09:33, Andreas Pieber <[hidden email]> wrote: >>> On Wed, Mar 2, 2011 at 9:27 AM, David Jencks <[hidden email]> 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:[hidden email]] >>>>> Sent: Wednesday, March 02, 2011 02:33 AM >>>>> To: [hidden email] <[hidden email]> >>>>> 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 <[hidden email]> 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 >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com |
Re: KAR feature not doing what the docs say it should
|
|
Well no one hinders you to keep all your deps in the poms AND in the
features.xml (but also no one forces you to do so). I'm still not convinced that this is a bad idea. Kind regards, Andreas On Wed, Mar 2, 2011 at 11:34 AM, Guillaume Nodet <[hidden email]> wrote: > It's more than that. If you end up being offline or with no internet > access for example (and we have customers that need to build offline > for example), not having all dependencies as maven dependencies is > really a problem, as you can't rely on any tooling anymore to grab all > the dependencies. > > On Wed, Mar 2, 2011 at 11:30, Andreas Pieber <[hidden email]> wrote: >> 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 <[hidden email]> wrote: >>> On Wed, Mar 2, 2011 at 09:33, Andreas Pieber <[hidden email]> wrote: >>>> On Wed, Mar 2, 2011 at 9:27 AM, David Jencks <[hidden email]> 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:[hidden email]] >>>>>> Sent: Wednesday, March 02, 2011 02:33 AM >>>>>> To: [hidden email] <[hidden email]> >>>>>> 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 <[hidden email]> 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 >>> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > |
|
In reply to this post by Adrian Trenaman-2
I propose we look at this from a different point of view, the implementer with basic knowledge of Karaf. With that in mind, whatever we decide to do with the plugin should result in the following use-cases being satisfied: 1) Provide a strong "starting point" for a features.xml file based on what's listed in the pom, leveraging maven. In my program, we spend 1 - 2 FTE (full time equivalents, basically8 to 16 hours of development time) per bundle (here I mean a bundle that we write, not that we use) to create a good features.xml file. We then aggregate these into a featues.xml file for our overall application. Being able to generate a good starting point for our features.xml documents would shave about three-quarters of this time off of the process. 2) Provide a good starting point for a deployable KAR file based on the pom and leveraging maven. When we finally get to the point where the KAR feature is usable in Karaf, I imagine it will take some time to create a deployable KAR. Implementers of smaller applications would be able to use this functionality to create thier final KAR file, while implementers of larger applications would be able to use this KAR as a starting point and then refine it. 3) Provide the ability to use a completed features.xml file to create a final KAR file for an application. This means that the plugin would read-in the features.xml, resolve all of the bundles, and then package the bundles with the features.xml file in a deployable KAR file. This is similar to how the KAR feature currently works. The overarching goal for the community should be to provide a tool that will ease the implementation of a new or existing Java application into Karaf. I'd also like to take this opportunity to comment on some of the discussion in this thread and others about how much a developer should know about OSGi before being able to successfully use it. Consider the lessons learned when we started moving our legacy enterprise applications (CORBA and home-grown) into the J2EE in the early 2000's. There were numerous developers of widely ranging skillsets who attempted to migrate thier applications, and early-on many were not successful, writing off the J2EE as too hard or complex to be viable. Most of this was caused by the learning curve of the new way-of-thinking required by the J2EE, and a lack of tools to do hand-holding for the developers. We can expect the same thing to occur with OSGi and Karaf. One major thing we can do to reduce this is to create tools that will do a lot of the heavy-lifting of OSGi for the developers. So, while from a knowledgable OSGi developer's point of view, it would be nice for all of our users to know everything there is to know about Karaf before they use it, that will not be the case for 80% of the users. If the features.xml file produced by the plugin isn't perfect, or needs tweaking, so be it. At least we've gotten the users most of the way to thier final solution.
Mike Van (All links open in new tabs)
Committer - Kalumet Atraxia Technologies Mike Van's Open Source Technologies Blog |
|
|
In reply to this post by Guillaume Nodet
+1 to Guillaume's point I can think of at least three common use-cases where an instance of Karaf would not be able to use a remote maven repo. 1) A highly secure environment, for example a bank's intranet. While the initial development will be done with access to a maven-repository, the intranet may not have any connection to the internet for security reasons. So, being able to distribute the initial application and then subsequent versions of the application via a KAR would allow the banks to keep thier stuff up to date. If you look at the Apache ACE project, they address this sort of use-case. 2) An installation in an underdeveloped area with poor internet access. Think of something like a government intranet in a 3rd world country. Its foreseeable that while they would have access to a maven repository, the download times would be so great that it wouldn't be viable to use them. In this case, again, being able to distribute a KAR on a flash-drive, via ACE or the like would allow them to keep thier applications up-to-date. 3) An embedded system. Currently there is an effort to create an embedded karaf. I can't imagine all embedded instances of Karaf would be connected to the internet. If the KAR feature were available in the embedded instance, this would be a good way of sending updates to the software. Admittedly, this is a pretty questionable use-case, but one that is foreseeable.
Mike Van (All links open in new tabs)
Committer - Kalumet Atraxia Technologies Mike Van's Open Source Technologies Blog |
Re: KAR feature not doing what the docs say it should
|
this sure has gotten long :-)
Lets see if I can summarize... maybe we can double the length... First, the features.xml generation and kar assembly are done in separate mojos, and the feature packaging stops after feature generation whereas the kar packaging generates the features.xml and then assembles a kar. Features generation: I think we all agree that the output from features generation should express pretty much all the options available in a features.xml. Some of these are going to be easy to derive from pom dependencies and other native pom information, some are going to be easy to derive from maven plugin configuration, and some are going to be easier to express in a source features.xml that is modified. The one thing that the current features generation doesn't do is include more than one feature in a generated features.xml. I'm not sure how important this is. One option should we decide to support it would be to have a plugin configuration option that includes the features from maven dependencies that are features. In other words, in a features or kar project A, if one of the maven dependencies B is a features packaging project, we would include the features from B's feature.xml in the generated features.xml for A. kar assembly: I think there's supposed to be way of controlling whether a dependency gets included in the kar, I'm not sure if that's implemented yet. We might want more flexibility about where resources get unpacked on installation. validation: I think this is the main area of controversy. There are two aspects: 1. should we validate that dependencies mentioned in the preexisting features.xml are also (transitive) maven dependencies of the project 2. should we include dependencies mentioned in the preexisting features.xml that are not known to maven in a kar. My answer to these are 1 yes, 2 no. (2 is only relevant if you answer 1 no). 2: if maven doesn't know about a dependency, then you need a way outside maven to find the dependency in order to include it in the kar. I guess this would involve configuring the pax-mvn-url stuff. But this duplicates maven configuration. This is just a bad idea and pretty much guarantees a non-portable build. 1. I think this is usually a good idea, but essential for kar packaging. I'd be OK with having an option to turn it off for standalone feature packaging, especially for non-mvn url dependencies. ------------- We might start needing some more concrete examples to focus the discussion. For instance seeing what Adrian means by "ergonomic" might be useful and insteresting. And as a side note.... karaf 3 is java 6 so it should be OK now to move the jaxb classes from tooling into the feature deployer runtime? thanks david jencks |
Re: KAR feature not doing what the docs say it should
|
In reply to this post by mikevan
Am 02.03.2011 17:55, schrieb karafman:
> Guillaume Nodet wrote: >> It's more than that. If you end up being offline or with no internet >> access for example (and we have customers that need to build offline >> for example), not having all dependencies as maven dependencies is >> really a problem, as you can't rely on any tooling anymore to grab all >> the dependencies. >> >> On Wed, Mar 2, 2011 at 11:30, Andreas Pieber wrote: >>> 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 wrote: >>>> On Wed, Mar 2, 2011 at 09:33, Andreas Pieber wrote: >>>>> On Wed, Mar 2, 2011 at 9:27 AM, David Jencks 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:[hidden email]] >>>>>>> Sent: Wednesday, March 02, 2011 02:33 AM >>>>>>> To: [hidden email] >>>>>>> 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. >>>>>>>>>>>>>> >>>>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> Open Source SOA >>>> http://fusesource.com >>>> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > +1 to Guillaume's point > > I can think of at least three common use-cases where an instance of Karaf > would not be able to use a remote maven repo. > > 1) A highly secure environment, for example a bank's intranet. While the > initial development will be done with access to a maven-repository, the > intranet may not have any connection to the internet for security reasons. > So, being able to distribute the initial application and then subsequent > versions of the application via a KAR would allow the banks to keep thier > stuff up to date. If you look at the Apache ACE project, they address this > sort of use-case. +1, it doesn't need a bank for such an environment. :) > 2) An installation in an underdeveloped area with poor internet access. > Think of something like a government intranet in a 3rd world country. Its > foreseeable that while they would have access to a maven repository, the > download times would be so great that it wouldn't be viable to use them. In > this case, again, being able to distribute a KAR on a flash-drive, via ACE > or the like would allow them to keep thier applications up-to-date. > > 3) An embedded system. Currently there is an effort to create an embedded > karaf. I can't imagine all embedded instances of Karaf would be connected > to the internet. If the KAR feature were available in the embedded > instance, this would be a good way of sending updates to the software. > Admittedly, this is a pretty questionable use-case, but one that is > foreseeable. > > ----- > 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-tp2606973p2614716.html > Sent from the Karaf - Dev mailing list archive at Nabble.com. |
Re: KAR feature not doing what the docs say it should
|
|
In reply to this post by David Jencks
Hey David,
On Wed, Mar 2, 2011 at 8:50 PM, David Jencks <[hidden email]> wrote: > this sure has gotten long :-) > > Lets see if I can summarize... maybe we can double the length... > > First, the features.xml generation and kar assembly are done in separate mojos, and the feature packaging stops after feature generation whereas the kar packaging generates the features.xml and then assembles a kar. > > Features generation: > I think we all agree that the output from features generation should express pretty much all the options available in a features.xml. Some of these are going to be easy to derive from pom dependencies and other native pom information, some are going to be easy to derive from maven plugin configuration, and some are going to be easier to express in a source features.xml that is modified. +1 > The one thing that the current features generation doesn't do is include more than one feature in a generated features.xml. I'm not sure how important this is. One option should we decide to support it would be to have a plugin configuration option that includes the features from maven dependencies that are features. In other words, in a features or kar project A, if one of the maven dependencies B is a features packaging project, we would include the features from B's feature.xml in the generated features.xml for A. Currently I don't need such a feature but it could be quite useful in some situations > kar assembly: > I think there's supposed to be way of controlling whether a dependency gets included in the kar, I'm not sure if that's implemented yet. > We might want more flexibility about where resources get unpacked on installation. Basically I can life with a simple "include everything" approach here... > validation: > I think this is the main area of controversy. There are two aspects: > 1. should we validate that dependencies mentioned in the preexisting features.xml are also (transitive) maven dependencies of the project > 2. should we include dependencies mentioned in the preexisting features.xml that are not known to maven in a kar. > > My answer to these are 1 yes, 2 no. (2 is only relevant if you answer 1 no). > 2: if maven doesn't know about a dependency, then you need a way outside maven to find the dependency in order to include it in the kar. I guess this would involve configuring the pax-mvn-url stuff. But this duplicates maven configuration. This is just a bad idea and pretty much guarantees a non-portable build. Analyzing all my karaf based projects again I can live as well with 1 yes and 2 no as the other way round; but yes, you're right David, yes/no would be the "cleaner" solution. > 1. I think this is usually a good idea, but essential for kar packaging. I'd be OK with having an option to turn it off for standalone feature packaging, especially for non-mvn url dependencies. +1 > > ------------- > > We might start needing some more concrete examples to focus the discussion. For instance seeing what Adrian means by "ergonomic" might be useful and insteresting. > > And as a side note.... karaf 3 is java 6 so it should be OK now to move the jaxb classes from tooling into the feature deployer runtime? Yep Kind regards, Andreas > > thanks > david jencks |
Re: KAR feature not doing what the docs say it should
|
|
In reply to this post by David Jencks
Hi,
I like that proposal. +1 2011/3/2 David Jencks <[hidden email]>: > this sure has gotten long :-) > > Lets see if I can summarize... maybe we can double the length... > > First, the features.xml generation and kar assembly are done in separate mojos, and the feature packaging stops after feature generation whereas the kar packaging generates the features.xml and then assembles a kar. > > Features generation: > I think we all agree that the output from features generation should express pretty much all the options available in a features.xml. Some of these are going to be easy to derive from pom dependencies and other native pom information, some are going to be easy to derive from maven plugin configuration, and some are going to be easier to express in a source features.xml that is modified. > > The one thing that the current features generation doesn't do is include more than one feature in a generated features.xml. I'm not sure how important this is. One option should we decide to support it would be to have a plugin configuration option that includes the features from maven dependencies that are features. In other words, in a features or kar project A, if one of the maven dependencies B is a features packaging project, we would include the features from B's feature.xml in the generated features.xml for A. > > kar assembly: > I think there's supposed to be way of controlling whether a dependency gets included in the kar, I'm not sure if that's implemented yet. > We might want more flexibility about where resources get unpacked on installation. > > validation: > I think this is the main area of controversy. There are two aspects: > 1. should we validate that dependencies mentioned in the preexisting features.xml are also (transitive) maven dependencies of the project > 2. should we include dependencies mentioned in the preexisting features.xml that are not known to maven in a kar. > > My answer to these are 1 yes, 2 no. (2 is only relevant if you answer 1 no). > 2: if maven doesn't know about a dependency, then you need a way outside maven to find the dependency in order to include it in the kar. I guess this would involve configuring the pax-mvn-url stuff. But this duplicates maven configuration. This is just a bad idea and pretty much guarantees a non-portable build. > > 1. I think this is usually a good idea, but essential for kar packaging. I'd be OK with having an option to turn it off for standalone feature packaging, especially for non-mvn url dependencies. > > ------------- > > We might start needing some more concrete examples to focus the discussion. For instance seeing what Adrian means by "ergonomic" might be useful and insteresting. > > And as a side note.... karaf 3 is java 6 so it should be OK now to move the jaxb classes from tooling into the feature deployer runtime? > > thanks > david jencks |
«
Return to Karaf - Dev
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |