geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject No legacy repos for Geronimo projects using Maven2
Date Fri, 08 Dec 2006 23:06:00 GMT
Maven does not behave well with a mix of default and legacy repos.  I  
have gone through and moved all legacy repos only to the modules  
where they are used, and in some cases imported a module-local repo  
to hold those artifacts so that the build does not need to include a  
legacy repo.  A few weeks ago I finally removed all the legacy  
repos.... and now they are starting to creep back in.

Specifically the repo, which is a legacy repo for jstl muck,  
was added.  Something needs to be done about this, so this repo can  
be moved out of the project root, or removed altogether.  The  
addition of the legacy repo is known to cause problems with SNAPSHOT  
resolution, and can get itself into a state with local metadata what  
other artifacts will start to resolve in very, very, very strange  
ways.  So... don't use them.

This is compounded even more by the poor network connectivity (and  
maybe connection limiting) done by the repo, which is  
causing builds to timeout all over the place.

  * * *

Basically... maven remote repos suck ass... and should be limited in  
use as much as possible if we want a stable and repeatable build for  
any of our projects.

In a corporate environment, this problem is easily solved by managing  
a local repo which has copies of all of the artifacts which are  
required to build, often times stored in version control and labeled  
with project using it.

If we are going to continue to use Maven (which I'm starting to  
really wonder if it is worth it), then we really need to address this  
problem... otherwise it will be an ongoing head-ache for the  
foreseeable future... and really builds will never reach any level of  
stability and will almost never have any ability to be reproduced.

Ugh, I've already spent so many hours debugging other peoples  
reported issues, which most of the time end up resolve to problems  
with Maven.  I've been away for a little bit working on build  
automation and in the few weeks I'm gone the build system has already  
regressed in a few areas, and IMO its well on its way to becoming out  
of control again while quickly.  I am starting to believe that Maven  
promotes that chaos, especially so for larger projects.  I also  
believe that Maven promotes build instability, where at times someone  
might change some dependency which could completely hose our build  
with out anyone really knowing why or having any paper trail (change  
logs) to debug it.

IMO... the *ONLY* way to resolve these issues with Maven it so have  
*ONE* repository which holds all artifacts used by our projects, and  
have that repository under SVN control.

So, for this example of jstl on, those artifacts would be  
checked into the *ONE* repository and life goes on, no new pom config  
to configure a new repo, no side-effects of poor network connectivity  
to remote repositories, no strange behavior due to legacy vs. default  
layout metadata muck.

If we were using Ant, then we would have needed to implement  
something like this already.  Though its more cumbersome with Maven  
since most of the crap that is downloaded is for Maven itself, not  
for our dependencies, our dependencies are much, much, much easier to  
manage than the stew of jars required to make Maven and its horde of  
plugins work.

The more I use Maven, the more I dislike it... and I don't really see  
a light at the end of the tunnel either... mvn is almost as slow  
moving as Geronimo has been for the past year, so not sure how viable  
it will be as a build tool for the future if they do not provide more  
bug fixes sooner and faster.  At this point... and ya, I may be in a  
bad mood now... I don't think that mvn is an appropriate tool for  
building production quality products... period.


View raw message