>From my standpoint I think the way features are in xml is really
convenient. That being said I am not sure what there is in features.xml
that could not be built off of stuff already in the osgi standard or
being proposed. Personally I feel the start level should be set by the
resolver and done by adding requirements. If you depend on another
feature being installed then there should be a requirement for it and
setting a later start level seems more of a hack for getting around
bundles that have requirements but don't list them and instead make
assumptions. To me a conditional boils down to being a calculated
requirement. I am not sure but it would be nice if you could use the
same approach that was used for osgi.type = karaf.feature. If you had an
osgi.type = karaf.conditional.{conditional_config_pid}, if karaf sees a
requirement that starts with karaf.conditional it will use the
configuration data at the pid to determine if the bundle should be
installed or not. As pointed out earlier the configurator could be used
to do the file deployment. I could see how there would be issues with
system provided packages and examples like you gave for cxf but I think
that the base system should be providing those as capabilities somehow.
That or the projects could check if they have all their dependent
libraries and if not deploy the jar and include it in the classpath.
Anyway, I like the features the way they are but it would be nice if you
could find a way to get the same functionality by using the standard
similar to how you did for getting features to use the standard
resolver. This would give the capability to use stuff like cxf outside
of karaf without needing an in depth knowledge of all its dependencies.
David Daniel
On 2015-11-30 05:21, Guillaume Nodet wrote:
> 2015-11-30 11:03 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>
>> I think it might make more sense to allow a bundle to be a "feature"
>> definition too.
>
> I don't think those bundles are really related (or need to be) to features.
>
>> JB, Peter Kriens and me discussed about this on friday over skype. A bundle
>> with just a Manifest
>> can express most of the things a feature can express.
>
>> Require-Bundle can express requirements on certain bundles with version
>> ranges. It can also express optional dependencies.
>> Require-Capability can express other requirements.
>> Capability can express that the bundle implements a feature with a given
>> name and version it can also define any other capabilities.
>
> Yeah, when you remove all the things in features that can't ;-)
>
>> The Configurer extender from enroute which might be standardized can express
>> default configs.
>
> I've had a very brief look at the RFC, it looks quite similar to what we've
> done with features.
>
>> As Guillaume expressed on IRC there are definitely cases such a bundle can
>> not express (like conditionals or start levels or overwriting files). It
>> could be sufficient for a lot of
>> business cases though.
>
> Right. The problem is that leading users into a direction where they'll be
> blocked once they get out of the simple cases is not a good idea to me.
> Features are not very difficult to generate and write, we should be able to
> find a way to integrate their generation into the bndtools chain.
>
>> As far as I understood from David as well as from Peter such (application)
>> bundles are used in bndtools a bit like we use features in karaf.
>
> Yeah, and that's clearly the problem I have. They start from a bunch of
> common requirements we have, but just a subset. So what we need is to have
> bndtools sufficiently opened, so that we can add our own requirements and
> generate what we need (i.e. a feature file).
>
>> One advantage of such bundles is that they can be easily produced by
>> bndtools (together with an index to resolve against) and even eclipse pde.
>> They also use the default resolver mechanics. So they can be resolved
>> against a bndtools index as well as as a p2 repository. If we find solutions
>> to some of the problems Guillaume
>> mentioned then we might have a way for e.g. CXF to express their features in
>> a way that works on all OSGi platforms.
>
> CXF is a good use case. Unfortunately, this is not a simple one. For example,
> CXF has requirements on xalan / xerces, which aren't even expressed in the
> feature yet. Support for libraries has been added to Karaf 4.x, but the
> feature has not been upgraded yet. This is another requirement which do not
> fit into the simple "application bundle" model.
>
>> So what we could do on the karaf side is either have a special feature
>> command to install such a bundle or have an option of the bundle:install
>> command
>> to install a bundle + its dependencies resolved by the resolver.
>
> We already have the code supporting it. And we can't use bundle:install
> command for it. It should be a feature:xxx command. The bundle:install
> commands are simple wrappers around the bundle context methods and I think we
> should keep them this way. The feature:xxx command do use the resolver and we
> can easily add a new command to the list.
> Right now, with the modifications I wrote to support OSGi Resource
> Repositories inside features repositories, it should be quite simple to
> implement:
> <features>
> <resource-repository>xml:url-to-the-repository-xml</resource-repository>
> <feature name="xxx">
> <requirement>requirement:osgi.identity;osgi.identity=application-bundle;osgi.type=xxx;version=xxx</requirement>
>
> </feature>
> </features>
> We could easily write a simple command to generate such a feature by simply
> giving the repository xml and the identity of the application bundle, but JB
> has been working on commands to add resource repositories, so it would
> already translate into 2 simple command calls:
> feature:resource-repository-add xml:url-to-the-repository-xml
> feature:requirement-add
> 'requirement:osgi.identity;osgi.identity=application-bundle;osgi.type=xxx;version=xxx'
>
>
> As a short term solution we could even just work with just karaf as is by
> creating a feature.xml that refers to the index and a feature that refers to
> the application bundle. It is a little overhead but would
> allow us to work out the idea some more without requiring bigger changes in
> karaf.
>
> This idea is still in an early stage but I think it has a lot of potential
> and it should make sense to experiment with it.
>
> Christian
>
> On 30.11.2015 10:40, Jean-Baptiste Onofré wrote:
> David wants to create a "dummy bundle", describing a feature as resources
> (without the XML).
>
> Not yet sure it's a good idea (it's what we discussed on IRC).
>
> Regards
> JB
>
> On 11/30/2015 10:36 AM, Guillaume Nodet wrote:
>
> 2015-11-30 8:41 GMT+01:00 David Leangen <apa...@leangen.net
> <mailto:apa...@leangen.net>>:
>
>>> There is an easy way to install bundles.
>>> Just use the feature:requirement-add command.
>
> Sounds practical. But then again, I really like the idea of
> "features". I like to see which "feature" is installed and
> running. If my bundle is only added as a requirement, then I
> lose that visibility. Also, having to restart Karaf each time
> I want to add a new repository (as is currently the case) is
> not a very nice option for me.
>
> Jean-Baptiste is working on that.
> I've also pushed support for referencing xml repositories from
> features files to a github branch
> https://github.com/gnodet/karaf/tree/KARAF-4130 [1]
> Looks nice!
>
> I noticed that currently, it is not possible to add a new Feature
> via the FeatureService. Although there is an addFeature(Feature)
> type method in the API, in practice it will not work if there is not
> a corresponding XML repo.
>
> It would be very nice to be able to create a feature on the fly,
> such as by wrapping a bundle, then add it via the service. Actually,
> for what I am trying to do it would be "necessary". :-)
>
> I'm not sure i understand this requirement. How can you
> programmatically generate the feature definition ? What's your input
> exactly ?
>
> Should I file a JIRA issue for this?
>
> In any case, feature:requirement-add is currently not working
> for me, for 2 reasons...
>
> 1) The patch I submitted to allow resolution of resources with
> relative URLs only works when
> there is one single Repository added to the config file.
> I am investigating an updated fix, but:
>
> 2) Something odd happens intermittently when I try to add a
> requirement. Karaf adds "type=karaf.feature"
> even when I express the type as "osgi.bundle". Example:
>
> karaf@root()> feature:requirement-add
> 'osgi.identity=my.bundle;type=osgi.bundle'
> Error executing command: Unable to resolve root: missing
> requirement [root] osgi.identity;
> osgi.identity="osgi.identity=my.bundle;type=osgi.bundle";
> type=karaf.feature;
> filter:="(&(osgi.identity=osgi.identity=my.bundle;type=osgi.bundle)(type=karaf.feature))"
>
> Try with feature:requirement-add
> 'requirement:osgi.identity;osgi.identity=my.bundle;type=osgi.bundle'
> Still trying. I must be doing something wrong... :-(
>
> Cheers,
> =David
--
Christian Schneider
http://www.liquid-reality.de [2]
Open Source Architect
http://www.talend.com [3]
Links:
------
[1] https://github.com/gnodet/karaf/tree/KARAF-4130
[2] http://www.liquid-reality.de
[3] http://www.talend.com
