Maven dependency mgmt: am I doing something wrong?

Question

(title shortened to simply not make it too long, not because I am l33t).
I have a little frustration that only makes me wonder if I am doing something wrong. My general opinion about maven is that it is a great tool that can save a lot of effort managing builds. However, I sometimes find myself traversing down dependency management hell. The source of my problems: transitive dependencies.
Is it me, or is the maven repository tree polluted? Sometimes I have no other option (that I know of) than adding manual exclusions to my parent poms to filter out transitive dependencies I really do not need, and in some cases even cause conflicts. Now I must say, most of these problems stem from JBoss endorsed projects such as Seam and JBPM.
If for example I add JBPM 3.3.2 to my application I get Jackrabbit, Lucene and whatever else for "free" with it - I exclude them to keep my dependency tree clean because during runtime these dependencies really are not needed.
Worse is when I want to use JBoss Seam 2.1.2 (on JBoss 4.2.3, unfortunately I cannot go to a newer JBoss yet) - to be able to do this I must include a dependency org.jboss.el/jboss-el to the project and war, otherwise a single util class cannot be found (grrr). But this dependency transitively adds javax.el / el-api - at compile scope! If this is let slip through and a war is deployed with this dependency present, a classpath isolated environment will give classloader clashes with the classes that the JBoss server itself provides. So I add an exclusion...
These were just isolated examples and certainly not the only ones I encountered so far. Does anybody else experience these kind of issues? And is there perhaps something obliviously obvious that I am failing to do which would rid me of the need to add manual exclusions? Or am I correct in stating that the repository really is this polluted?

Answer 1

I've seen that effect, but luckily not to a degree where it got a huge problem. Simply write the necessary excludes when you see such a case and go on. It wasn't necessary too often yet.
The problem seems to stem from the fact that many Maven artifacts are simply "project X". That means that each and every feature that project X provides is bundled in a single jar which draws in each and every dependency that project X has anywhere.
The smarter (or at least more maven-friendly) approach would have been to split project X in "project X - core functionality", "project X - lucene search support", "project X - frobnicator" and provide a "project X - everything" module that pulls in all there is for the project.
This way we could pick only those modules that we need in our dependency and therefore also get only those transitive dependencies that we really need.
Unfortunately only a few projects have that kind of architecture, so we'll have to live with the excludes for a while.