It looks like the current state of the Maven artifact/repo API makes
it more difficult than desired to integrated directly into Geronimo.
Dain mentioned that Jason van Zyl might be cleaning up the API, so we
may be able to use the API directly once that has been done.
But... in the meantime, I made a few changes which I think should
help reduce strange problems with SNAPSHOT resolution.
First, I added a few ${version} property, which is always set to the
same value of ${pom.version}, but does not use that property
directly. ${pom.version} will change from the value which is
configured in poms to x-timestamo-build values when resolved from a
deployed SNAPSHOT release, and ends up causing massive problems when
resolving other artifacts.
I do not like using properties for versions like this... but short of
getting Maven changed this was the only way I could find that will
allow modules to depend on other modules w/o having to maintain a
massive dependencyManagement section in the top-level pom... which
would need ~140 dependency elements... which ends up at ~700 lines...
sucky. Use of this property also complicates the release process a
tad, as the ${version} property will need to be updated by hand
before running the release plugin... and we have yet to see how that
will work. I have asked the Maven dev list about this and so far no
one has responded back with any solution... other than not using $
{pom.version} or using non-unique versions when distribution...
neither of which I like very much.
I have also changed the car:package goal to delegate directly to the
Maven API for the sourceRepository, which will allow SNAPSHOT
versions to be resolved correctly to the versions which Maven has
downloaded. I also added explicit resolution of the deployer modules
used by car:package to ensure that the source repo always has all of
the required transitive dependencies for the deployers. This means
that external projects that package CAR files will function off of
downloaded dependencies w/o needing to explicitly add deployer deps
to the modules dependencies.
* * *
I have done some testing for G and CTS builds and so far it looks
like this is working... though I am not 100% sure that this fixes
everything.
I believe that it should be possible to build G online now with
configs deployed and get the right bits included into the assemblies
as one would expect.
For those of you who have taken to building offline to get around
problems, I'd like to ask that you try to build online and report
back if you run into any strange problems... like missing SNAPSHOT
deps, or code newly built not getting pulled into the assembly.
Please let me know if you run into anything.
Thanks,
--jason
On Oct 26, 2006, at 10:57 PM, Jason Dillon 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
