geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <>
Subject Re: No legacy repos for Geronimo projects using Maven2
Date Mon, 11 Dec 2006 15:55:53 GMT
Also, keep in mind that there is no way to bypass the
local repository afaik.  So if a bad artifact goes into the
user local repo, it may disturb Geronimo's build, even
if Geronimo build only use a single svn based remote
repo.  In such a case, the only way to ensure that the
build will work is to start from a clean local repo.

On 12/9/06, Jason Dillon <> wrote:
> On Dec 8, 2006, at 6:41 PM, Prasad Kashyap wrote:
> >> ... 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.
> >
> > I hear ye. I share the pain. But I fear the alternative - spending
> > considerable time migrating to another build system.
> Ya, I know... I'm not suggesting that we change any time soon.  But I
> do fear that there is going to be some serious ongoing pain.
> > When you return from your bad mood to your jolly good ole' self again,
> I dunno... I'm jaded now... good ole jolly jason was eaten by the big
> angry maven monster... :-P
> > can you please shed more light on what it would take to have this
> > *ONE* repo; it's pros and cons and such..
> I've sent a few emails about this in the past.  Major hurtles to this
> are going to be sysadmin/network overheads, ASF infra politics, and
> of course keeping the artifacts in sync.  There are just way to many
> things that need to get downloaded, making the window for problems
> really quite massive.
> I'm still trying to figure out how to effectively workaround this
> problem for an open community... in a corporate setting this is a no
> brainer, setup a machine, back it up, setup proximity or maven-proxy
> to aggregate remote repos, then create a few local repos backed by
> svn to hold custom artifacts or specific versions to help reduce risk
> incurred by remote artifact stability.  Then each project just lists
> that one repo.
> This works well, but due to the way maven works, other dependencies
> may list repos, which will then get picked up and used for artifacts
> selection, which tends to pollute the sanity and stability, but
> usually not too much.  But its yet another flaw in maven's
> architecture which while its flexible and easy for smaller projects,
> its nearly impossible to make any sort of assurances for larger more
> complicated projects.  Actually even for smaller ones it makes it
> very very difficult to ensure build stability over the life of the
> project (past build repeatability and assumed future compatibility,
> as at any time someone could publish a plugin or artifact which
> completely breaks your build, often times requiring days to debug why).
> The only way around this is to have total ownership of imported build
> artifacts and an effective paper trail for changes (ie svn change logs).
> While maven has made many things simpler... it really has made it a
> lot harder to implement stable, reliable and durable builds. :-(
> Anyways, all I can really think of to step around this problem, is to
> checkin all of the artifacts which are needed into svn, configure the
> build to use a checkout of that repo for its local and then always
> run offline.  And periodically update the svn repo from remotes as
> well as manage some artifacts by hand.  Essentially removing any
> remoteness from Maven, which is IMO key to making builds stable,
> reliable and durable.
> Svn has all the artifacts needed, so svn co will get you the right
> bits, svn up will make sure its the latest, so no need to keep making
> all those network calls to check for artifacts, which will speed the
> build up dramatically.  Svn will always have a trail of who changed
> what when which can be easily correlated to build failures using a CI
> tool.  Mysterious dependency download, metadata corruption, bad
> network connections basically go a way from the list of normal
> problems we run into.  The repository gets labeled when the software
> gets labeled, so you can *always* go back in time, checkout an old
> release and build it... and have a very, very, very high chance that
> it will work with no fuss, only things which may break it would be
> environment related (deep windows folder, wrong jdk version, missing
> heap settings, etc).
> Dunno if there are other options really... maybe... but I can't think
> of it at the moment.
> I think the mvn plugin system is good, getting better once they fix
> some of the annoying bugs... and even better once they document the
> apis more.  Wish the dang pom was not so verbose... or need to carry
> version details into each and every pom... but those are all minor.
> The major issue is the remote repo.  Once you eliminate that, then
> mvn starts to look a whole lot more attractive for serious production
> builds.
> --jason

Guillaume Nodet

View raw message