I'm just building the new SNAPSHOT to test if the couple of issues I saw
are now fixed ;)
I keep you posted.
Thanks !
Regards
JB
On 12/02/2015 05:11 PM, Guillaume Nodet wrote:
2015-12-02 16:54 GMT+01:00 Christian Schneider <ch...@die-schneider.net
<mailto:ch...@die-schneider.net>>:
Am 02.12.2015 um 15:51 schrieb Guillaume Nodet:
Remember resource repositories can also point to other resource
repositories.
Interesting. I did not know this. That makes it a lot easier of course.
I read in the bndtools doc that it support multiple kind of
repositories. Can't we just add support for feature repositories ?
It could work. Would we simply add all the bundles in the feature
repository as an index?
I think one issue might be that a feature repository does not
contain the OSGi metadata. So we would need to
create it on the fly and probably cache it.
If we simply reuse the code in features-core from bndtools, this would
not really be necessary to cache anything.
Karaf does not cache those when they are built before a resolution, and
I don't think it's necessary to do so.
One other approach would be a maven plugin to create an OBR index
from a feature repository. So the result would directly work in
bndtools.
Probably this would be the simplest way to bring a lot of the karaf
features into bndtools for development.
For short term it could help to be able to use existing feature
repositories. For long term I really like the idea to back feature
repositories with an index.
It makes the individual features and the whole feature creation
process a lot simpler. So probably it makes sense to follow both paths.
This made me think about one problem with using repositories. For
example in aries, we release bundles individually as needed. This would
make the creation of an R5 repository much more complicated (and still
does not remove the need for the features definition), while simply
generating the features is much easier.
I wonder how the R5 repository generation is supposed to fit in a
release model when developing with bndtools. Unless they don't have any
answer yet. If the idea is to use a single big repository, then that
would be very problematic.
Btw, I've just committed the fix for relative resource uris and support
for <resource-repository> in the features repositories.
Feel free to experiment !
What we would need is the input that was given to the bndtooling
during resolution / validation.
If we have this, we could certainly have a successful resolution
too.
Tough having a list of bundles, i.e. the output of the
resolution would work too.
Yes I think both approaches could have their place.
For the application mode the fully resolved list of bundles could be
great. We could then even start a karaf without the feature service
and use startup.properties to list the bundles.
Another approach would be to create a feature from the resolved
bundle list.
In both cases a problem is that karaf already starts with some
bundles. So for the first approach we would need to somehow add
these bundles either already in bndtools or later.
For the second approach we would probably want to remove the initial
bundles from the feature. Maybe they could also just stay there ..
not sure though.
Christian
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
