On 5/3/09 10:35 AM, Filippo Diotalevi wrote:
On Sun, May 3, 2009 at 3:41 PM, Richard S. Hall<he...@ungoverned.org> wrote:
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 don't know the implementation details, but if the fragment imports a
package that is already imported by the host, I would consider it just
redundant and not a conflict (maybe a WARNING to explain that the
import is not needed). Implementation wise, maybe you can just ignore
the redundant import (?).
That is only true if there is no conflict. For example, the host could
import foo;version=[1.0.0,1.0.0] and the fragment could import
foo;version=[2.0.0,2.0.0]. This would be impossible to resolve. Version
is just one attribute, but there could be conflicts with any attribute.
However, you are correct that we can treat an overlapping requirement as
redundant if, in the most general sense, we can find a candidate that
satisfies all overlapping requirements for a given package/require bundle.
Just noticed that the (infamous, by now ;-) hibernate bundle example
has the same problem for exports: f.i. the "org.hibernate.cfg" package
is exported by the host bundle and by 2 fragments. Haven't tested this
use case yet. Do you think it's complicated to support?
Exports do not pose a conflict at all, since a bundle is allowed to
export the same package more than once with different attributes. So,
this is only an issue for overlapping import packages and required bundles.
-> richard
