On 22 Jun 07, at 2:56 AM 22 Jun 07, Mark Hobson wrote:
On 21/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
I don't think this makes sense to add to 2.0.x as we have to 1)
provide a way to load these strategies which is taken care of in 2.1,
The method I've been using to switch conflict resolvers in 2.0.x is by
supplying an auxiliary components.xml in $M2_HOME/extensions and
updating m2.conf, as described in MNG-2771. I'm aware that this is
per-installation and not defined in the POM, but I'm happy to live
with that for 2.0.x.
and 2) people will implement them in 2.0.x and then expect them to
work in 2.1 which they won't because it will be graph-based in 2.1.
Due to the manual intervention required to switch conflict resolvers,
I don't think many people will be surprised to have to use a different
method in 2.1. Conflict resolvers will still be relevant with graph
based resolution, although I'm sure the API will be slightly
different.
I think everyone agrees that will happen. And though the issue has
been
voted on, how many people are desperate for this now that MNG-1577
has been implemented.
MNG-1577 is a small step in the right direction, but nearest conflict
resolution is the root cause of most of our dependency woes which sap
large amounts of developer time. As I mentioned earlier in this
thread, our projects consist of many inter-related modules:
MNG-1577 is not simply the employing the nearest strategy of
selection: it is putting the user in control of what gets selected.
"To give an example of the number of components within our top-level
projects: a typical project has 151 dependencies, 89 of which are
internal, and the dependency tree goes up to 7 levels deep. We
currently have 25 of these projects, each of which are on differing
versions of our internal components. It's easy to see that managing a
list of 150 dependency versions across 25 different dependency
management sections soon becomes a maintenance nightmare."
For one project you have 25 different depMans?
Technically this is not a problem. The problem is exposing the API
near the end of 2.0.x active development and then having to support
this later on.
The API would be no more exposed than it is now - ConflictResolver is
the API and currently already exists in maven-artifact 2.0.x.
Yes, but no one uses it and how are you going to turn it on.
The
patch merely supplies alternative implementations of this API and uses
it as intended in DefaultArtifactCollector. Thus the API is no more
exposed than any other Plexus component within Maven.
API exposure, and mechanism for loading the strategies are problems.
I don't think it would be wise to promote this at this point in
2.0.x.
I've covered both of these points above. It would be shame to deny
2.0.x this much-needed feature and force users to wait months,
possibly a year, for a stable 2.1. I'd be forced to maintain a
patched version of 2.0.x since we desperately need this now.
How are you going to activate it?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
