You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by toby cabot <to...@caboteria.org> on 2008/02/05 16:50:18 UTC
long-term buildability of released versions?
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
Re: long-term buildability of released versions?
Posted by toby cabot <to...@caboteria.org>.
On Tue, Feb 05, 2008 at 01:23:33PM -0500, Jarek Gawor wrote:
> I've fixed 1) and 2) in trunk, branches/2.0, and branches/2.1.
Thank you.
> I'm not sure about the other two.
I tried surefire 2.3 and it works fine. I think it's low risk since
it's only used during the build.
--- maven-plugins/geronimo-maven-plugin/pom.xml (revision 615899)
+++ maven-plugins/geronimo-maven-plugin/pom.xml (working copy)
@@ -58,7 +58,7 @@
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-api</artifactId>
- <version>2.1-SNAPSHOT</version>
+ <version>2.3</version>
</dependency>
</dependencies>
jtidy looks as if it will be a problem, but we've made very good
progress.
Re: long-term buildability of released versions?
Posted by Donald Woods <dw...@apache.org>.
There are newer released versions of surefire-api we can use - 2.3,
2.3.1 and 2.4. I'll defer to someone who knows our maven-plugins better
to determine if we can move up to a newer version....
The only release of jtidy is 4aug2000r7-dev. The latest snapshot is
http://jtidy.sourceforge.net/snapshots/jtidy/jtidy/8.0-SNAPSHOT/jtidy-8.0-20060801.131059-3.jar.
I asked to join the project, but we may need to copy that jar into our
local repo dir as a short-term solution.
-Donald
Jarek Gawor wrote:
> I've fixed 1) and 2) in trunk, branches/2.0, and branches/2.1.
>
> For 1) add the exclusion like David mentioned. For 2) just remove the
> <version> element for that api in geronimo-jaxws/pom.xml. It's really
> not needed there.
>
> I'm not sure about the other two.
>
> Jarek
>
> On Feb 5, 2008 12:25 PM, toby cabot <to...@caboteria.org> wrote:
>> Thanks David, it sounds as if we do want a SNAPSHOT-less build.
>>
>> These snapshots croak 2.0.2's offline build:
>>
>> | 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
>> |
>> | 1) org.apache.axis2:axis2-jaxws-api:jar:SNAPSHOT
>> |
>> | Path to dependency:
>> | 1) org.apache.geronimo.modules:geronimo-jaxws:jar:2.0.2
>> | 2) org.apache.axis2:axis2-jaxws-api:jar:SNAPSHOT
>> |
>> | 1) org.apache.maven.surefire:surefire-api:jar:2.1-SNAPSHOT
>> |
>> | Path to dependency:
>> | 1) org.apache.geronimo.plugins:geronimo-maven-plugin:maven-plugin:2.0.2
>> | 2) org.apache.maven.surefire:surefire-api:jar:2.1-SNAPSHOT
>> |
>> | 1) jtidy:jtidy:jar:8.0-SNAPSHOT
>> |
>> | Path to dependency:
>> | 1) org.apache.geronimo.plugins:testsuite-maven-plugin:maven-plugin:2.0.2
>> | 2) jtidy:jtidy:jar:8.0-SNAPSHOT
>>
>> Not bad. If you'd like I can try to find the nearest released
>> versions that correspond to the snapshots and see what happens if I
>> substitute them.
>>
>
Re: long-term buildability of released versions?
Posted by Jarek Gawor <jg...@gmail.com>.
I've fixed 1) and 2) in trunk, branches/2.0, and branches/2.1.
For 1) add the exclusion like David mentioned. For 2) just remove the
<version> element for that api in geronimo-jaxws/pom.xml. It's really
not needed there.
I'm not sure about the other two.
Jarek
On Feb 5, 2008 12:25 PM, toby cabot <to...@caboteria.org> wrote:
> Thanks David, it sounds as if we do want a SNAPSHOT-less build.
>
> These snapshots croak 2.0.2's offline build:
>
> | 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
> |
> | 1) org.apache.axis2:axis2-jaxws-api:jar:SNAPSHOT
> |
> | Path to dependency:
> | 1) org.apache.geronimo.modules:geronimo-jaxws:jar:2.0.2
> | 2) org.apache.axis2:axis2-jaxws-api:jar:SNAPSHOT
> |
> | 1) org.apache.maven.surefire:surefire-api:jar:2.1-SNAPSHOT
> |
> | Path to dependency:
> | 1) org.apache.geronimo.plugins:geronimo-maven-plugin:maven-plugin:2.0.2
> | 2) org.apache.maven.surefire:surefire-api:jar:2.1-SNAPSHOT
> |
> | 1) jtidy:jtidy:jar:8.0-SNAPSHOT
> |
> | Path to dependency:
> | 1) org.apache.geronimo.plugins:testsuite-maven-plugin:maven-plugin:2.0.2
> | 2) jtidy:jtidy:jar:8.0-SNAPSHOT
>
> Not bad. If you'd like I can try to find the nearest released
> versions that correspond to the snapshots and see what happens if I
> substitute them.
>
Re: long-term buildability of released versions?
Posted by toby cabot <to...@caboteria.org>.
Thanks David, it sounds as if we do want a SNAPSHOT-less build.
These snapshots croak 2.0.2's offline build:
| 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
|
| 1) org.apache.axis2:axis2-jaxws-api:jar:SNAPSHOT
|
| Path to dependency:
| 1) org.apache.geronimo.modules:geronimo-jaxws:jar:2.0.2
| 2) org.apache.axis2:axis2-jaxws-api:jar:SNAPSHOT
|
| 1) org.apache.maven.surefire:surefire-api:jar:2.1-SNAPSHOT
|
| Path to dependency:
| 1) org.apache.geronimo.plugins:geronimo-maven-plugin:maven-plugin:2.0.2
| 2) org.apache.maven.surefire:surefire-api:jar:2.1-SNAPSHOT
|
| 1) jtidy:jtidy:jar:8.0-SNAPSHOT
|
| Path to dependency:
| 1) org.apache.geronimo.plugins:testsuite-maven-plugin:maven-plugin:2.0.2
| 2) jtidy:jtidy:jar:8.0-SNAPSHOT
Not bad. If you'd like I can try to find the nearest released
versions that correspond to the snapshots and see what happens if I
substitute them.
Re: long-term buildability of released versions?
Posted by David Jencks <da...@yahoo.com>.
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
Re: long-term buildability of released versions?
Posted by toby cabot <to...@caboteria.org>.
> If you still have problems, please keep this thread alive....
At the risk of demonstrating my inability to follow directions I'll
keep the thread alive to say that with your changes and Jarek's I
think we're in good shape. Thanks!
Re: long-term buildability of released versions?
Posted by Donald Woods <dw...@apache.org>.
I just built the latest 2.0.3-SNAPSHOT code (r619588) online and then
again offline successfully via -
mvn install -Dtest=false -o
If you still have problems, please keep this thread alive....
-Donald
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
>