geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: Local module repos and SNAPSHOT artifacts
Date Tue, 27 Feb 2007 21:01:38 GMT
On 2/27/07, Prasad Kashyap <goyathlay.geronimo@gmail.com> wrote:
> 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 is exactly what I had tried too. Theoretically, this should have
> worked. A straightforward move from a lower module pom to a higher
> pom. But it fails to resolve the artifacts from module repo and move
> it to maven local repo.
>
> pom.xml: http://rifers.org/paste/show/3692
>
> log: http://rifers.org/paste/show/3693
>
> I think I am missing something very glaringly obvious here.

Here's the glaringly obvious mistake I had made. Had set snaps to true
and releases to false.

Now it works.

Cheers
Prasad

>
> Cheers
> Prasad
>
> >
> > 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
> >
>

Mime
View raw message