<?xml version="1.0" encoding="UTF-8"?>
<settings>
<localRepository>${LOCAL_GERONIMO_M2_REPO}</localRepository>
</settings>But the downside, is you're leaving it up to each developer to either supply this environment variable or manually update the file and it would be used by all Maven2 builds.... So, you would really need to restore the bootstrap scripts to setup a local Geronimo repo dir (checkout or update the needed files from svn) and then run a multistage server build (genesis, maven plugins, modules, configs and assemblies)....
-Donald Jason Dillon wrote:
Unfortunately this would have to be externally controlled, can not specify maven.repo.local in a pom, and if you could, can't root it to the project, as ${pom.basedir} will always keep changing.This was possible in m1 though... for what its worth. Only way to do this in m2 is to use native scripts.:-( --jason On Dec 11, 2006, at 2:49 PM, Guillaume Nodet wrote:Is there a way to specify that in the pom ? Or you have to rely on users to specify it on the command line everytime they build (or use batch files). On 12/11/06, Jason Dillon <[EMAIL PROTECTED]> wrote:What do you mean? If you specify -Dmaven.repo.local=./svn-repo (or where ever the svn checkout is) and run the build offline, then the repo won't get modified, and thus only chance a bad artifact would get in there would be if someone checked in something bad, or if the local `mvn install` got messed up, but generally `mvn install` artifacts will never be checked into that repo. It is really too bad that there is not a local repo for deps and then a local repo for generated artifacts. The whole local repo thing is lossy IMO and makes it very difficult to assure quality of releases. --jason On Dec 11, 2006, at 7:55 AM, Guillaume Nodet wrote: > 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 <[EMAIL PROTECTED]> 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 >> >> > > > -- > Cheers, > Guillaume Nodet--Cheers, Guillaume Nodet
smime.p7s
Description: S/MIME Cryptographic Signature
