Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #26174
| 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> |
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 | Next — Previous in thread | Find similar
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