On 9/18/06, Andreas Guther <[EMAIL PROTECTED]> wrote:
And then that we sometimes end up with two versions of the same
dependency. Application A needs components C1 and C2. C1 defines
dependency on D version 1.1 and C2 defines dependency on D version 1.0.
What I see is that we find both in our war lib folder.
Right now I am not sure how to deal with those problems. The idea of
locking the repository obviously does not really solve the problem. The
convenience of Maven to resolve and download all transient dependencies
seems to be paid with sudden conflicts that were not apparent in the
first place without Maven.
This will also answer Lakshman Srilakshmanan's reply too.
You had to deal with these version conflicts before, but you had to do
so manually.
At least I did when using Ant.
With Maven the dependencies are explicitly managed by the pom so it
takes the guesswork out of what is really needed. Admittedly there
are some projects out there that need cleaning up and marking some of
their dependencies optional so that you don't get the kitchen sink as
well.
However the two ways I resolve these problems are
1) your parent pom defines all version information and your modules do not.
2) override the dependency values (if your are depending upon
something other than a module) and exclude things.
The root cause of your problem is that Components C1 and C2 need to
ensure that they are using the same versions, which is the job of your
Configurations Controller to check and enforce. By locking the
repository down you just add a layer of administration that slows
things down when the component really does need a different version.
If the versions are incompatible then that means you need to
communicate more to ensure people are using sanctioned versions and
one component needs to be modified (either upgraded or downgraded in
library versions).
I find that you can get away with not explicitly "sanctioning"
versions for quite a lot of projects. For the small number of cases
where version conflicts arise then listing the "sanctioned" versions
on your internal wiki is quicker, cheaper and more accessible than
locking the repository. If all this fails, then sit down with the
projects and communicate how dependencies work, which is still much
cheaper than trying to lock down the repository.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
