I don't think we really need to take a decision on this point. If there 's a bug we need, which is specific to the karaf usage of the resolver, we can temporarily embed it. If the fix is an OSGi framework problem, we'll need to have it in both felix and equinox, so it does not really matter.
For the pending fix, if equinox decides to leave it out, or if we want a bug fix release before that, I don't have any problem. The same could be true for the work I've been working on those past days (resolver optimisation, see discussion on the felix dev list). For framework level resolution, those are usually fast enough, but the fact that the karaf resolver resolves everything at the same time can lead to resolution times of 10s or so, which is way too long, so we could also decide to embed the new resolver in karaf in case it takes too long to have it part of felix and equinox. In short, I don't have any problem embedding it, we don't even have to change the packages imports / exports afaik, it's just a matter of embedding the implementation classes and use a constructor instead of a service tracker. If we do that more than once, we may want to leave the two code path easily available, so that the switch would be a simple property in maven or something like that. That said, I think it may be a per-release decision, I'd rather not embed it if there's no need, just as a work around. 2015-06-26 15:26 GMT+02:00 Christian Schneider <[email protected]>: > Currently we use the resolver that is embedded into the OSGi framework. > While this is a good way to avoid having duplicated code int the runtime > this approach has some big problems: > > 1. It takes longer to get resolver fixes or enhancements into karaf as we > first have to get a release of resolver and then of the framework. Equinox > releases are only every 6 months. > 2. Resolver changes need a framework release to be useable in karaf > releases. As some of the changes are only necessary for karaf the framework > maintainers might not do a release just for us. > 3. The equinox framework might not contain all changes. I recently talked > to Thomas Watson on the equinox list. For the upcoming equinox release he > told me which changes they include and which they leave out. > > So we might have the situation that feature resolution works differently > depending on which framework you choose. > > So I wonder if we should switch back to embedding the resolver into > feature core. > > Christian > >
