Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster » Solutions to "Circular Component Dependency Issue with JDT"
Solutions to "Circular Component Dependency Issue with JDT" [message #696509] Thu, 14 July 2011 06:36 Go to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
The Indigo release train contains two versions of the 'org.eclipse.jdt.core' bundle. One is provided by Object Teams and
has a dependency to 'org.eclipse.jdt.ui'. That in turn causes a circular dependency reported as:

org.eclipse.jdt.launching -> org.eclipse.jdt.core -> org.eclipse.jdt.ui -> org.eclipse.jdt.launching

The Object Team bundle will not normally be selected when installing since it in turn requires that a patch is selected
at the same time (it has a non-greedy requirement to this patch). The Buckminster resolver is however not sophisticated
enough to detect this and act on it. It's a fairly complex problem and being able to resolve it really shows the power
of the SAT resolver. The SAT resolver must however know about all components before it starts. Buckminster's objective
is to find them. We could consider finding all possible candidates and then invoke the solver but that won't fly either
since some components are in source form and incomplete (no generated version qualifiers nor ranges).

Buckminster's resolution is a "best effort", an approximation, and sometimes it needs a little help to do the right
thing. This is one of these times.

Unless you indeed want the Object Team's bundle (in which case you must allow circular dependency on o.e.jdt.launching),
there are three possible solutions:

1. Tweak your RMAP so that the eclipse/updates-3.7 is consulted before releases/indigo. Example:

End your chain of locators with the following two entries:

<rm:locator searchPathRef="platform" failOnError="false"/>
<rm:locator searchPathRef="indigo"/>

And include these two search paths:

<rm:searchPath name="platform">
<rm:provider componentTypes="osgi.bundle,eclipse.feature" readerType="p2" source="false">
<rm:uri format="http://download.eclipse.org/eclipse/updates/3.7/"/>
</rm:provider>
</rm:searchPath>
<rm:searchPath name="indigo">
<rm:provider componentTypes="osgi.bundle,eclipse.feature" readerType="p2" source="false">
<rm:uri format="http://download.eclipse.org/releases/indigo/"/>
</rm:provider>
</rm:searchPath>

This will ensure that the platform update site is consulted first. Buckminster will not query indigo for any component
found in platform.

2. If you don't want to tweak your rmap, you can instead add an advice node to your cquery that modifies any request for
the org.eclipse.jdt.core bundle, like so:

<cq:advisorNode
namePattern="^org\.eclipse\.jdt\.core$"
componentType="osgi.bundle"
versionOverride="[3.7.0.v_B61,3.7.0.v_B61]"/>

3. The third option is to include a dependency to a feature that explicitly requires the correct version of the
org.eclipse.jdt.core bundle.

For more info about this, please follow the bugzilla at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=351117

- thomas
Re: Solutions to &quot;Circular Component Dependency Issue with JDT&quot; [message #696828 is a reply to message #696509] Thu, 14 July 2011 22:05 Go to previous messageGo to next message
Carsten Reckord is currently offline Carsten Reckord
Messages: 139
Registered: July 2009
Senior Member
Hi Thomas,

Thanks for digging into this.

This problem made me stumble over another issue that made the JDT problem
hit particularly hard. I'll post it here, since it's not strictly related to
that particular bug:

My setup was

org.example.a.feature
org.example.b.feature
depends on jdt.core
org.example.c.feature
org.example.d.feature

In my cspec I had (due to my own messed up dependency graph):

<cq:advisorNode namePattern="^org\.example.*"
allowCircularDependency="true"/>
<cq:advisorNode namePattern=".*"/>

(so no explicit allowCircularDependency matching jdt).


This had the effect that the resolution ran fine and without any warnings,
but org.example.b.feature and all its dependencies were missing in the
materialization.

What really got me here was

a) no warning of any kind was issued
b) I expected that a resolution nested in another one that has
allowCircularDependency=true would implicitly have the same, which is not
the case. Instead everything up to (and including, which I believe is a bug)
the component allowing circular dependencies is just silently discarded...

I had to go hunting with the Debugger to find the cause in the JDT problem here.

Did I just shoot myself in the foot here really really well or is there
another bug at work?


Best regards,
Carsten
Re: Solutions to &quot;Circular Component Dependency Issue with JDT&quot; [message #696968 is a reply to message #696828] Fri, 15 July 2011 08:04 Go to previous message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
Hi Carsten,

If you have ideas on how the circular dependency mechanism could be improved then I suggest you enter a bugzilla for
that. I agree that what you describe here sounds far from ideal.

Regards,
Thomas Hallgren

On 2011-07-15 00:05, Carsten Reckord wrote:
> Hi Thomas,
>
> Thanks for digging into this.
>
> This problem made me stumble over another issue that made the JDT problem
> hit particularly hard. I'll post it here, since it's not strictly related to
> that particular bug:
>
> My setup was
>
> org.example.a.feature
> org.example.b.feature
> depends on jdt.core
> org.example.c.feature
> org.example.d.feature
>
> In my cspec I had (due to my own messed up dependency graph):
>
> <cq:advisorNode namePattern="^org\.example.*"
> allowCircularDependency="true"/>
> <cq:advisorNode namePattern=".*"/>
>
> (so no explicit allowCircularDependency matching jdt).
>
>
> This had the effect that the resolution ran fine and without any warnings,
> but org.example.b.feature and all its dependencies were missing in the
> materialization.
>
> What really got me here was
>
> a) no warning of any kind was issued
> b) I expected that a resolution nested in another one that has
> allowCircularDependency=true would implicitly have the same, which is not
> the case. Instead everything up to (and including, which I believe is a bug)
> the component allowing circular dependencies is just silently discarded...
>
> I had to go hunting with the Debugger to find the cause in the JDT problem here.
>
> Did I just shoot myself in the foot here really really well or is there
> another bug at work?
>
>
> Best regards,
> Carsten
Previous Topic:Howto use simple pool of bundle jars
Next Topic:Problems installing Buckminster on Indigo
Goto Forum:
  


Current Time: Thu Sep 18 09:51:18 GMT 2014

Powered by FUDForum. Page generated in 0.13602 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software