Re: Dependency resolution in Java builds

Joshua Maurice wrote:


Second to deployment, which is subordinate to operations, which subsumes the
aforementioned.

Generally, programmers as a class are woefully ignorant of
build/deployment/ops matters. I've seen this repeatedly in
multi-million-dollar projects. One such had radically different builds on
developer machines from those on test/production machines. You could pass all
unit tests on the developer machine and fail on the test box, for example.

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. I forbore to mention the classloader and library
incompatibilities between JARS loaded by unchecked programmers and versions
provided by the application server.

On a recent project I had the opportunity to get elbow-deep into Maven builds,
Hudson continuous integration and deployments to a Java EE server. Boy howdy!

On a less recent project, I worked for about six months with the ops guys, in
a town I'll call Deploymentville. Their opinion of the project's programming
team, about twenty miles up the highway in Programmerton? "We like to get
those Programmerton guys over here for about six months," one ops guru told
me, grinning wickedly. "They go back ... /changed/."

--
Lew
Ceci n'est pas une fen??tre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|