geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: No legacy repos for Geronimo projects using Maven2
Date Mon, 11 Dec 2006 15:09:03 GMT
Jason V,

Copying you for your feedback and awareness.

On Dec 8, 2006, at 6:06 PM, Jason Dillon wrote:

> 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 java.net 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 java.net 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 java.net, 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.
>
> --jason
>

Matt Hogstrom
matt@hogstrom.org



Mime
View raw message