Hi JB and Christian, I am very interested in this discussion, as it is extremely related to my current top priority (getting a bndtools—>Karaf development+deployment workflow in place).
>> We created features instead of using directly OBR as OBR doesn't cover the >> needs (features contain transitive features, configuration, bundles, etc). >> Generating a feature from OBR repository will result to incomplete and >> limited features IMHO. I see. That makes sense. Then perhaps all we need to do is allow a Feature to include an OBR repo as an option. Bundles in the feature could provide a capability (for example in the “namespace=karaf.feature”) to flag it as a bundle to be included in the feature. <features xmlns="http://karaf.apache.org/xmlns/features/v1.3.0"; name=“my-feature-set"> <feature name=“my-feature" description=“My Feature" version=“1.0.0"> <obr>http://host.com/path/to/repo/index.xml <http://host.com/path/to/repo/index.xml></obr> </feature> </features> And in the OBR: <repository xmlns="http://www.osgi.org/xmlns/repository/v1.0.0"; increment=“1" name="Release"> <resource> <capability namespace="osgi.identity"> <attribute name="osgi.identity" value=“my.application.api"/> <attribute name="type" value="osgi.bundle"/> <attribute name="version" type="Version" value=“1.0.0"/> </capability> <capability namespace="osgi.content"> <attribute name="osgi.content" value=“..."/> <attribute name="url" value=“..."/> <attribute name="size" type="Long" value=“..."/> <attribute name="mime" value="application/vnd.osgi.bundle"/> </capability> <capability namespace="osgi.wiring.bundle"> <attribute name="osgi.wiring.bundle" value=“my.dependency"/> <attribute name="bundle-version" type="Version" value=“1.0.0"/> </capability> ... <capability namespace=“karaf.feature"> <attribute name=“feature.id" value=“name.of.feature/1.0.0"/> <attribute name=“start-level" value=“80"/> <attribute name=“config" value=“com.foo.bar”> <property name=“myProperty” value=“myValue”/> </attribute> </capability> <requirement namespace="osgi.ee"> <directive name="filter" value="(&(osgi.ee=JavaSE)(version=1.8))"/> </requirement> ... </resource> </repository> (Not sure if the attributes should be there or not, just added them in as an afterthought.) In any case, all the bundle information etc. is already there, so it seems unnecessary to have to duplicate it in in a features.xml file. >> As bndtools is a design/development time, I would prefer that it can >> generate a complete feature. I understand. This does not really fit our model well and, if I am understanding the intent of OSGi, not that model, either. I believe that OSGi presumes that the bundle developer is a different role from the operator. I would argue that the creation of features is an operator function, not a bundle developer function. In my specific use case, I am considering having a “deployment” service read the available OBR repositories, and provide deployment options to the operator at (deployment) runtime. What I think would be easy to do is to read the OBR repositories and, one way or another, create features on the fly based on what is available. In this way, the operator creates the features (on the fly) based on what she is given by the bundle developers. This way, there would be a clear handoff (the OBR repo being the intermediary), strong decoupling between development and runtime, and a clear distinction of roles. BTW, on that note, I would argue that the model behind Karaf assumes that the operators know OSGi very deeply, and are probably themselves bundle developers. At least, the separation of roles seems vague to me. Perhaps I am misunderstanding. Anyway, I am trying to bend our developer/operator to suit Karaf, or rather bend Karaf to fit our deployment model. I’ll let you know how that goes if I do continue down this route. > I also thought about how to nicely deploy applications created by bndtools. > I think there are two general ways of using karaf > > 1. Server mode > > You deploy several independent deployment units to karaf. This is for example > used by Talend or Redhat to deploy many indepenent integrations into karaf. > You use features to describe each deployment unit and use the shell or jmx to > deploy them. > > For this mode a solution could be to create an obr index for your application > using the bnd-indexer-plugin. We think about adding an element to the > feature.xml to reference such a repository. > The features should then work in a similar way to bndrun files and just > describe the top level bundles and requirements and let the resolver create > the actual list of bundles to install. > > We are also thinking about creating obr indexes for each open source project > per release and deploy these to maven central. So you could create your > application in bndtools by just combining existing > obr repository files. > > Bndtools could also be adapted to be able to create and validate feature > files. On the other hand we could adapt the karaf feature.xml to look more > like a bndrun file. So for example if you already have an > obr index to back your feature then each bundle requirement in the featue can > be desribed like in bndrun using the symbolic name + optionally a version > range. So this would make creating features a lot easier. I think the idea of these indexed OBR files is great! It would provide a complete and detailed description for such a deployment unit. It should be extensible and configurable as well, ideally. I think this is quite similar to what I describe above. I would further argue that Karaf should be layered on top of such OBR repository in order to keep it generic (and not only Karaf-focused), else the spec should be enhanced. Since this represents a generalised runtime problem, not just a Karaf problem, perhaps this updated feature model could be the basis of such spec update. Just a thought. > 2. Application mode > > In this case karaf typically hosts only one deployment unit. You want to > start and most times also deploy your application together with karaf. > > In most cases a karaf custom distribution is created during the application > build. > Here you have two choices to describe your application. The traditional way > is to describe it as one or more features and add these to the boot features. > > As bndtools can not create features but can create nice deployments from > bndrun files we can also use another approach here. We could skip the whole > feature service and describe karaf + your application > as a plain list of bundles using startup.properties. Bndtools could supply > this list and an enhanced karaf maven plugin could create the whole archive. > I think this mode should be realtively easy to support using bndtools. > It should also be possible to make the nice bndtools debug mode work with > karaf. > > Another advantage of the application approach would be that the static list > of bundles is a very stable form of deployment. You can not have surprises > like the feature service refreshing bundles or karaf trying to load artifacts > from the internet. > > As these concepts are not yet tested in the field I would be very interested > in your feedback Agree that in this case, a static deployment descriptor would make sense. Perhaps instead of “server” vs. “application” mode, we could consider “static” vs. “dynamic” mode. Just a thought. >> I agree that a spec enhancement, containing a mix feature (as a generic OSGi >> feature), subsystem, OSGi Repositories (new name of OBR) can be interesting. >> As I said in another e-mail, I would be more than happy to participate, but >> as Apache is not a company and can't pay the OSGi Alliance, it's not easy >> for us to be part of the OSGi Alliance (other than being employee of a >> company already member of the OSGi Alliance). This part of the thread seems to have taken on a life of its own, so I’ll leave it alone here. :-) Cheers, =David
