geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: No legacy repos for Geronimo projects using Maven2
Date Tue, 02 Jan 2007 23:11:18 GMT
You don't need to add this to settings.xml, you can simply:

     mvn -Dmaven.repo.local=some/path

But you are right, to make this work, we need those native scripts to  
bootstrap the build again and set the correct value for the repo.

--jason


On Jan 2, 2007, at 8:32 AM, Donald Woods wrote:

> You can create a settings.xml in the default user/.m2 directory to  
> point to an alternate local repo dir, like -
>
> <?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 <jason@planet57.com> 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 <jason@planet57.com> 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


Mime
View raw message