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:[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. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> 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. 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.
