This posting is a general observation rather than a descriptions of a specific technical problem. (Okay, it's really more of a venting than an observation.)
I finding fighting with dependencies from dozens of third party JAR files from different open-source projects is becomingly an increasing burden for new project development. After spending hours into days sorting out library conflicts, it's not unusual for me to think I'd be better off reverting to a more pure and simple Tomcat Servlet architecture. (The Rails success has largely come from a straight forward proposition: Simpler Is Better.)
Like most projects, each JBoss server / tool / API comes with its JARs, plus a few to many other third-party JARs as dependencies - and the versions aren't always the same. For instance. Hibernate 3.2.0 downloaded from JBoss depends on commons-collections-2.1.1.jar, but Seam downloaded from JBoss depends on commons-collections-3.1.jar. JBoss AS 4.2.0.GA "All" instance depends on a JAR file named commons-collections.jar.
So when you do a Seam + Hibernate + JBoss 4.2.0.GA project, which commons-collections JAR should we use?
Of course, when things go wrong, one spends half a day digging through some other project's source code to figure out why. Sometimes, just changing the classpath order fixes issues. All this wasted time adds no business value to my project.
I recall Marc Fleury once describing the JBoss open source model like this: Anyone can buy the ingredients to make ketchup, but we place extra value in having a third party put it altogether for us. Likewise, anyone can assemble all the J2EE/JEE capabilities from third party libraries, but JBoss puts it all together for us. And we value that integration.
I know JBoss doesn't write most of the code used in the many JARs used in its projects, but it would be extra valuable if it could bring all the ingredients together to make them work across projects.
I don't know if it's feasible, or even desirable, for JBoss to establish a central repository of up-to-date third party JARs to be used by all of its projects. All projects would be tested and released against those JARs. When an updated version of a JAR was released, no project would use the new JAR in a release until every project was certified to worked with it.
If there's an answer out there I've missed, please let me know. Thanks for letting me vent.