Re: classlib build status emails?
On 27/02/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > So I (ahem) 'tested' the build machine by checking in some code that > would not compile, at 16:23 GMT today -- but no complaint sent on the > dev list? Thanks Tim. It's about time someone tested it! ;-) The mail logs show the message leaving the build machine and being delivered to the smarthost that should have delivered it. I've just sent a test message from the build machine and that reach an external host without a problem so I guess the build messages must be getting spam filtered or moderated? I wonder if someone can check the logs for the list host for message from <[EMAIL PROTECTED]> ? Regards, Mark. -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
Re: classlib build status emails?
So I (ahem) 'tested' the build machine by checking in some code that would not compile, at 16:23 GMT today -- but no complaint sent on the dev list? Regards, Tim Mark Hindess wrote: > On 21/02/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> Mark Hindess wrote: >>> On 21/02/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Mark Hindess wrote: > Hi, > > Is there any interest in having build status emails sent to this list? > I'm building classlib trunk with continuum and it would be simple for > me to have messages like the following sent to the list whenever the > status of our builds change. Currently I'm building only on linux but > I plan to get windows builds running in the next few days. Cool. Please, only send changes (pass->fail, fail->pass). >>> Agreed. >>> >>> Done. (Will the non-subscriber [EMAIL PROTECTED] be able to send >>> to the list or is there something that needs to be done to avoid >>> moderation/spam filtering?) >> We can certainly add that.. > > Thanks. > > Currently the builds are running the default target in make/build.xml > but if there was a top-level build-and-test target then I could run > that instead. This might produce more useful results. Ah. Can you do a sequence : $ cd make $ ant $ cd .. $ ant -f build-test.xml >>> The current build is just a direct "svn co" and ant project at >>> present. My next step is to use a local repository with svn:externals >>> pulling in the harmony trunk so I'll have more flexibility. However, >>> I suspect more people might run the test target if this process was >>> simplified. Of course, as Tim mentioned it's not trivial because of >>> the requirement for a VM and other dependencies so perhaps it is not >>> worth it. >> I think it is. It's great that you have a private version of this >> running now for us, but we want to get to a point where >> >> a) anyone can do it >> >> b) The one that we reun for the project is running here on apache >> infrastructure > > I agree. I'd be happy to run it on apache infrastructure. I'd be > happy to move development of the build-test-publish wrapper to apache > infrastructure but that might slow things down a little. > >>> I'm going to concentrate on testing first - since the test results are >>> probably more important than the actual build artifacts at this point >>> - but wrapping the build should also allow me to add a publish step to >>> our parent build if there was somewhere I could publish to? >> Lets get that working - we can then run it here and have it publish >> locally to the infrastructure... > > Agreed. > > Nothing we are doing here is really private except in that it is > currently running on a private server. That's really a matter of > getting results while avoiding the logistical issues - hardware, > access, compiler licenses, etc - of running it on apache > infrastructure. When it is working we can resolve those issues. > Until it is working there isn't really much incentive. > > Regards, > Mark. > > > -- Forwarded message -- > From: Apache Harmony Build <[EMAIL PROTECTED]> > Date: 20-Feb-0006 11:04 > Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 > To: [EMAIL PROTECTED] > > > Online report : > http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/44 > Build statistics: > State: Ok > Previous State: Failed > Started at: Mon, 20 Feb 2006 11:03:46 + > Finished at: Mon, 20 Feb 2006 11:04:56 + > Total time: 1m 9s > Build Trigger: Forced > Exit code: 0 > Building machine hostname: hy2 > Operating system : Linux > Java version : 1.4.2(IBM Corporation) > > Changes > No files changed > > > Output: > > [snip] > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: classlib build status emails?
Yup, got to echo Tims words - very cool :) It's great for us to be able to see how near/far we are from a full J2SE implementation, and provides a simple way for people to find areas that need work. Thanks! Stuart Ballard wrote: Stuart Ballard gmail.com> writes: If you can give me an url that will always point to the latest jar file(s), I can set up nightly japi results and mail diffs to this list. Geir gave me a pointer to the latest snapshots, so the japi results are now online: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk10-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk11-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk12-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk13-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-harmony-jdk15 The last report triggers a recently-discovered bug in japitools that causes some StringBuffer methods to be incorrectly reported as "missing in jdk15" (which would mean that they are extra methods in harmony). I suggest ignoring the last report for now, or at least verifying anything it claims against Sun's documentation before acting on it. Other than that the reports should give correct information about Harmony's coverage of the API defined in each JDK version. Whenever these results change for better or worse, (unless I've screwed something up), an email will be sent to this list with the differences. Stuart. -- Oliver Deakin IBM United Kingdom Limited
Re: classlib build status emails?
These are very cool -- thanks Stuart. We need to figure out a way that we can run the japitools on a regular basis to track progress. It is also a great way to indicate where people can help round-out a particular package for example. How should I interpret a line whose percentage figures don't add up to 100% ? For example, looking at: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-harmony The packages java.security.interfaces and java.text are flagged as less than 100% good, but without any minor/bad/missing/abs.add sins. Regards, Tim Stuart Ballard wrote: > Stuart Ballard gmail.com> writes: >> If you can give me an url that will always point to the latest jar file(s), I >> can set up nightly japi results and mail diffs to this list. > > Geir gave me a pointer to the latest snapshots, so the japi results are now > online: > > http://www.kaffe.org/~stuart/japi/htmlout/h-jdk10-harmony > http://www.kaffe.org/~stuart/japi/htmlout/h-jdk11-harmony > http://www.kaffe.org/~stuart/japi/htmlout/h-jdk12-harmony > http://www.kaffe.org/~stuart/japi/htmlout/h-jdk13-harmony > http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-harmony > http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony > http://www.kaffe.org/~stuart/japi/htmlout/h-harmony-jdk15 > > The last report triggers a recently-discovered bug in japitools that causes > some > StringBuffer methods to be incorrectly reported as "missing in jdk15" (which > would mean that they are extra methods in harmony). I suggest ignoring the > last > report for now, or at least verifying anything it claims against Sun's > documentation before acting on it. > > Other than that the reports should give correct information about Harmony's > coverage of the API defined in each JDK version. > > Whenever these results change for better or worse, (unless I've screwed > something up), an email will be sent to this list with the differences. > > Stuart. > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: classlib build status emails?
Stuart Ballard gmail.com> writes: > If you can give me an url that will always point to the latest jar file(s), I > can set up nightly japi results and mail diffs to this list. Geir gave me a pointer to the latest snapshots, so the japi results are now online: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk10-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk11-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk12-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk13-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-harmony-jdk15 The last report triggers a recently-discovered bug in japitools that causes some StringBuffer methods to be incorrectly reported as "missing in jdk15" (which would mean that they are extra methods in harmony). I suggest ignoring the last report for now, or at least verifying anything it claims against Sun's documentation before acting on it. Other than that the reports should give correct information about Harmony's coverage of the API defined in each JDK version. Whenever these results change for better or worse, (unless I've screwed something up), an email will be sent to this list with the differences. Stuart.
Re: classlib build status emails?
On 21/02/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > Mark Hindess wrote: > > On 21/02/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> Mark Hindess wrote: > >>> Hi, > >>> > >>> Is there any interest in having build status emails sent to this list? > >>> I'm building classlib trunk with continuum and it would be simple for > >>> me to have messages like the following sent to the list whenever the > >>> status of our builds change. Currently I'm building only on linux but > >>> I plan to get windows builds running in the next few days. > >> Cool. Please, only send changes (pass->fail, fail->pass). > > > > Agreed. > > > > Done. (Will the non-subscriber [EMAIL PROTECTED] be able to send > > to the list or is there something that needs to be done to avoid > > moderation/spam filtering?) > > We can certainly add that.. Thanks. > >>> Currently the builds are running the default target in make/build.xml > >>> but if there was a top-level build-and-test target then I could run > >>> that instead. This might produce more useful results. > >> Ah. Can you do a sequence : > >> > >> $ cd make > >> $ ant > >> $ cd .. > >> $ ant -f build-test.xml > > > > The current build is just a direct "svn co" and ant project at > > present. My next step is to use a local repository with svn:externals > > pulling in the harmony trunk so I'll have more flexibility. However, > > I suspect more people might run the test target if this process was > > simplified. Of course, as Tim mentioned it's not trivial because of > > the requirement for a VM and other dependencies so perhaps it is not > > worth it. > > I think it is. It's great that you have a private version of this > running now for us, but we want to get to a point where > > a) anyone can do it > > b) The one that we reun for the project is running here on apache > infrastructure I agree. I'd be happy to run it on apache infrastructure. I'd be happy to move development of the build-test-publish wrapper to apache infrastructure but that might slow things down a little. > > I'm going to concentrate on testing first - since the test results are > > probably more important than the actual build artifacts at this point > > - but wrapping the build should also allow me to add a publish step to > > our parent build if there was somewhere I could publish to? > > Lets get that working - we can then run it here and have it publish > locally to the infrastructure... Agreed. Nothing we are doing here is really private except in that it is currently running on a private server. That's really a matter of getting results while avoiding the logistical issues - hardware, access, compiler licenses, etc - of running it on apache infrastructure. When it is working we can resolve those issues. Until it is working there isn't really much incentive. Regards, Mark. > >>> -- Forwarded message -- > >>> From: Apache Harmony Build <[EMAIL PROTECTED]> > >>> Date: 20-Feb-0006 11:04 > >>> Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 > >>> To: [EMAIL PROTECTED] > >>> > >>> > >>> Online report : > >>> http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/44 > >>> Build statistics: > >>> State: Ok > >>> Previous State: Failed > >>> Started at: Mon, 20 Feb 2006 11:03:46 + > >>> Finished at: Mon, 20 Feb 2006 11:04:56 + > >>> Total time: 1m 9s > >>> Build Trigger: Forced > >>> Exit code: 0 > >>> Building machine hostname: hy2 > >>> Operating system : Linux > >>> Java version : 1.4.2(IBM Corporation) > >>> > >>> Changes > >>> No files changed > >>> > >>> > >>> Output: > >>> > >>> [snip] -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
Re: classlib build status emails?
Mark Hindess wrote: On 21/02/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Mark Hindess wrote: Hi, Is there any interest in having build status emails sent to this list? I'm building classlib trunk with continuum and it would be simple for me to have messages like the following sent to the list whenever the status of our builds change. Currently I'm building only on linux but I plan to get windows builds running in the next few days. Cool. Please, only send changes (pass->fail, fail->pass). Agreed. Done. (Will the non-subscriber [EMAIL PROTECTED] be able to send to the list or is there something that needs to be done to avoid moderation/spam filtering?) We can certainly add that.. Currently the builds are running the default target in make/build.xml but if there was a top-level build-and-test target then I could run that instead. This might produce more useful results. Ah. Can you do a sequence : $ cd make $ ant $ cd .. $ ant -f build-test.xml The current build is just a direct "svn co" and ant project at present. My next step is to use a local repository with svn:externals pulling in the harmony trunk so I'll have more flexibility. However, I suspect more people might run the test target if this process was simplified. Of course, as Tim mentioned it's not trivial because of the requirement for a VM and other dependencies so perhaps it is not worth it. I think it is. It's great that you have a private version of this running now for us, but we want to get to a point where a) anyone can do it b) The one that we reun for the project is running here on apache infrastructure I was thinking we might be able to have standard assumptions (encoded in ant properties) about the location of dependencies and document setting up the build and test process - much as Tim has done for the classlib build. Obviously we'd want a mechanism for overriding the standard assumptions - perhaps a local (optional) included property file. Yep Perhaps once I have setup the test run I'll have a better idea about how this could be simplified. I'm going to concentrate on testing first - since the test results are probably more important than the actual build artifacts at this point - but wrapping the build should also allow me to add a publish step to our parent build if there was somewhere I could publish to? Lets get that working - we can then run it here and have it publish locally to the infrastructure... On a related note, removing the output attributes from the targets that exec make (and thus allowing the output to go to stdout/console) would produce much more helpful results and probably result in more constructive bug reports if/when the native builds fail. Yes indeedy. I never understood why they were off in a file by default. We've already had one person get confused there... Thanks. Regards, Mark. -- Forwarded message -- From: Apache Harmony Build <[EMAIL PROTECTED]> Date: 20-Feb-0006 11:04 Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 To: [EMAIL PROTECTED] Online report : http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/44 Build statistics: State: Ok Previous State: Failed Started at: Mon, 20 Feb 2006 11:03:46 + Finished at: Mon, 20 Feb 2006 11:04:56 + Total time: 1m 9s Build Trigger: Forced Exit code: 0 Building machine hostname: hy2 Operating system : Linux Java version : 1.4.2(IBM Corporation) Changes No files changed Output: [snip] -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
Re: classlib build status emails?
On 21/02/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > Mark Hindess wrote: > > > > Hi, > > > > Is there any interest in having build status emails sent to this list? > > I'm building classlib trunk with continuum and it would be simple for > > me to have messages like the following sent to the list whenever the > > status of our builds change. Currently I'm building only on linux but > > I plan to get windows builds running in the next few days. > > Cool. Please, only send changes (pass->fail, fail->pass). Agreed. Done. (Will the non-subscriber [EMAIL PROTECTED] be able to send to the list or is there something that needs to be done to avoid moderation/spam filtering?) > > Currently the builds are running the default target in make/build.xml > > but if there was a top-level build-and-test target then I could run > > that instead. This might produce more useful results. > > Ah. Can you do a sequence : > > $ cd make > $ ant > $ cd .. > $ ant -f build-test.xml The current build is just a direct "svn co" and ant project at present. My next step is to use a local repository with svn:externals pulling in the harmony trunk so I'll have more flexibility. However, I suspect more people might run the test target if this process was simplified. Of course, as Tim mentioned it's not trivial because of the requirement for a VM and other dependencies so perhaps it is not worth it. I was thinking we might be able to have standard assumptions (encoded in ant properties) about the location of dependencies and document setting up the build and test process - much as Tim has done for the classlib build. Obviously we'd want a mechanism for overriding the standard assumptions - perhaps a local (optional) included property file. Perhaps once I have setup the test run I'll have a better idea about how this could be simplified. I'm going to concentrate on testing first - since the test results are probably more important than the actual build artifacts at this point - but wrapping the build should also allow me to add a publish step to our parent build if there was somewhere I could publish to? > > On a related note, removing the output attributes from the targets > > that exec make (and thus allowing the output to go to stdout/console) > > would produce much more helpful results and probably result in more > > constructive bug reports if/when the native builds fail. > > Yes indeedy. I never understood why they were off in a file by default. > We've already had one person get confused there... Thanks. Regards, Mark. > > -- Forwarded message -- > > From: Apache Harmony Build <[EMAIL PROTECTED]> > > Date: 20-Feb-0006 11:04 > > Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 > > To: [EMAIL PROTECTED] > > > > > > Online report : > > http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/44 > > Build statistics: > > State: Ok > > Previous State: Failed > > Started at: Mon, 20 Feb 2006 11:03:46 + > > Finished at: Mon, 20 Feb 2006 11:04:56 + > > Total time: 1m 9s > > Build Trigger: Forced > > Exit code: 0 > > Building machine hostname: hy2 > > Operating system : Linux > > Java version : 1.4.2(IBM Corporation) > > > > Changes > > No files changed > > > > > > Output: > > > > [snip] -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
Re: classlib build status emails?
Stuart Ballard wrote: Mark Hindess googlemail.com> writes: Is there any interest in having build status emails sent to this list? I'm building classlib trunk with continuum and it would be simple for me to have messages like the following sent to the list whenever the status of our builds change. Currently I'm building only on linux but I plan to get windows builds running in the next few days. Are the resulting rt.jar (and/or jce.jar and/or jsse.jar, or equivalent) files available anywhere? If so (as discussed previously on this list) I'd be interested in producing japi comparisons to show API coverage and errors against the various JDK versions. The latest can be found here : http://cvs.apache.org/dist/incubator/harmony/snapshots/ Look for the "latest-harmony." We'll be publishing them much more regularly going forward. If you can give me an url that will always point to the latest jar file(s), I can set up nightly japi results and mail diffs to this list. (please keep me CC'd on responses, I can't keep up with the harmony list and only check the archives intermittently) wimp :) Thanks for doing this. geir Stuart.
Re: classlib build status emails?
Mark Hindess wrote: Hi, Is there any interest in having build status emails sent to this list? I'm building classlib trunk with continuum and it would be simple for me to have messages like the following sent to the list whenever the status of our builds change. Currently I'm building only on linux but I plan to get windows builds running in the next few days. Cool. Please, only send changes (pass->fail, fail->pass). Currently the builds are running the default target in make/build.xml but if there was a top-level build-and-test target then I could run that instead. This might produce more useful results. Ah. Can you do a sequence : $ cd make $ ant $ cd .. $ ant -f build-test.xml On a related note, removing the output attributes from the targets that exec make (and thus allowing the output to go to stdout/console) would produce much more helpful results and probably result in more constructive bug reports if/when the native builds fail. Yes indeedy. I never understood why they were off in a file by default. We've already had one person get confused there... Regards, Mark. -- Forwarded message -- From: Apache Harmony Build <[EMAIL PROTECTED]> Date: 20-Feb-0006 11:04 Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 To: [EMAIL PROTECTED] Online report : http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/44 Build statistics: State: Ok Previous State: Failed Started at: Mon, 20 Feb 2006 11:03:46 + Finished at: Mon, 20 Feb 2006 11:04:56 + Total time: 1m 9s Build Trigger: Forced Exit code: 0 Building machine hostname: hy2 Operating system : Linux Java version : 1.4.2(IBM Corporation) Changes No files changed Output: Buildfile: make/build.xml default: [echo] [echo] [echo] Building Java component archives... [echo] clean-bin: [delete] Deleting 1649 files from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin [delete] Deleted 101 directories from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin clean-layout: [delete] Deleting 34 files from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy clean-package: [delete] Deleting 11 files from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components [delete] Deleted 1 directory from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components clean: copy-resources: [mkdir] Created dir: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin [copy] Copying 7 files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin compile: [javac] Compiling 1280 source files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. package: [mkdir] Created dir: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/archive.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/kernel-stubs.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/luni.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/nio.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/nio_char.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/security.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/x-net.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/text.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/math.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/regex.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/sql.jar layout: [copy] Copying 2 files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/lib/boot [copy] Copying 11 files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/lib/boot [copy] Copying 1 file to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/lib/boot [copy] Copying 18 files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/bin
Re: classlib build status emails?
Mark Hindess googlemail.com> writes: > Is there any interest in having build status emails sent to this list? > I'm building classlib trunk with continuum and it would be simple for > me to have messages like the following sent to the list whenever the > status of our builds change. Currently I'm building only on linux but > I plan to get windows builds running in the next few days. Are the resulting rt.jar (and/or jce.jar and/or jsse.jar, or equivalent) files available anywhere? If so (as discussed previously on this list) I'd be interested in producing japi comparisons to show API coverage and errors against the various JDK versions. If you can give me an url that will always point to the latest jar file(s), I can set up nightly japi results and mail diffs to this list. (please keep me CC'd on responses, I can't keep up with the harmony list and only check the archives intermittently) Stuart.
Re: classlib build status emails?
Mark Hindess wrote: > Hi, > > Is there any interest in having build status emails sent to this list? Well we've discussed this privately, but for the record "yes!" I'd like to see build results posted to the dev list when the build is broken/repaired. > I'm building classlib trunk with continuum and it would be simple for > me to have messages like the following sent to the list whenever the > status of our builds change. Right, we don't need to see the results of every build, just when it goes from working to broken, or broken to working again. > Currently I'm building only on linux but > I plan to get windows builds running in the next few days. > > Currently the builds are running the default target in make/build.xml > but if there was a top-level build-and-test target then I could run > that instead. This might produce more useful results. Sure, use the default for now, and I'll add a 'continuum' target for you. I presume you will handle adding in some dependencies like Bouncy Castle and a VM? > On a related note, removing the output attributes from the targets > that exec make (and thus allowing the output to go to stdout/console) > would produce much more helpful results and probably result in more > constructive bug reports if/when the native builds fail. yep, that's better than hunting for the output file. Thanks. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.