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 
> <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?


> 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
>  
> <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

Reply via email to