Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #26174

Re: Dependency resolution in Java builds

From Lew <noone@lewscanon.com>
Newsgroups comp.lang.java.programmer
Subject Re: Dependency resolution in Java builds
Date 2011-02-10 08:09 -0500
Organization albasani.net
Message-ID <ij0o10$o9o$1@news.albasani.net> (permalink)
References <87oc6mi2nl.fsf@web.de> <b074deac-dae8-4afe-895c-496eaa3fb5eb@x4g2000prf.googlegroups.com> <iit0p2$ha4$1@news.albasani.net> <alpine.DEB.1.10.1102092338120.18846@urchin.earth.li>

Show all headers | View raw


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|
|_____|_____|
|===========|

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Find similar


Thread

Re: Dependency resolution in Java builds Tom Anderson <twic@urchin.earth.li> - 2011-02-09 23:56 +0000
  Re: Dependency resolution in Java builds Lew <noone@lewscanon.com> - 2011-02-10 19:08 -0500
  Re: Dependency resolution in Java builds Lew <noone@lewscanon.com> - 2011-02-10 08:09 -0500

csiph-web