Hi Karl,
> I like the way you hide the bundleprotectiondomain
There are various other changes like this. Also the Module has changed
from immutable to mutable (i.e. it now has some setters). A possible way
forward would be to provide abstract classes for the interfaces (as I
did) and only have protected setters on those classes. In that way a
client of the resolver would have an immutable view, but an implementor
of the extension points can write.
With git it is very easy to provide a pach for what I did. If you like I
can do that, but perhaps it would equally be easy for you to clone the
jbosgi320 branch and do the 'git diff' yourself.
I could also continue on that branch and move forward in a direction
that we previously aggreed on.
cheers
-thomas
PS: I'll probably meet with Richard in Ottawa next month.
On 06/10/2010 10:43 AM, Karl Pauls wrote:
On Thu, Jun 10, 2010 at 9:57 AM, Thomas Diesler
<[email protected]> wrote:
Hi Folks,
The JBossOSGi Framework now sucessfully integrates the Felix Resolver.
Cool :-)
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.
Well, we are not yet done with factoring out the resolver...
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)
Indeed, the idea is to make the resolver available standalone
eventually. The main reason we didn't do it right now is that we first
want to feel confident that we can support the api. Its great if
people start to use it but having it inside the framework for now
emphasises the fact that it is still in an "might be changed for any
internal reason" state.
Anyways, now that we have felix 3.0.0 almost out of the door we should
be able to get back to the resolver api soon. Great to know that we
seem to be almost there in regard to being usable outside of the
framework. I like the way you hide the bundleprotectiondomain - didn't
think of it before. Nice.
regards,
Karl
more ...
https://community.jboss.org/thread/152983?tstart=0
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
