Why aren't you using dependencyManagement instead of the technique shown
below?
Michael McCallum wrote:
On Sun, 22 Jun 2008 18:16:37 Ralph Goers wrote:
This is one of the problems that has bothered me for a while. It makes
no sense for a project to say I'm compatible with 3.8.x. How in the
world could they know that? The dependent project might release a new
3.8.x release that isn't compatible. Thus, for any kind of version range
to have any meaning, projects must declare what prior versions they are
compatible with using a declaration that isn't part of the current pom
syntax. Then when a project specifies a dependency on 3.8.1 if there is
a 3.8.2 that specifies it is compatible with any prior 3.8.x release it
would be fine to use 3.8.2 in the project with the dependency. Without
such a specification, in my opinion version ranges aren't particularly
useful.
I get around this by wrapping a well defined version around a strict range
e.g.
i have a special pom project that holds the version of spring that all my
projects should use currently at 7.1 which says use 2.0.7
so all my projects use a range of
<dependency>
<version>[7,8-!)</version>
<groupId>my.domain.constraint</groupId>
<artifactId>my.domain.constraint.spring</artifactId>
</dependency>
and my.domain.constraint.spring is defined in brief as
<project ...>
...
<dependency>
<version>[2.0.7]</version>
<groupId>org.springframework</groupId>
<artifactId>context</artifactId>
</dependency>
...
</project>
the only overhead to this is a few extra artifacts with no code... hardly a
major... there is also the added bonus that you have a convenient place to
control exclusions like... commons-logging
having read more of the thread... most of the apache projects are small and
have fairly simple trees you can get away with locking vrsion down simply. In
my case the trees are fairly horendous and using various pattern and
refactoring techiniques was necessary to get clean consistent trees.
It does mean that I encapsulate the the third party version as shown above and
it also lets me guarantee that dependency graph produced by spring,
hibernate, jmx, etc etc is the same when used in all my other projects. Each
time there is a new release I can just do depedency:resolve and/or
depedency:tree and make sure the trees look the same and then run tests on
all my projects against the new version to ensure nothing breaks. If
something does I can decide to bump the major version of the 'constraint'
project or fix the problem in the broken project...
i don't think that you can ever make a generic solution to this problem you
always need a flexible solution close to home, because ultimately you need to
manage when and where things change if you ever hope to produce stable
software in a timely fashion.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
