[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dash-dev] Version ranges or exact versions
|
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
On 11-03-20 05:35 AM, Alex Blewitt wrote:
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
_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dash-dev
