Hopefully a better maven expert than I will chime in.
I think we are using the scout jar but not the jaxr-api snapshot
jar. I'm pretty sure the scout 1.0rc1 jar should not have been
released since it depends on a snapshot. In this case I think that
the solution is to exclude the scout jaxr-api jar in the scout
dependency.
The much bigger question is how we detect these problems before
cutting a release. One step would be to use the release plugin since
IIUC it will scan for snapshot dependencies and refuse to proceed: I
don't know if this is only for what you are building or if it checks
all the way down the dependency tree.
Anyone have ideas on what else we can do?
thanks
david jencks
On Feb 5, 2008, at 7:50 AM, toby cabot wrote:
Hi Folks,
I'm trying to gather the set of code and dependencies to build
Geronimo 2.0.2. I'd like to end up with all of the bits that I need
to build 2.0.2 without accessing the internet next week, next month,
etc, and end up with the same image.
Donald and Iain on the user list helped me with the config-magic to
convince Maven to stay local, so now I've got a maven repo with *only*
the deps that 2.0.2 needs to build. If I do an online build
everything works great, Maven copies the deps from that tree to my
user repo and the build succeeds.
Here's the problem: if I try to do an offline build the next day I get
an error about a missing jar and the build fails.
Missing:
----------
1) org.apache.ws.scout:jaxr-api:jar:SNAPSHOT
...
Path to dependency:
1) org.apache.geronimo.modules:geronimo-webservices:jar:2.0.2
2) org.apache.ws.scout:scout:jar:1.0rc1
3) org.apache.ws.scout:jaxr-api:jar:SNAPSHOT
Evidently the SNAPSHOT keyword tells Maven "refuse to build until
you've checked whether there's a newer version online".
What's the Geronimo project's goal vis-a-vis repeatably building
Geronimo releases in the future? As it stands, the 2.0.2 I build
today won't necessarily be the same as the one I build tomorrow since
Maven will aggressively bring new versions of jaxr-api (and maybe
others) into my build environment unless I crowbar Maven to think it's
online when it really isn't.
If bit-for-bit repeatability is a non-goal that's cool, I'll hack on
my internal repo metadata until Maven thinks that it's locked in
place. If it is I'll try to figure out how to "lock down" the
dependencies so they don't change.
Thanks,
Toby
