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
