Re: long-term buildability of released versions?
> 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?
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: long-term buildability of released versions?
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 @@ org.apache.maven.surefire surefire-api -2.1-SNAPSHOT +2.3 jtidy looks as if it will be a problem, but we've made very good progress.
Re: long-term buildability of released versions?
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 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 <[EMAIL PROTECTED]> 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. smime.p7s Description: S/MIME Cryptographic Signature
Re: long-term buildability of released versions?
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 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 <[EMAIL PROTECTED]> 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?
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?
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
