felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Fragment support
Date Sun, 03 May 2009 13:41:06 GMT
The specification is somewhat vague on what it means for a fragment and 
host (or other fragments) to conflict. Initially I have taken a 
conservative view of this, so if there is any overlap at all I consider 
them to be in conflict.

It would be possible to loosen this up by allowing overlap if they the 
have exact same requirement, for example. You could even go further and 
try to see if you can find candidates that resolve overlapping 
requirements and only consider them conflicting if you cannot.

I am aware that I chose a stricter definition at this point, since it 
was easier for now and I need to try to release this soon. We can always 
open up an issue to loosen it up later.

What do you think?

-> richard

On 5/3/09 6:39 AM, Filippo Diotalevi wrote:
> On Sun, May 3, 2009 at 3:31 AM, Richard S. Hall<heavy@ungoverned.org>  wrote:
>> [..]
>> Please try out some fragments and give feedback.
>> I will likely need to push a release of this soon, since GF has some
>> requirements I need to address with it. So any feedback is welcome.
> Hi Richard,
>    I did a fair amount of testing on bundle fragment support yesterday
> and today, using both some home-made fragments and examples available.
> As Clement says, felix works fine with slf4j, but fails to resolve
> some "real world" fragments.
> Taking the usual hibernate bundle as an example, the 2 fragments are
> not resolved
> [   7] [Active     ] [    1] JBoss Hibernate Object-Relational Mapper (3.2.6.ga)
> [   9] [Installed  ] [    1] JBoss Hibernate Annotations (3.3.1.ga)
> [  10] [Active     ] [    1] JBoss Hibernate Common Annotations (3.3.0.ga)
> [  11] [Installed  ] [    1] JBoss Hibernate Entity Manager (3.3.2.GA)
> The reason is
> DEBUG: Excluding fragment com.springsource.org.hibernate.annotations
> from com.springsource.org.hibernate due to conflict with imported
> package org.apache.commons.logging from com.springsource.org.hibernate
> DEBUG: Excluding fragment com.springsource.org.hibernate.ejb from
> com.springsource.org.hibernate due to conflict with imported package
> javax.naming from com.springsource.org.hibernate
> In practice, when host and fragment share some imports (in the
> specific org.apache.commons.logging
> and javax.naming), fragments are not resolved.
> Specification wise, I think these double imports should be specified, since
> "Fragments are therefore treated as part of the host, including any
> permitted headers; they must not have their own class loader. "
> and
> " Append the import definitions for the Fragment bundle that do not con-
> flict with an import definition of the host to the import definitions of the
> host bundle. A Fragment can provide an import statement for a private
> package of the host. The private package in the host is hidden in that
> case.
> [..]
> A host and a fragment conflict when they cannot resolve to provide a consis-
> tent class space"
> but, as far as I see, it's quite common to find similar cases in
> already available bundles.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message