Curtis, can you please explain what you do, if a developer asks for a
new version of a dependency?
Will you than update the dependency management section of the parent pom
and create a release of the parent pom? If you don't do a release, you
will overwrite the parent pom and lose your old dependency
configuration. As a consequence you are not able to repeat a former
build of the project.
Mario
Am 29.09.2010 15:11, schrieb Yanko, Curtis:
We use an idiom whereby we don't declare any version in the dependency
itself but use the depMgmnt section in a project level POM to *pin*
versions.
________________________________
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]
