Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (herse.apache.org: domain of jason.dillon@gmail.com
 designates 64.233.162.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=SuP+ykknFsarPF9UjaLxBVmWzsSxXi6FrPrIzhAiICxdSZUE3KmH94F6FG9O2VVhjEJmWR4E/1CuheMp7kOwyGLDXNlabeZdXSHxO/ei50dhoSXCo1KaraYzAEgc56bseZgeyaP+6pPUa+cv7LzaHYtPyG89ybe710A9VT5NtUU=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <b23ecedc0612111449p32eff1dfl572646870efb6321@mail.gmail.com>
References: <CBF45145-49D5-43B8-B1F2-022019C96503@planet57.com>
 <c278ac970612081841q1dff4ad8w22821df1670e18f6@mail.gmail.com>
 <01DE558D-BFF2-4811-93C9-208900B93DBD@planet57.com>
 <b23ecedc0612110755h3a67279di42aa069bee84b010@mail.gmail.com>
 <48911438-8422-48ED-8D09-9A785BECB3DD@planet57.com>
 <b23ecedc0612111449p32eff1dfl572646870efb6321@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <AB36B3B0-61D7-4E19-95F2-9068AC58C9DD@planet57.com>
Content-Transfer-Encoding: 7bit
From: Jason Dillon <jason@planet57.com>
Subject: Re: No legacy repos for Geronimo projects using Maven2
Date: Mon, 11 Dec 2006 15:04:35 -0800
To: dev@geronimo.apache.org
Sender: Jason Dillon <jason.dillon@gmail.com>

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