Home/ Questions/Q 4321300
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T08:43:43+00:00

I’m working on Project Dash, specifically on a set of tools to import Eclipse

  • 0

I’m working on Project Dash, specifically on a set of tools to import Eclipse bundles (like org.eclipse.swt.gtk.linux.x86_64_3.6.2.v3659b.jar) into a Maven 2 repository. We ran the tools over the weekend and here is the result: A testing Maven 2 repository containing most of Eclipse 3.6.2.

During the conversion, we faced a problem without a simple solution: Most Eclipse bundles either don’t request a specific version or they request a version range. So we have both:

Require-Bundle: org.eclipse.core.runtime

and 

Require-Bundle: org.eclipse.core.runtime;bundle-version="[3.2.0,4.0.0)"

During the transformation, the tools collect all versions of all bundles, and if we need to write a POM for the upper example, we write out the version that we have collected (that would be 3.6.2 in this example). In the lower case, we leave the version range alone. No problem so far.

Now a new version comes out, say 3.7. When we convert that, a new version 3.7.0 of the first POM is created and it gets a dependency to org.eclipse.core:org.eclipse.core.runtime:3.7.0 while the second is created with the same version range as before.

Note: We have now four POMs (two for 3.6.2 and two for 3.7). One depends on core.runtime 3.6.2, one on 3.7.0 and two have the version range [3.2.0,4.0.0)

This is published and you don’t change anything on your side. You don’t update to 3.7.0!

Now we have a problem: If you use those two artifacts with version 3.6.2 in your build, then the first one will still use core runtime 3.6.2 since it’s version is locked.

But the second one will update the Maven metadata and see “oh, we have 3.7 for that, too”, download it and bang, you end up with org.eclipse.core:org.eclipse.core.runtime:3.7 and org.eclipse.core:org.eclipse.core.runtime:3.6.2 in your classpath without changing anything on your side.

That’s bad. How should we solve that?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Well, you’re not going to have both 3.7 and 3.6.2 in your classpath – Maven will take the highest version so you’d upgrade to 3.7 (which is probably not what the user of the Eclipse Maven artifacts wants or desires).

    Given that (as far as I know) Eclipse releases all of it’s components at the same time can’t you just ignore the bundle version range (from the second example) and hardcode the version dependency to the current release (like you’re doing for the first example)?

    • 0