Hi Brian,
is your project configuration a multi module project? If so, I guess
this is a nice solution. If you release all your modules at the same
time, you will never have dependency conflicts. Disadvantage of that
approach is, that you sometimes release moduls without a change. Am I right?
Mario
Am 29.09.2010 00:42, schrieb Brian Smith:
Hi Mario
Unless I'm misunderstanding - I do 2) for dependencies of external libraries
plus 4) for dependencies on my own modules.
I only specify versions of external dependencies in dependencyManagement in
the parent, and do so with properties so they're convenient to change.
Child poms just inherit versions from the parent dependencyManagement.
I keep the versions of my own modules as SNAPSHOT of the next version, until
release time and then release them all with the same version.
Then set the versions to SNAPSHOT for the next (likely) version.
This way I only maintain dependency versions in one place and everything
that is released is consistent.
I haven't needed version ranges or found diffcult conflicts despite
depending on dozens of your fairly common java libraries.
Hope that helps
Brian
On 28 September 2010 22:29, Mario Wirth<[email protected]> 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-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges
)
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]
