Hi! > If project A says it depends on B 1.0 and C says it depends on B 1.1, > there's a conflict in Maven, Ant and anything you want to use, the > difference is that Maven tries to do it for you, but you still can > override that behaviour. We also ended up putting our jars in svn again and using only system jars with a path to the jar in our pom. We have 50 direct dependencies, maintaining exclusion lists is a pain in the a** as you have really spent a couple of hours to get everything right again when you add a new dependency.
And the problem is not only a version number difference. Also a project might decide to change its artifactId - or split into different smaller pieces. THAT was the real bummer for us. Whats missing in pom.xml is something like: replaces and conflicts So a artifact might say, ok, I "replace" any other artifact or I cant work together "conflict" with one. Say if xmlrpc decide to split into xmlrpc-common, xmlrpc-server, xmlrpc-client, xmlrcp-all then it can say that it "conflict" with xmlrpc - and for xmlrpc-all it can say that it "replace" xmlrpc. Still, user intervention is required, but thats better than having the same library on the path multiple times, just due to the fact that the name differs. Maybe also a "contains" would be nice, so xmlrpc-all can say it already "contains" the server,client and common part. But I have to admit, I dont want the one programming the dependency solver ;-) Ciao, Mario --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
