geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Local module repos and SNAPSHOT artifacts
Date Fri, 23 Feb 2007 12:19:23 GMT
Good, any idea when the 1.2.0-SNAPSHOT artifacts will make it into  
there?  This would allow us to drop one of the module-local repos I  
was referring to.  I'd rather not configure yet another remote  
repository URL though, and each time we do that it slows the build  
down, we've already got a few in there which I'd like to get rid of ;-)

--jason


On Feb 23, 2007, at 4:14 AM, Matthias Wessendorf wrote:

> at least into the snapshot repo:
>
> http://people.apache.org/repo/m2-snapshot-repository/
>
>
>
> On 2/23/07, Jason Dillon <jason@planet57.com> wrote:
>> Are you folks eventually going to merge these artifacts into the main
>> apache repos?
>>
>> --jason
>>
>>
>> On Feb 23, 2007, at 4:02 AM, Matthias Wessendorf wrote:
>>
>> > Jason,
>> >
>> > I just created a staging repo for the myfaces 12 snapshot things.
>> > We are working on getting the myfaces12 build by continuum every
>> > night.
>> >
>> > However, here the stage goes:
>> > http://people.apache.org/~matzew/myfaces12-stage/
>> >
>> > -M
>> >
>> > On 2/23/07, Jason Dillon <jason@planet57.com> wrote:
>> >> Folks, the local module repository thing is a massive hack, not  
>> meant
>> >> to be used as much as we are using it... and really it should  
>> *not*
>> >> have SNAPSHOT artifacts in it.
>> >>
>> >> When using snaps in these local artifacts, strange artifact
>> >> resolution failures are bound to occur when Maven decides its  
>> time to
>> >> go update snaps (daily for us).  This causes problems when  
>> building a
>> >> module which depends on another module which has a module local  
>> repo
>> >> that contains snapshots, since the current module does not have
>> >> access to the dependency's repo it will cause an artifact  
>> resolution
>> >> exception.
>> >>
>> >> I did not check _all_ of the module local repos that we have in
>> >> server/trunk, but I know that at least in configs/jasper/ 
>> repository
>> >> there are myfaces 1.2.0-SNAPSHOT artifacts.  This is not really
>> >> acceptable.  First, its bad enough that we have to have this repo
>> >> here in the first place (the myfaces team should just publish  
>> snaps
>> >> like all other projects) and second, these artifacts are SNAPSHOT
>> >> which causes build problems as noted above.
>> >>
>> >> *If you must* use a module local repo, then *do not* put SNAPSHOT
>> >> artifacts in there... *if you must* then include the _timestamp-
>> >> build_ artifacts and configure your pom to use them, so that
>> >> dependent projects don't freak-out when mvn tries to update snaps.
>> >>
>> >>   * * *
>> >>
>> >> I'm still working out a simply/elegant way to solve this  
>> problem of
>> >> remote repos and local repos, etc... but until I get that we  
>> need to
>> >> becareful about how we use these local repos and which remote  
>> repos
>> >> we include (I notice we still have a few legacy repos, which are a
>> >> big no-no).
>> >>
>> >> David Jencks mentioned in IRC today that it might be better if we
>> >> just had one location where all of these module-local repos  
>> artifacts
>> >> are kept.  IMO, the module-local repos suck... but having one  
>> sucks
>> >> less than having more than one, so I'm inclined to agree this is a
>> >> good idea for the short-term.  To make this work, we basically  
>> create
>> >> another top-level module (peer to modules and configs, etc) say  
>> named
>> >> "repository" (or whatever).  This module contains the single  
>> local-
>> >> module repository in m2 format, which is only configured in that
>> >> modules pom.  Then the pom lists all of the artifacts as  
>> dependencies
>> >> which are in the repo to force them to get installed into Maven's
>> >> local cache.
>> >>
>> >> This module is added first, before all other children in the  
>> reactor,
>> >> which will *hopefully* always get that module executed first,  
>> those
>> >> deps installed and then other modules which depend on those custom
>> >> bits will already have them resolved in the local maven cache.  It
>> >> sucks... but it sucks-less IMO than handful of repos that we  
>> have now
>> >> scattered through the project tree.
>> >>
>> >> I'm still working on getting a better solution to the entire  
>> remote
>> >> repo/repeatable build/blah, blah stuff... but until then I  
>> think this
>> >> is a decent step to simplify things a tiny bit more and help  
>> reduce
>> >> strange problems from popping up.
>> >>
>> >>   * * *
>> >>
>> >> Comments?  Unless there are any objections, I'll implement this in
>> >> the next day or so... BUT, still need someone to deal with the
>> >> myfaces 1.2.0-SNAPSHOT bits which really need to be fixed even  
>> if we
>> >> leave the repos asis, or move to this one single short-term local
>> >> repo.
>> >>
>> >> --jason
>> >>
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> > http://tinyurl.com/fmywh
>> >
>> > further stuff:
>> > blog: http://jroller.com/page/mwessendorf
>> > mail: mwessendorf-at-gmail-dot-com
>>
>>
>
>
> -- 
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com


Mime
View raw message