Hi,
Guillaume Nodet-2 wrote >>>Anyway, once I'm given a repository and a set of bundles to look at, i'm willing to look at it. dleangen wrote >>Cool! Thank you very much! >> >>I will work on that as soon as I can. :-) I have created a sample bndtools (enRoute) workspace on github: https://github.com/dleangen/org.apache.karaf.demos.enroute Although quite simplistic, hopefully it is representative of what happens in a typical enRoute workspace. The workspace gets released as a unit in the form of an OBR. To me, this “unit” is clearly homologous to a Karaf Feature, or at least very synergetic. The objective is in fact to take the released OBR, which is plain and simple OSGi, and transform it into a Feature on the fly. The “driver” or “application” bundle is org.apache.karaf.demos.enroute.application. The EnrouteApplication class pulls in all the required dependencies. The mechanism is to annotate the class, and bndtools uses the information in the annotations to write the requirements in the manifest. All Karaf would need to do is wrap this bundle, and in theory all the requirements (if available) should get resolved. I’m still grappling a bit with what to do about configurations with regards to features, but FYI I also included a simple configuration in the "enRoute Way” as well. You can see this in the “unrelated” bundle, which also happens to get pulled into the “application”. (I am not advocating that this _should_ be the right or only way to pull in a dependency or a configuration, just showing that it _can_ be done, and is very easy to do.) Once the code was ready, I performed a “release”, which creates an OBR. This is saved in the cnf/release directory, which I also committed to the same project in github. If you look at the index.xml file, you will notice that the application bundle indeed provides the following capability: <capability namespace="karaf.identity"> <attribute name="description" value="Demo to show how to deploy an enRoute application with Karaf"/> <attribute name="karaf.identity" value="enroute-demo"/> <attribute name="type" value="karaf.feature"/> <attribute name="version" type="Version" value="1.0.0"/> </capability> As you can probably imagine, it would be very easy to write a parser to scan for this “feature” and create one in runtime. In fact, I already created a parser (was very easy to do indeed), but got blocked because currently Karaf won’t let me use this info to create a Feature in runtime, as it expects an xml file instead. Barring any suggested improvements, then, it seems to me that the only things to decide on to make this nice process work are: 1. Whether or not the namespace etc. should be standardised in Karaf 2. If so, what this standardisation should be, and create a corresponding parser 3. How to get a feature working in runtime without requiring the use of a features.xml file Please let me know if I can provide any more information. Hopefully this gives a better idea of what could be done. :-) Cheers, =David -- View this message in context: http://karaf.922171.n3.nabble.com/Bndtools-Karaf-the-right-way-tp4043765p4043974.html Sent from the Karaf - User mailing list archive at Nabble.com.
