| Circular Component Dependency Issue with JDT [message #692202] |
Sun, 03 July 2011 22:03  |
 Chris Eagan
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
While attempting to re-base our product on Eclipse 3.7, I updated our Buckminster RMap to point to the new 3.7 update sites and attempted to Import and resolve a new Target platform. I ran into the following issue which I was able to re-create by using the simple RCP Mail app and adding a dependency to it on org.eclipse.jdt.core.
Circular component dependency detected. Chain is com.example.sample.releng -> com.example.sample.site -> com.example.sample -> com.example.sample -> org.eclipse.jdt.core -> org.eclipse.jdt.ui -> org.eclipse.jdt.launching -> org.eclipse.jdt.core
This issue also appeared if I added a dependency on org.eclipse.jet:
Circular component dependency detected. Chain is com.example.sample.releng -> com.example.sample.site -> com.example.sample -> com.example.sample -> org.eclipse.jet -> org.eclipse.emf.codegen -> org.eclipse.jdt.launching -> org.eclipse.jdt.core -> org.eclipse.jdt.ui -> org.eclipse.jdt.launching
I feel like this is a problem in the p2 update site more than it is an issue with Buckminster. Does any know how to work around this issue?
The Eclipse Project Release Notes mention that some of the components in eclipse actually have circular dependencies.
Quote:PDE will not unzip source zips of some plug-ins
In the plug-in import wizard, when you choose to import plug-ins as "projects with source folders", PDE will not unzip the source for the org.apache.ant, org.eclipse.core.runtime.compatibility.registry, org.eclipse.osgi.util and org.eclipse.osgi.services. This is because the source ZIPs contains code that will not compile when unzipped as it requires additional JARs that are not part of the SDK. To avoid the creation of plug-in projects that won't compile, PDE will import these plug-ins as binary and attach source, so you would still be able to read the source, you just won't be able to modify it. Also, PDE will not unzip the source for the org.eclipse.swt plug-ins. In this case, it is because, when shipped, the swt code is spread across a plug-in and a fragment, and when unzipped, it will require circular dependencies between the plug-in and fragment projects. These circular dependencies are at minimum marked as warnings by the JDT compiler and may result in unpredictable build behavior. Therefore, PDE always imports org.eclipse.swt as binary with source attached. (bug 66314)
|
|
|
| Re: Circular Component Dependency Issue with JDT [message #692266 is a reply to message #692202] |
Mon, 04 July 2011 04:21  |
|
Hi Chris,
We're using org.eclipse.jdt.core in our own build and we don't encounter
this problem. I checked the p2 meta-data and there is no dependency from
org.eclipse.jdt.core to org.eclipse.jdt.ui.
We're using org.eclipse.jdt.core version 3.7.0.v_B61 obtained from
http://download.eclipse.org/eclipse/updates/3.7. What are you using?
- thomas
On 2011-07-04 00:03, Chris Eagan wrote:
> While attempting to re-base our product on Eclipse 3.7, I updated our
> Buckminster RMap to point to the new 3.7 update sites and attempted to
> Import and resolve a new Target platform. I ran into the following issue
> which I was able to re-create by using the simple RCP Mail app and
> adding a dependency to it on org.eclipse.jdt.core.
>
> Circular component dependency detected. Chain is
> com.example.sample.releng -> com.example.sample.site ->
> com.example.sample -> com.example.sample -> org.eclipse.jdt.core ->
> org.eclipse.jdt.ui -> org.eclipse.jdt.launching -> org.eclipse.jdt.core
>
> This issue also appeared if I added a dependency on org.eclipse.jet:
>
> Circular component dependency detected. Chain is
> com.example.sample.releng -> com.example.sample.site ->
> com.example.sample -> com.example.sample -> org.eclipse.jet ->
> org.eclipse.emf.codegen -> org.eclipse.jdt.launching ->
> org.eclipse.jdt.core -> org.eclipse.jdt.ui -> org.eclipse.jdt.launching
>
> I feel like this is a problem in the p2 update site more than it is an
> issue with Buckminster. Does any know how to work around this issue?
>
> The http://www.eclipse.org/eclipse/development/readme_eclipse_3.7.html
> mention that some of the components in eclipse actually have circular
> dependencies.
>
> Quote:
>> PDE will not unzip source zips of some plug-ins
>>
>> In the plug-in import wizard, when you choose to import plug-ins as
>> "projects with source folders", PDE will not unzip the source for the
>> org.apache.ant, org.eclipse.core.runtime.compatibility.registry,
>> org.eclipse.osgi.util and org.eclipse.osgi.services. This is because
>> the source ZIPs contains code that will not compile when unzipped as
>> it requires additional JARs that are not part of the SDK. To avoid the
>> creation of plug-in projects that won't compile, PDE will import these
>> plug-ins as binary and attach source, so you would still be able to
>> read the source, you just won't be able to modify it. Also, PDE will
>> not unzip the source for the org.eclipse.swt plug-ins. In this case,
>> it is because, when shipped, the swt code is spread across a plug-in
>> and a fragment, and when unzipped, it will require circular
>> dependencies between the plug-in and fragment projects. These circular
>> dependencies are at minimum marked as warnings by the JDT compiler and
>> may result in unpredictable build behavior. Therefore, PDE always
>> imports org.eclipse.swt as binary with source attached. (bug 66314)
>
|
|
|
|
| Re: Circular Component Dependency Issue with JDT [message #692571 is a reply to message #692549] |
Mon, 04 July 2011 18:43 |
|
On 2011-07-04 19:57, Chris Eagan wrote:
> I did a bit more experimentation based on your comments. I was able to
> get the circular error to go away by changing my rmap. In 3.6, we used both
>
> http://download.eclipse.org/releases/helios
> http://download.eclipse.org/eclipse/updates/3.6
>
> but we placed the updates site above the other in the rmap, assuming
> that Buckminster would use the first valid site it found. It appears
> that Buckminster is actually looking at all the sites within a Search
> Path and selecting the best match.
Yes, Buckminster will consult all providers within a searchPath and
select the best match. The orders does not matter. If you want to impose
order, you should use a sequence of locators with failOnError set to false.
> Something appears to go wrong when
> both /releases/indigo is included in the Search Path.
>
We're using Indigo too without problems. The org.eclipse.jdt.core in
indigo is the same as at eclipse/updates/3.7.
> I removed /releases/indigo from my RMap and the circular dependency went
> away. Using only /releases/indigo causes the circular error to return.
>
Would it be possible for you to attach a failing cquery+rmap combination
to a bugzilla?
- thomas
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02513 seconds
] 
Search
Help
Register
Login
Home
