Hi Jean-Baptiste, On 05.02.17 16:36, Thomas Vandahl wrote: > Reading this makes me think that the list of Maven dependencies > (including transitive ones) should be sufficient to resolve everything. > Is this a valid assumption to make? The karaf-maven-plugin gives me for > example > > <bundle>mvn:org.apache.camel/camel-blueprint/2.18.1</bundle> > > Is this identical to > > <feature version="2.18.1">camel-blueprint</feature> > > and if not, how do I get the plugin to generate the latter from a > dependency entry in the POM? Is this possible at all or do I need to > manage the feature dependencies manually?
Ok, I got my feature artifact to verify successfully. Upgrading to Karaf 4.0.8 helped a lot. The error messages are much more helpful. However, it was *not* possible to get the feature to verify without adding feature dependencies to the feature.xml-template such as aries-blueprint, aries-proxy, eventadmin and spring - even though most of them were listed as wrapped bundles in the dependency tree. Moreover, I had to add the standard-feature-descriptor and the spring-feature-descriptor as "runtime"-dependencies to the POM. One last thing I learned was that a bundle dependency of camel-ftp/2.18.1 is obviously not identical to a feature dependency of camel-ftp. In the first case, the Karaf Maven plugin complains about a missing dependency to com.jcraft.jsch.*, in the second case, it doesn't. I now have a verified feature file but when I try to install it in a clean Karaf 4.0.8 instance, all cores go up to 100% and nothing else happens. No entries in the log file, no network activity, just CPU. I gave up after a little bit over an hour. Could you please explain how this is supposed to work and what debug approach would be the best? I can provide my code examples if you want, I'm just a bit reluctant to post them here. Bye, Thomas.
