I disagree. All the problems come when you start using maven transitive dependencies in real projects and hit lots of dependencies which are not OSGi bundles or not OSGi ready. Think about simple examples like spring, or all the bundles that we do re-wrap in servicemix. I think this idea is nice in theory, but it just does not work in real life.
Also, in the past years, several attemps have been made at using pure maven metadata to do provisioning, it has always failed to my knowledge, so I'd really want to avoid going that road again. Keep in mind that Karaf always create OBR repositories on the fly, based on the bundles listed in the features. If you maven metadata is clean, you can simply use the generate goal and you're good to go. If it's not clean enough, because it contains non OSGi dependencies, or because you need additional informations, keep your features hand-written. As for pure resource repositories, they can already be used and referenced from feature files using the <resource-repository> elements, so we can already experiment a bit. 2016-10-19 15:04 GMT+02:00 Christian Schneider <ch...@die-schneider.net>: > 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/arie > s-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 > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
