Re: Dependency resolution in Java builds
Lew wrote:
Another symptom is framework plethora. Let's just throw our
RichFaces/Acegi/Echo2/Spring/Spring-JDBC/Spring-Aspect/Spring-OMG!/ all over
our XHTML over various disparate JMS scaffolds between localhost processes.
No, that's not a rant, that's a prototypic description of more than one
real-world scenario, both large and small projects. The exact frameworks in
question vary (I mentioned ones I've encountered in various combination) but
the arity is similar.
Tom Anderson wrote:
Isn't that just a question of shovelling JARs onto the classpath and then
jarring up the right things? Or do these frameworks have more involved build
requirements?
I wish it was that easy. There are at least two orders of problem. The first
is that the frameworks often pull in different versions of the same libraries.
The other is that the frameworks interact with each other in, ahem, emergent
and unexpected ways. On top of those, sometimes different frameworks have
overlapping functionality, such as Spring/JDBC and Hibernate, making it
difficult to implement a coherent strategy for such functionality.
On a recent project with Maven builds, we had a parent build ("foomain") and
several subsidiary modules ("foofrontend", "foologic", "foopersistence", ...).
Historically different versions of the same frameworks were specified for
the different modules. Yet when you pulled the dependencies into the
"foomain" pom.xml in common the build broke. Turns out some of the
dependencies transitively depend on the same libraries, but different versions
also, some of which are transitive dependencies for other stuff, also
different versions.
I tried "shoveling JARs". Nope. It's subtler than that.
--
Lew
Ceci n'est pas une fen??tre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|