Bugzilla – Full Text Bug Listing
| Summary: | org.eclipse.core eventually depends upon org.osgi.foundation which poops all over java.lang.* | ||
|---|---|---|---|
| Product: | [Technology] Dash | Reporter: | Chris West (Faux) <eclipse> |
| Component: | Maven | Assignee: | Project Dash Incoming bugs <dash-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | digulla, d_a_carver, thanh.ha |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Chris West (Faux)
Adding Aaron to the bug. Thanks, Dave.
Great ... Ok, what happens is this:
A while ago, part of Eclipse was imported into Maven Central. That import wasn't well fated for various reasons.
The problem is org.eclipse.equinox.app with "<version>[1.0.0,2.0.0)</version>" in org.eclipse.core.runtime-3.6.0.pom.
This plugin is available from both Maven Central (as 1.3.0.v20100512) and the testing POM (1.3.0.v20100512). The version range means: Pick whatever fits.
Unfortunately, those two versions are the same so Maven guesses (incorrectly in this case) that those two artifacts are the same -> doom.
1. Can you please try to add a dependencyManagement element to your parent/root POM? It should nail down the version to "1.3.1" (which is the version found on testing). Let me know if that works.
2. Import the huge dependency file from org.eclipse.dash:dependency-management:3.6.2 with:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.eclipse.dash</groupId>
<artifactId>dependency-management</artifactId>
<version>3.6.2</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependencies>
<dependencyManagement>
This nails down *all* versions at once. Please try this, too.
Yeah, I worked around this by dependencyManagementing it up to <version>[1.3.1,2.0.0)</version>. The question was, as it's trivial for you to do so, can you make it so I don't have to, please? :) e.g. Please make org.eclipse.core.runtime depend on equinox.app:[1.3.1,2.0.0)? (In reply to comment #3) > Yeah, I worked around this by dependencyManagementing it up to > <version>[1.3.1,2.0.0)</version>. > > The question was, as it's trivial for you to do so, can you make it so I don't > have to, please? :) I could add a patch, no problem. But ... It would only solve this issue. There are thousands of similar issues all over the repo. In the end, all of those need to be fixed. But I don't the correct solution in all cases. So you have to use dependencyManagement anyway. If I leave it like this, builds will fail early, people will stumble over this issue and learn "oh, we have to use dependencyManagement" and the issue is fixed for all cases. Example: Some bundles depend on commons-logging 1.1 and some on 1.1.1. Those are simple: 1.1.1 is compatible with 1.1, so I could overwrite that. Others need javax.xml.bind 2.0 and other 2.2. Or javax.servlet 2.4 vs. 2.5. Here, the API changed. So I can't simply overwrite one version with the other. Consumers of the repository need to make an educated guess. On top of that, OSGi allows to include several versions of the same dependency in a project which doesn't work with Maven (OSGi uses several classloaders which avoids cross pollution while Maven doesn't). That's why I'm a bit reluctant to modify the existing versions and why I developed the solution with importing the huge dependencyManagement POM. If you can find a flaw in my chain of thought, I will reconsider my position. :-) maven.eclipse.org was decommissioned via bug 405750 and replaced with repo.eclipse.org. See: https://wiki.eclipse.org/Services/Nexus |