Jason van Zyl wrote:
On 22 Aug 07, at 11:29 AM 22 Aug 07, Stephen Connolly wrote:
Gregory Kick wrote:
How do you deal with concurrent writes?
That's a nightmare problem with the local repository anyway.
How on earth do you have concurrency problems with a local repository?
One team of ours had to scrap switching to Maven as it filled the
disk on their shared homes drive... and if they changed the system
default to use a common local repository they kept on getting broken
builds from two people installing the same (usually snapshot)
artifact at the same time!
Using a shared local repository is a very, very, very bad idea.
Nothing will work if you share one local repository. Again, just a bad
idea.
Yep... I cringed when I heard this one.
First they crashed the server by having one component built by maven and
"hiding" this in the middle of an ANT build script that everyone does.
Then they have a load of really big dependencies with lots of mini
version updates...
Then they wonder why they run out of disk space.. only to find that it's
the 100 developers all having a 2GB local repository in their home
directory on the shared network server...
Then they say... AHHH we'll just make it a shared local repository...
and they wonder why the other developers think Maven is a pile of cr*p...
Maven is fine... it's just the people who tried to implement it badly!
It's more of a problem for continuous integration servers that run
builds in parallel.
However the concurrent write problem is solved for remote
repositories, please solve it for local repositories as well!
You're not supposed to be sharing them. You CI system should be
deploying to a shared remote repository, not writing to a shared local
repository.
Ahhh no... you mis-understand.
CI build system kicks off build of job on machine (that build deploys to
remote repo... but deploy includes install, so installs to local repo
for current user (the user account running the CI service))
CI detects another change and says I have processing capacity to spare,
kicks off another build (or just builds another stream of the same
project) That job also is deploying to remote repo... but deploy
includes install and the local repo is the one for the user account
running the CI service... bang!
Yes _I_ know that the correct way is to configure each and every job to
have it's own local repo... and to clean out that local repo before
every build... and to have caching proxying remote repos so that you can
pull down all the dependencies quickly at the start of each build (as
otherwise the build will take 50 min instead of 5min)
But _I_ am not the person who sets up all the builds! ;-)
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
