geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul McMahan" <paulmcma...@gmail.com>
Subject Re: Maven2 vs. Geronimo Maven2 repository problems
Date Fri, 27 Oct 2006 14:39:13 GMT
I agree that these types of incompatibilities between the maven2 and
geronimo repos are troublesome and I am concerned that there will be
more rough spots ahead as both maven and geronimo continue to enhance
their repository logic in separate beakers.  An additional dimension
of this discussion is that geronimo plugin repositories favor the
maven2 style layout and conventions (see GERONIMO-2521).

I am not a maven expert so it hurts my head to think about how
complicated it might be to replace the geronimo repo with a maven repo
or some extension of it.  Stuff like the pain we went through because
of windows pathname limits comes to mind :-(  But if its possible to
perform this brain surgery without killing the patient then I am in
definitely favor of the idea.  If the effects can be localized enough
to avoid major disruptions to build, JEE5, and other ongoing
development then it seems like a worthwhile effort.

Best wishes,
Paul


On 10/27/06, Jason Dillon <jason@planet57.com> wrote:
> I think we have a major problem with out pseudo Maven2 repository
> impl wrt how SNAPSHOT artifacts are handled.
>
> The real m2 repo code when asked for a SNAPSHOT will consult a list
> of remote repos, and if matched will download a time-stamped artifact
> which will resolve to the SNAPSHOT version by metadata.  Out pseudo
> m2 repo code knows nothing about time-stamped artifacts and thus can
> not resolve an artifact that is not named artifactId-n-SNAPHOT.ext,
> even though m2 can.
>
> This is a major problem when packaging cars, as the m2 build will
> download and resolve SNAPSHOT artifacts, but G will not since it can
> not find the time-stamped versions that resolve to the artifactId-n-
> SNAPHOT.ext which was asked for.
>
> I did some experiments to make a thin adapter for the car:package
> goal to delegate to the real m2 repo API, so that it can find time-
> stamped SNAPSHOT artifacts, but I still end up with exceptions while
> packaging due to our repo API not resolving properly.  I suspect that
> our artifact resolver code needs to be changed to make this work, but
> have yet to test/validate that it works.
>
> It also looks like our repo API, or its usage is terribly
> inefficient, as I see that artifacts are asked for over and over and
> over... which causes a ton of redundant artifact resolutions... which
> is why when building a car you see a ton of pom related failures over
> and over and over for the same artifact.
>
> All and all this causing major discontinuity between m2 and G repos
> when SNAPSHOT artifacts are used... which is causing severe build
> complications.
>
> And in short... I have no idea how to fix this.  Seems like we should
> probably reuse the maven repo code... but our repo code is doing some
> mysterious things that do no map well the the maven code... like
> looking in parent configs and such.... and all that explicit
> resolution mucky muck.
>
> Erg... but then again the maven API is not really sock solid either.
> I have found that if you create an artifact with artifactId-n-
> SNAPHOT.ext and then resolve it, the resulting artifact's file is
> groupId/artifactId/n-timestamp/artifactId-n-timestamp.ext instead of
> what I had hoped groupId/artifactId/n-SNAPSHOT/artifactId-n-
> timestamp.ext, but ArtifactRepository.pathOf(artifact) returns
> groupId/artifactId/n-SNAPSHOT/artifactId-n-SNAPSHOT.ext and so with
> the combonation of the two we can resolve the actual file.
>
> I dunno... this is all pissing me off way to much....
>
> --jason
>

Mime
View raw message