Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (nike.apache.org: domain of heavy@ungoverned.org designates
 67.222.54.6 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ungoverned.org;
	h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User;
	b=RqwGzPcpkeZxL35iVTTljEzbEb/hMuxIBE5Jeqdkz9/CmAJp0r/gFBojK8BFEkUt5b2wBryvI2AmU3sKZUGB4B9QZmrgeaDmZIzXC/RCUoxLbLn6Zn1WIIvdTa30cszk;
Message-ID: <4C10E986.9000006@ungoverned.org>
Date: Thu, 10 Jun 2010 09:32:54 -0400
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5
MIME-Version: 1.0
To: Thomas Diesler <thomas.diesler@jboss.com>
CC: dev@felix.apache.org, bgeorges@redhat.com
Subject: Re: Apache Felix Resolver integration
References: <4C109AF9.3030108@jboss.com>
In-Reply-To: <4C109AF9.3030108@jboss.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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