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: "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."
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. 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
