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<he...@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.
