geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <drw_...@yahoo.com>
Subject Re: No legacy repos for Geronimo projects using Maven2
Date Thu, 04 Jan 2007 16:22:01 GMT
Is that an open invitation to help recreate those scripts?

Do others see a need for this?  I certainly would like to see us put 
them back in geronimo/server/trunk (or genesis) and enhance them to 
allow svn checkout/update and orderly building of genesis, specs, server 
and even handle openejb and devtools.....


-Donald


Jason Dillon wrote:
> 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