[jira] [Commented] (KARAF-4160) Allow for the "feature wrapping" of a bundle

["David Leangen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KARAF-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035525#comment-15035525 ] 

David Leangen commented on KARAF-4160:
--------------------------------------

I have created a [sample bndtools (enRoute) workspace|https://github.com/dleangen/org.apache.karaf.demos.enroute] on github:

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:

{code:title=index.xml snippet|borderStyle=solid}
   <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>
{code}

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:

 # Whether or not the namespace etc. should be standardised in Karaf
 # If so, what this standardisation should be, and create a corresponding parser
 # 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. :-)

> Allow for the "feature wrapping" of a bundle
> --------------------------------------------
>
>                 Key: KARAF-4160
>                 URL: https://issues.apache.org/jira/browse/KARAF-4160
>             Project: Karaf
>          Issue Type: Improvement
>          Components: karaf-feature
>            Reporter: David Leangen
>
> In the OSGi capability/requirement model, if a bundle declares all of its dependencies, then it could be considered to be very similar to a feature.
> It would be very nice to be able to wrap such a bundle during runtime in order to generate features "on the fly". Currently, Karaf requires that a feature be described statically in a features.xml file, and further that related repositories already be declared at startup, so this type of dynamic feature generation is currently not possible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)