On 6/10/10 3:57, Thomas Diesler wrote:
Hi Folks,
The JBossOSGi Framework now sucessfully integrates the Felix Resolver.
The code for the resolver integration is here
http://github.com/jbosgi/jbosgi-framework/tree/master/resolver/src/main/java/org/jboss/osgi/framework/resolver
By design, this module does not have a dependency on the jboss
framework. Instead it extends the felix resolver API to cleanup and
provide the necessary extension points for an arbitary framework to
integrate with the felix resolver.
Unfortunately, some changes to the felix resolver API were necessary
to remove dependencies on felix framework internals.
I made those changes to the jbosg320 branch
<http://github.com/jbosgi/felix-framework/tree/jbosgi320> on the
felix-framework git-svn mirror
<http://github.com/jbosgi/felix-framework/network>. (You can click on
the blue dots to see the content of the individual commits)
Ideally, and over time those abstract classes in
org.jboss.osgi.framework.resolver would bubble up to the felix code
base and felix would provide a standalone resolver maven artifact that
is independent of the felix framework (I could help with that if needed)
Good news that you were able to do it.
As I've mentioned to you previously, the API for the resolver was not
completed for the 3.0 framework release, which is why our JIRA issue for
moving it to a separate module was pushed back to 3.2. However, that's
still the goal, to make it completely separate.
It looks like most of your changes relate to the precise issue that I
mentioned to you that needs to be fixed, which is how the resolver deals
with fragments. So, in that regard it is good, because assuming I can
fix it the way that I envision it, then it should resolve your issue for
the most part.
The reason you are seeing impl dependencies is because
FelixResolverState _is_ part of the framework impl, only the stuff in
the resolver package is part of the resolver. But this leads to the crux
of the issue, since FelixResolverState is needed to handle fragments.
Hopefully, we can fix that.
Thanks for your feedback.
-> richard
more ...
https://community.jboss.org/thread/152983?tstart=0
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
