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@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
_______________________________________________
dash-dev mailing list
dash-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
