On 22/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 22 Jun 07, at 3:15 AM 22 Jun 07, Mark Hobson wrote:
> As mentioned above, this requires a change in the Maven installation
> rather than the POM. Obviously far from ideal, but I'm happy to live
> with this for the huge gain in productivity.
So how exactly does this help with your situation as I'm looking for
details as I'm loathe to put this in 2.0.x.
Okay, imagine a project with a deep dependency tree where many
dependencies bring in common dependencies at various levels.
Initially, let's say there are no version conflicts amongst the
dependencies. Now, a bug fix version of a common dependency is
released and updated in the most appropriate place within the
dependency tree. We now have a conflict and it is purely down to the
depth of the updated dependency as to whether it is propagated through
the whole project.
Now, there are three solutions: 1) Update all other components that
also depend on this dependency so there are no version conflicts; 2)
Add the bug fix version to the main project's depMan; 3) Rely on the
conflict resolution strategy to resolve the required version.
(1) becomes extremely impractical in large projects; (2) works, but
over time, as more and more versions are fixed in depMan, it starts to
resemble Maven 1's flattened list of dependencies, thus causing even
more maintenance problems; (3) seems like the most natural place to
make these decisions.
This is basically our situation and why we need a more intuitive
conflict resolver than nearest-wins. You can see that the concept of
nearness becomes more and more arbitrary as the dependency tree grows.
From here, the plan is to supplement the highest-wins conflict
resolution with version ranges to restrict mediation and release POMs
for reproducibility, hence my work in this area too.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
