[lmm]

Sounds like they've cocked up the jars they've produced; you should never have to use exclusions, and it's possible to have a dependency that can be satisfied multiple ways with a default, so you shouldn't need to choose the driver separately if you don't want to. Much of that xml file is what already exists for your project. So the fair comparison is with the section: <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-java</artifactId> <version>2.28.0</version> </dependency>

So: you need a groupId; we've learnt through painful experience that this is a good idea to prevent collisions rather than just using the name. That said, your tool should autocomplete it if there's only one option.

You need to specify a version; this is 1000% the Right Thing. Again, your tool will give you a list to choose from.

And yeah, it's a bit of a verbose way to specify those three pieces of information; the point is for it to be easy to automatedly manipulate the pom file.

[babebridou]

Exclusions happen, when you need to make do with libraries that have different release schedules or are poorly organized but critical for your current priorities, needs and time constraints. One should see exclusions pretty much as Technical Debt.

Maven becomes brilliant when you start dealing with a large number of modules and profiles, and becomes more tedious when you pass a certain complexity threshold, usually when you have multiple layers of compile-time code generation going on top of each other.