felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff McAffer <Jeff_McAf...@ca.ibm.com>
Subject Re: Felix M2 Plugin feedback
Date Tue, 20 Sep 2005 01:14:28 GMT
Daniel Fagerstrom <danielf@nada.kth.se> wrote on 09/19/2005 01:55:32 PM:

> Jeff McAffer wrote:
> > Daniel Fagerstrom <danielf@nada.kth.se> wrote on 09/19/2005 05:11:12 
> ...
> >>Another question: how should we handle dependencies?
> ...
> > All of this to illustrate that matching the compile-time structure to 
> > runtime structure is quite important.
> Now I remember that I have asked this before and that you answered:
> > Yes. One of the design points we put in a couple of releases ago was 
> > explicit separate State/Resolver API that tooling and installers can 
> > to model and explore prospective configurations of bundles.  This is 
> > exact resolver that the framework uses.  No claims that it is perfect 
> > check out org.eclipse.osgi.service.resolver.  It covers many usecases. 

> I don't know enough about OSGi framework implementation to have any 
> opinion about the API. But it would IMO make sense to reuse the work 
> from Eclipse or cooperate with Eclipse on this.
> If we where to use the org.eclipse.osgi.service.resolver APIs and your 
> implementation of it, is it possible to use standalone or does it 
> require large part of the Eclipse OSGi framework? Also it is not obvious 

> for me how to go from a couple of bundles and an implementation of the 
> State API to a classloader suited for compiling a bundle depending on 
> the bundles.

As you observed, the state and resolver were designed to be used 
standalone.  We have some uses that approximate this but they *happen* to 
still be running inside a framework.  Basically the PDE tooling uses the 
state and resolver to manage the target definition.  So technically it is 
running in OSGi but it is not modeling the current OSGi framework.  There 
may be a few minor gotchas in having it run completely separate but there 
shouldn't be anything major.

To be minimalist about it you would want to separate it out from the 
org.eclipse.osgi jar.  We have not bothered to try but again, there should 
not be any major issues.  It might drag along a few unfortunate helper 
classes but I'd be surprised if there was much.  (If there is we will try 
to fix that)  For initial experimentation I suggest you just use the whole 
OSGi jar and worry about carving the resolver out later.

If you want to look at the code, check out the org.eclipse.osgi project 
from dev.eclipse.org/home/eclipse and look in the following spots


It is broken up this way since the resolver is actually a pluggable part 
of the adaptor layer in our implementation.

I'll see if we can dig up some sample code for populating the state.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message