Package import merging [was: Re: [jira] Commented: (FELIX-1197) Bundle Fragments not resolved correctly]

[Glyn Normington <gl...@springsource.com>]

I don't know how imported the conflict detection mentioned below is,  
but I wrote a bunch of code to merge groups of package imports from  
various sources and throw helpful exceptions identifying any conflict  
together with the original sources of the conflict. Merging computes  
the intersection of version ranges and squares up other attributes and  
directives. Currently, this is in the GPL portion of dm Server, but if  
it would help, I could look into migrating it down into the Apache  
licensed util area for Felix to reuse or fork.

If and only if you are comfortable looking at GPL source code, see [1]  
and the other classes in the same directory. If you're not  
comfortable, I'm happy to answer any questions here.

Glyn

[1] https://src.springsource.org/svn/dm-server-kernel/main-branches/jersey/com.springsource.kernel.osgi/src/main/java/com/springsource/kernel/osgi/framework/support/merge/TrackedPackageImports.java

On 3 Jun 2009, at 16:16, Richard S. Hall (JIRA) wrote:

>
>    [ https://issues.apache.org/jira/browse/FELIX-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715947 
> #action_12715947 ]
>
> Richard S. Hall commented on FELIX-1197:
> ----------------------------------------
>
> You mention that your fragments import nearly the same packages, Be  
> aware that Felix fragment import conflict detection currently  
> requires overlapping imports of fragments to be identical (i.e.,  
> same package, version range, attributes, and directives). If not,  
> then it will not allow it.

Re: Package import merging [was: Re: [jira] Commented: (FELIX-1197) Bundle Fragments not resolved correctly]

[Glyn Normington <gl...@apache.org>]

Hi Richard

On 4 Jun 2009, at 00:13, Richard S. Hall wrote:

> The issue is, I need to determine whether or not a given fragment  
> conflicts with the existing host or other fragments or else I cannot  
> attach it. Currently, the approach I take is quite simplistic, which  
> is just requiring any overlapping Import-Package or Require-Bundle  
> to be identical (i.e., I allow that, anything else I reject  
> attaching the fragment).
>
> If/when necessary, I contemplate getting around this by just trying  
> to satisfy all dependencies and just look for interesting candidates  
> on overlapping ones, but it doesn't seem necessary now.

That's equivalent to my approach when dependencies can be satisfied,  
but when the combination of dependencies is simply unsatisfiable  
because of conflicts, I wanted to provide specific feedback about the  
clash and where the clash arose from rather than generic feedback  
about the failure to resolve dependencies. Anyway, I simply wanted to  
bring up this approach and the available code.

Regards,
Glyn

Re: Package import merging [was: Re: [jira] Commented: (FELIX-1197) Bundle Fragments not resolved correctly]

["Richard S. Hall" <he...@ungoverned.org>]

The issue is, I need to determine whether or not a given fragment 
conflicts with the existing host or other fragments or else I cannot 
attach it. Currently, the approach I take is quite simplistic, which is 
just requiring any overlapping Import-Package or Require-Bundle to be 
identical (i.e., I allow that, anything else I reject attaching the 
fragment).

If/when necessary, I contemplate getting around this by just trying to 
satisfy all dependencies and just look for interesting candidates on 
overlapping ones, but it doesn't seem necessary now.

-> richard

On 6/3/09 8:56 AM, Glyn Normington wrote:
> I don't know how imported the conflict detection mentioned below is, 
> but I wrote a bunch of code to merge groups of package imports from 
> various sources and throw helpful exceptions identifying any conflict 
> together with the original sources of the conflict. Merging computes 
> the intersection of version ranges and squares up other attributes and 
> directives. Currently, this is in the GPL portion of dm Server, but if 
> it would help, I could look into migrating it down into the Apache 
> licensed util area for Felix to reuse or fork.
>
> If and only if you are comfortable looking at GPL source code, see [1] 
> and the other classes in the same directory. If you're not 
> comfortable, I'm happy to answer any questions here.
>
> Glyn
>
> [1] 
> https://src.springsource.org/svn/dm-server-kernel/main-branches/jersey/com.springsource.kernel.osgi/src/main/java/com/springsource/kernel/osgi/framework/support/merge/TrackedPackageImports.java 
>
>
> On 3 Jun 2009, at 16:16, Richard S. Hall (JIRA) wrote:
>
>>
>>    [ 
>> https://issues.apache.org/jira/browse/FELIX-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715947#action_12715947 
>> ]
>>
>> Richard S. Hall commented on FELIX-1197:
>> ----------------------------------------
>>
>> You mention that your fragments import nearly the same packages, Be 
>> aware that Felix fragment import conflict detection currently 
>> requires overlapping imports of fragments to be identical (i.e., same 
>> package, version range, attributes, and directives). If not, then it 
>> will not allow it.