Christian - sounds like a good idea ;) 

Paremus have always pursued this sort of approach -  See 
https://docs.paremus.com/pages/viewpage.action?pageId=8060997 
<https://docs.paremus.com/pages/viewpage.action?pageId=8060997> for a simple 
example. 

Cheers




> On 19 Oct 2016, at 14:04, Christian Schneider <[email protected]> wrote:
> 
> I agree. Currently the feature files are too low level. Basically you have to 
> list all bundles.
> We need something like bndtools resolution.
> 
> So I think a feature should be backed by an index. I have made some good 
> experiences with pom based indexes. This is a pom that depends on bundles 
> (including transitive deps).
> The goal is to provide a full list of bundles as a basis of the feature file.
> See this as an example 
> https://github.com/apache/aries-rsa/blob/master/repository/pom.xml.
> In the pom above an OBR index is created by maven. Eventually this could be 
> skipped and karaf could create such an index on the fly as the maven index 
> plugin is not working very well for me.
> 
> Each feature would then only need to list the top level bundles and other 
> requirements.
> 
> The karaf maven plugin could then either validate the features against the 
> repository. This works if karaf can work with such index backed feature files.
> If karaf can not do this then the plugin could create the full list of 
> bundles per feature and write "traditional" feature files. The additional 
> resolved bundles would then
> have dependency=true.
> 
> Christian
> 
> On 13.10.2016 11:19, Milen Dyankov wrote:
>> I have 2 things to say to that
>> - I agree with all the pain points you've identified (experienced them
>> myself)
>> - I'd prefer to fix things instead of claim them useless due to
>> malfunctioning
>> 
>> Perhaps a middle ground would be a good starting point? Something like how
>> bndrun resolution works. I mean:
>>  - developer says - this is what I care to run (perhaps a prototype feature
>> or something ...)
>>  - feature-generate-descriptor takes it from there and fills in the gaps
>>  - developer can change/fix things by tweaking the prototype if not happy
>> with what feature-generate-descriptor did
>> 
>> This is just my first thought and I'm pretty sure reality is not that
>> simple. Just wanted to vote against removing it and suggest to start
>> looking for better solution instead.
>> 
>> Best,
>> Milen
>> 
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 

Reply via email to