2015-12-02 7:06 GMT+01:00 dleangen <apa...@leangen.net>: > 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. >
So i've just experimented a bit with this repository. I've added the following repository to karaf which could easily be generated. <features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"; name="enroute-demo"> <resource-repository>file:///Users/gnodet/work/tmp/org.apache.karaf.demos.enroute/cnf/release/index.xml</resource-repository> <feature name="enroute-demo"> <requirement>karaf.identity;filter:="(&(karaf.identity=enroute-demo)(type=karaf.feature))"</requirement> </feature> </features> After having fixed a few problems in Karaf, I was at a point where I couldn't deploy the feature, because the above feature is not transitively closed. It requires 2 extenders (osgi.component and osgi.enroute.configurer), but those are not provided in the xml. I suppose the information is somewhat given from the list below: https://github.com/dleangen/org.apache.karaf.demos.enroute/blob/master/org.apache.karaf.demos.enroute.application/org.apache.karaf.demos.enroute.bndrun#L11-L22 But those informations should appear somewhere, else you can't figure what to deploy in order to solve those requirements. Anyway, I've removed the enrolee extender requirement from the xml, deployed scr, and finally got the application deployed (but the bundle application which can not be resolved at runtime because of the missing extender). My main worry now is about those un satisfied requirements. If the generated xml repository only contains the bundles that you are writing, we need a way to give a list of bundles that will actually solve the requirements that are not satisfied by the generated bundles (such as the 2 extenders above), but it could be different requirements on packages, services, etc... > > 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. >
