karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: Bndtools & Karaf : the right way
Date Wed, 02 Dec 2015 12:44:33 GMT
Also, if the use case is a simple one, we still have the
features-generate-descriptor
goal in our plugin that can generate simple features descriptors and I we
could also add a goal (or enhance the existing one) to generate the
features xml from the resource repository.

Guillaume

2015-12-02 13:34 GMT+01:00 Guillaume Nodet <gnodet@apache.org>:

>
>
> 2015-12-02 11:04 GMT+01:00 David Leangen <apache@leangen.net>:
>
>>
>> Hi Guillaume,
>>
>> Thank you very much for looking into this so quickly!
>>
>>
>> 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:="(&amp;(karaf.identity=enroute-demo)(type=karaf.feature))"</requirement>
>> </feature>
>> </features>
>>
>>
>> What do you mean by “generated”? Do you mind providing a few more details?
>>
>
> What could  be done is a command that would create the features
> repository, given the resource xml repository generated by bnd.  It's just
> about parsing the repository, finding the "application" bundles, and create
> the above blob of xml.  Nothing very difficult from a technical pov.
>
> Again, the real problem is that I think those repositories should be
> transitively closed, i.e. they should contain everything needed to actually
> install and run the application.  It's currently not the case, as it seems
> that bnd will only generate the xml repository for the bundles in the
> project, not their dependencies.
>
> I think we end up with really two different things here: bndtools is
> certainly a nice toolchain to build OSGi bundles.  It does not look like a
> runtime deployment mechanism.  And that's what karaf features are.
> They should contain enough information for the whole application to be
> deployed, eventually the container to be modified (karaf provides
> "profiles" which may contain non ConfigAdmin configuration, libraries to
> add to the class path, etc...)
> It's one thing to generate the bundles, it's a different one to deploy
> them in a system, manage the lifecycle of the applications, upgrade
> applications, etc...
>
> The more I think about it, the less I think it's a good idea to have too
> much support for applications.  It will lack support for some features at a
> later point, and those have been already solved and would only support
> simple use cases.
> Imho, if you plan on deploying your bundles in Karaf, you should generate
> a feature inside your build.  For the above, it's just a matter of adding a
> dependency on the felix scr feature and a bundle dependency on the other
> extender.
>
> Anyway, once the 4.0.x branch has been created, I'll push what I have so
> far to master, that will allow you to use the <resource-repository> element
> inside features and fix a bunch of other problems related to deploying
> resources from those repositories.
>
>
>>
>>
>> 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.
>>
>>
>> Hmmm…
>>
>> In enRoute, these just get resolved, so I have never really thought about
>> it.
>>
>> 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…
>>
>>
>> Maybe it could be a standard "enRoute" repository that we can provide as
>> <resources-repository/> or global resource repository ?
>>
>>
>> I personally think this is a great idea! :-)
>>
>>
>> Cheers,
>> =David
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message