| Solutions to "Circular Component Dependency Issue with JDT" [message #696509] |
Thu, 14 July 2011 06:36  |
|
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 "Circular Component Dependency Issue with JDT" [message #696968 is a reply to message #696828] |
Fri, 15 July 2011 08:04  |
|
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
|
|
|
Powered by
FUDForum. Page generated in 0.03461 seconds
] 
Search
Help
Register
Login
Home
