Sorry, for the misleading post. I declare all dependencies, which are
needed for compile in the project's pom (not parent pom). I trust on
maven's conflict resolution and don't use Dependency Management at all
at the moment. The reason for that I have described already: I don't
want to release the parent pom and update the new version number in each
child. If I don't do that, former builds are not repeatable.
But if you trust maven's conflict resolution, it can lead to the
following situation:
There are 3 projects and their releationship:
A-1.0.0 → B-1.0.0 → C-2.0.0
In addition A as the following dependency:
A-1.0.0 → C-1.0.0
If project A is a war, it's lib folder will include B-1.0.0 and C-1.0.0.
But B-1.0.0 needs classes which are only available in C-2.0.0.
Consequence: You will get an exception at runtime.
With version ranges you can avoid that. You have to write in the POM of
B → C[2.0.0, 2.1). Maven will consider this additional information and
select version C-2.0.0.
But version ranges lead to other problems. You need correct meta-data
and you have to create a release pom to resolve the version ranges at
release time. (see:
http://maven.apache.org/plugins/maven-release-plugin/prepare-with-pom-mojo.html)
I really would like to use version ranges, but I read very often in this
forum: Avoid version ranges! (the post of Michael McCallum is an
exception ;-) ) I am not sure if it's the maven way.
On the other hand: If you do the dependency management manually, you use
Maven just to download the artifacts. Is that the maven way?
Thanks,
Mario
Am 29.09.2010 15:27, schrieb Yanko, Curtis:
I do find it surprising that your saying declaring a dependency is *only
a wish*? A declared dependency *should be* closest to the root, our do
you make your declarations in a Parent POM?
We too used to *factor up* any shared dep to the Parent but have stopped
since it creates a couple of issues, yours being just one of them.
2.Use Dependency Management. In my parent pom I can declare all
dependencies and their versions. Advantage: I have full control of
the dependencies in the child moduls. Disadvantage: If I need to
change a version of a particular dependency, I need to release a
new version of the parent pom and afterwards I have to update the
version number in all child projects which need the new version of the
dependency.
If you are declaring versions in depMgmnt, don't put a version in the
project pom dependency. Work with a SNAPSHOT POM version until you have
what you want, then RELEASE it, to nail it down.
I don't advocate version ranges at all since your build may not be
re-produceable if you do.
________________________________
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
-----Original Message-----
From: Michael McCallum [mailto:[email protected]]
Sent: Tuesday, September 28, 2010 5:51 PM
To: Maven Users List
Subject: Re: What is your strategy to manage dependencies?
I highly recommend using version ranges, in fact i wonder how people
work without them, it must be really hard to keep track of all the
dependencies.
On Wednesday 29 September 2010 10:29:36 Mario Wirth wrote:
Thank you Antonio,
for your response. But is this really the only solution? Is there no
plugin or technique available which helps to avoid (binary)
compatibility conflicts between artifacts?
Can anyone recommend the use of version ranges?
Thanks,
Mario
Am 24.09.2010 09:47, schrieb Antonio Petrelli:
5. Use released versions if possible and resolve conflicts one by
one.
Antonio
2010/9/24 Mario Wirth<[email protected]>:
Hi community,
I am interested in your strategy, how to use Maven to make sure,
all artifacts are selected in the right version.
By default, if you add a dependency with it's version, that is only
a wish.
Maven is allowed to change the artifact to a newer or an older
version. It depends on the dependency tree and the distance to the
root. (see:
http://www.sonatype.com/books/mvnref-book/reference/pom-relationshi
ps-sect-project-dependencies.html#pom-relationships-sect-version-ra
nges)
As a consequence, sometimes my war file contains libs which do not
fit together. The following solutions I've figured out so far:
1.Declare all needed dependencies in the pom of the war file.
Disadvantage:
I have to do the work manually.
2.Use Dependency Management. In my parent pom I can declare all
dependencies and their versions. Advantage: I have full control of
the dependencies in the child moduls. Disadvantage: If I need to
change a version of a particular dependency, I need to release a
new version of the parent pom and afterwards I have to update the
version number in all child projects which need the new version of
the dependency.
3.Use Version Ranges. Advantage: With version ranges I can add more
specific informations for Maven. This is used to support the
conflict resolution and maven only selects artifacts which satisfy
all version ranges. Advantage:
conflict resolution does not cause (binary) incompatibilty between
the artifacts, if the version ranges are set correct. Disadvantage:
There is more effort during the release process: you need to build
a release pom with resolved version ranges to make the build
repeatable. You have to hide Snapshots during the release process,
if you use boundaries like [4.0,). And finally, maven needs
additional meta data from the repository. If the meta data are not
up to date, strange behaviour can happen.
4.Use only snapshots. If I use only snapshot versions, the latest
version is always used. Disadvantage: Developing against snapshots
can be frustrating because of the nature of snapshots ;-) But you
will find out very fast, if something is binary incompatible.
So, I am very interested in the best practise! How do you solve the
problem to manage all dependencies in their correct version. Thank
you for your suggestions in advance.
Mario
-------------------------------------------------------------------
-- To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--------------------------------------------------------------------
- To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
