[dash-dev] Version ranges or exact versions

[Alex Blewitt]

This was mentioned in a different thread but I wanted to get the discussion going on this point specifically. (Cc'ing Jason in case he has thoughts on this too.)

The dependency problem is this: do we copy the ranges expressed by the manifest into Maven, or do we replace it with an explicit version:

<version>[3.2,4.0)</version>
<version>3.2.1</version>

The former, while valid, tends to be used less frequently. In addition, it will resolve (by looking at the maven metadata) at the *latest* build which may not be what we want.

Consider compiling against JDT UI, which needs JDT Core, for Ganymede. We would have in our code:

<dep><art>JDT.UI</dep><ver>3.5</ver></dep>

JDT UI would have:

<dep><art>JDT.Core</art><ver>[3.5,4.0)</ver></dep>

This would consult the latest, find Helios' release, and download JDT.Core 3.6.

So now we have JDT UI from Ganymede and JDT Core from Helios. This is not only an untested combination but there may be internal dependencies which don't follow the rule of compatibility, especially since these combinations aren't put to the test.

One can argue that range should be tighter but you could eg argue for the 3.6.1 vs 3.6.2 dependency as well.

Finally, version ranges demonstrate the fact you don't get repeated builds since what you build against is dependent on what the state the repository is in. This doesn't matter if you always want the latest and greatest because they are equivalent; but we have cases where people want to build against previous versions (especially when building +1) for compatibility reasons.

If we do go down the version range route we may want to have separate repo for each major release (eg /releases/helios and /releases/ganymede) so that when using a range you can restrict yourself to just that set. I don't believe this will be necessary if we are recording individual values in dependencies.

Finally, a hybrid approach might be to record the ranges in the poms and provide a dependencyManagement set which records explicit versions for Helios releases. Could we export this in some easy to consume way like having a pom.xml for Helios as a whole?

Alex

Sent from my iPhone 4

[Igor Fedorenko]

You can use dependency with scope=import to reuse predefined
<dependencyManagement/> section in multiple projects. This blog [1] is
supposed to explain how to do this, but formatting seems to be off :-(

Beware that unlike OSGi and P2, Maven does not attempt to optimise
dependency versions. If the same dependency is present multiple times in
project's dependency graph, Maven will use the first version it finds
while traversing the graph. <dependencyManagement/> is the mechanism a
project can use to force desired dependency version.

This is not strictly related to versions, but, out of curiosity, how do
you plan to deal with swt and swt fragments?

[1]
http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/

--
Regards,
Igor

Post by Alex Blewitt
This was mentioned in a different thread but I wanted to get the discussion going on this point specifically. (Cc'ing Jason in case he has thoughts on this too.)
<version>[3.2,4.0)</version>
<version>3.2.1</version>
The former, while valid, tends to be used less frequently. In addition, it will resolve (by looking at the maven metadata) at the *latest* build which may not be what we want.
<dep><art>JDT.UI</dep><ver>3.5</ver></dep>
<dep><art>JDT.Core</art><ver>[3.5,4.0)</ver></dep>
This would consult the latest, find Helios' release, and download JDT.Core 3.6.
So now we have JDT UI from Ganymede and JDT Core from Helios. This is not only an untested combination but there may be internal dependencies which don't follow the rule of compatibility, especially since these combinations aren't put to the test.
One can argue that range should be tighter but you could eg argue for the 3.6.1 vs 3.6.2 dependency as well.
Finally, version ranges demonstrate the fact you don't get repeated builds since what you build against is dependent on what the state the repository is in. This doesn't matter if you always want the latest and greatest because they are equivalent; but we have cases where people want to build against previous versions (especially when building +1) for compatibility reasons.
If we do go down the version range route we may want to have separate repo for each major release (eg /releases/helios and /releases/ganymede) so that when using a range you can restrict yourself to just that set. I don't believe this will be necessary if we are recording individual values in dependencies.
Finally, a hybrid approach might be to record the ranges in the poms and provide a dependencyManagement set which records explicit versions for Helios releases. Could we export this in some easy to consume way like having a pom.xml for Helios as a whole?
Alex
Sent from my iPhone 4
_______________________________________________
dash-dev mailing list
https://dev.eclipse.org/mailman/listinfo/dash-dev

[Alex Blewitt]

Post by Igor Fedorenko
You can use dependency with scope=import to reuse predefined
<dependencyManagement/> section in multiple projects. This blog [1] is
supposed to explain how to do this, but formatting seems to be off :-(
Beware that unlike OSGi and P2, Maven does not attempt to optimise
dependency versions. If the same dependency is present multiple times in
project's dependency graph, Maven will use the first version it finds
while traversing the graph. <dependencyManagement/> is the mechanism a
project can use to force desired dependency version.

So we could have (say):

<dependency>
<artifactId>org.eclipse.release.helios</artifactId>
<groupId>org.eclipse.release</groupId>
<version>3.6.0</version>
<type>pom</type>
</dependency>

and then all the dependencies could depend on that to consume a common dependencyManagement set:

<project>
<artifactId>org.eclipse.release.helios</artifactId>
<groupId>org.eclipse.release</groupId>
<version>3.6.0</version>
<packaging>pom</packaging>
<dependencyManagement>
<dependency>
<artifacIdt>org.eclipse.jdt.core</artifactId>
<groupId>org.eclipse.jdt</groupId>
<version>3.6.0</version>
</dependency>
</dependencyManagement>
</project>

Would you then in the POM encode the dependency version as a range, and let the import of the release constrain what element in the range is used?

Post by Igor Fedorenko
This is not strictly related to versions, but, out of curiosity, how do
you plan to deal with swt and swt fragments?
[1] http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/

Probably something we still have to figure out.

Alex

[Igor Fedorenko]

Post by Alex Blewitt

Post by Igor Fedorenko
You can use dependency with scope=import to reuse predefined
<dependencyManagement/> section in multiple projects. This blog [1] is
supposed to explain how to do this, but formatting seems to be off :-(
Beware that unlike OSGi and P2, Maven does not attempt to optimise
dependency versions. If the same dependency is present multiple times in
project's dependency graph, Maven will use the first version it finds
while traversing the graph.<dependencyManagement/> is the mechanism a
project can use to force desired dependency version.

<dependency>
<artifactId>org.eclipse.release.helios</artifactId>
<groupId>org.eclipse.release</groupId>
<version>3.6.0</version>
<type>pom</type>
</dependency>

I believe <scope>import</scope> is required in the above <dependency/>
element.

Post by Alex Blewitt
<project>
<artifactId>org.eclipse.release.helios</artifactId>
<groupId>org.eclipse.release</groupId>
<version>3.6.0</version>
<packaging>pom</packaging>
<dependencyManagement>
<dependency>
<artifacIdt>org.eclipse.jdt.core</artifactId>
<groupId>org.eclipse.jdt</groupId>
<version>3.6.0</version>
</dependency>
</dependencyManagement>
</project>
Would you then in the POM encode the dependency version as a range, and let the import of the release constrain what element in the range is used?

I don't think it really matters, as <dependencyManagement/> overrides
all dependency versions. I think it is even possible to omit <version/>
element altogether, which will force all consumers to specify
<dependencyManagement/> via scope=import or explicitly.

--
Regards,
Igor

[Aaron Digulla]

Post by Igor Fedorenko
I don't think it really matters, as <dependencyManagement/> overrides
all dependency versions. I think it is even possible to omit <version/>
element altogether, which will force all consumers to specify
<dependencyManagement/> via scope=import or explicitly.

I didn't know about scope=import; that sounds really interesting. This
explains the background:

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies

That would be a viable solution. The idea not to specify any version at
all (forcing users to specify it) also sounds interesting but I think
that will only work for top dependencies. People will not want to figure
out version 3.1.100 of some core plugin which is pulled in by the 5th
level of dependency resolution when they ask for x.y.z:3.6.2.

I've posted a question on SO to get more ideas:
http://stackoverflow.com/questions/5371174/importing-eclipse-bundles-into-maven-how-to-map-versions

Regards,