Proper Dependency Management - HowTo?

Hi,

we got a software, which is devided into serveral sub projects.
We defined a parent pom, that, besides other shared items, contains a
dependency management section to ensure all sub projects are using the same
dependencies. Also, as the "software" we are talking about is actually a
website, there is never really something like a "final version" or so - the
product is constantly under development (with a monthly release cyclus).

Based on these preconditions, I figured out the following handling:
So far, we have the parent pom always as a SNAPSHT version, and did not
differ between different versions of the parent pom.
So far, we have all dependencies - external as well as internal depdencies
(the sub projects themself) under dependency management.
When someone wants to change the version of a specific sub project, he does
so by editing a property in the parent pom
<mysubprojectXY-version>1.11</mysubprojectXY-versionwhich, on the basis of
this property, will then change the version in depdency management,
as well as the version of the sub project itself (and so keep them in sync).
This ensures all subprojects are ALWAYS using exactly the same dependencies
- external ones from other
suppliers, as well as internal ones provides by ourself.

However, the problem now is that when someone changes something in some sub
project, he could hardly ensure this change will not conflict with a certain
other sub project that might also use this project (and as so far we only
have one version of the parent pom, all projects will always get the latest
version of the parent pom, and so will also always get all updates from all
sub projects)

1. Therefore, I suppose it was better if we were using different parent pom
versions, right?
In otherwords, if someone wants to change the version of a sub project, he
would also have to change the version of the parent pom, there he would
increment the version of the parent pom, as well as the version of the sub
project. When someone else wants to use the new paret pom, he would
deliberately change the parent pom he is using, and so he would know that he
had to check for version changes and their influences on his specific sub
project.

2. What about the version numbers of the sub projects?
a) Is it a good idea to have them entirely managed in the parent pom (by
using a property, which is used in dependency management section, as well
as in the sub project version itself?), or
b) Is it a better idea to hard code the version of a sub project in its pom?


Based on the strength of past experience, I suppose it was best to use
different parent pom version for every release, and in between to maybe use
snapshot version, plus to keep up the process of having internal as well as
external dependencies in dep. management, and to keep the version in dep.
management with the last version of a certain sub project in sync by using
properties.

Do you agree? do you suggest another approach?

Thanks in advance,

Peter

Could you be a bit more precise? (Just make it plain simple, this increases
the chance that I get it! ;-)

Thanks,

Peter

The problem I see with version ranges, is you start loosing control.
I guess the vital part to make the use of version ranges work (at all) is
that every developer has to follow the rule

major.minor.patch

So far, we have been very loose with versions - Someone changes 5 lines in
the code, makes a new (patch) version, someone else changes another 7 lines,
makes another (patch) version, and so on - we keep on "patching" the jar -
1.3.57 - I wonder when we will hit a hundred or a thousand! ;-)

So I guess if EVERY developer would only use the "patch section" if it was
really just a minor patch that will not influence anything really, but would
use the minor or major section for all other changes, ranges might work
without breaking other ppls builds - but this mechanismus counts on this
very ability, which is hard to maintain, especially with new developers
joining the team. When you have strict versions everyone has to change to a
new version deliberately.

About the thing with version numbers as property values in the parent pom -
I am still not sure this is the best way, especially not with project that
are not really shared by others,
but this is the easiest way to update the dependency management section -
otherwise, when someone changes the version of a submodule, one has to
change this version, as well as the version in dep. mgmt.

Hmmmm, this is really hard to swallow, I can't really find THE one and only
solution of how to solve this dilemma - well, maybe I am still missing
something?

Peter

Neither Michael nor I did propose properties for the version. Simply define
the version in the version depMgmnt itself and you're done.


No, I don't think so, my point is:

parent pom:
<submoulde-version>
<dependency-management>
[]
<version>1.2.3</version>
[]
<submoulde-version>

submodule:
[]
<version>1.2.3</version>
[]

So you will have to change it in two places (=duplicate code) where as if
you are using a property, you can do it in
one singular place.

Peter


>

P.s.: It's really sad that there is no book / website that answers all these
kind of "best practice" answers.
The upcoming mvn book "the definitive guide" is great, yet imho it's more
focused on basics. :-(

Peter