Re: BATCH: All dressed up, with nowhere to go...
On 05/02/2020 09:52, Mark Thomas wrote: > The root cause of these errors is this: > https://support.sonatype.com/hc/en-us/articles/360041287334-Central-501-HTTPS-Required > > Maven central now requires https. > > I'm not sure how easy a fix this is going to be. Should be fixed now. The next issue is why the web pages (and database?) are not getting updated at the end of a run. I saw some errors when I ran Gump manually yesterday. I ignored them on the basis is was related to manual running. That may not be the case. Mark - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: BATCH: All dressed up, with nowhere to go...
The root cause of these errors is this: https://support.sonatype.com/hc/en-us/articles/360041287334-Central-501-HTTPS-Required Maven central now requires https. I'm not sure how easy a fix this is going to be. Mark On 19/01/2020 01:21, g...@gump-vm.apache.org wrote: > Dear Gumpmeisters, > > The following 12 notifys should have been sent > > *** G U M P > [GUMP@gump-vm]: Project logging-log4j-12 (in module logging-log4j-12) failed > [GUMP@gump-vm]: Project commons-lang (in module commons-lang-2.x) failed > [GUMP@gump-vm]: Project commons-io (in module commons-io) failed > [GUMP@gump-vm]: Project google-guava-parent (in module google-guava) failed > [GUMP@gump-vm]: Project commons-net (in module commons-net) failed > [GUMP@gump-vm]: Project google-guava (in module google-guava) failed > [GUMP@gump-vm]: Project commons-daemon (in module commons-daemon) failed > [GUMP@gump-vm]: Project easymock-parent (in module easymock) failed > [GUMP@gump-vm]: Project objenesis-parent (in module objenesis) failed > [GUMP@gump-vm]: Project commons-validator (in module commons-validator) failed > [GUMP@gump-vm]: Project commons-lang3 (in module commons-lang-trunk) failed > [GUMP@gump-vm]: Project commons-exec (in module commons-exec) failed > *** G U M P > [GUMP@gump-vm]: Project logging-log4j-12 (in module logging-log4j-12) failed > To whom it may engage... > > This is an automated request, but not an unsolicited one. For > more information please visit http://gump.apache.org/nagged.html, > and/or contact the folk at general@gump.apache.org. > > Project logging-log4j-12 has an issue affecting its community integration. > This issue affects 11 projects, > and has been outstanding for 10 runs. > The current state of this project is 'Failed', with reason 'Build Failed'. > For reference only, the following projects are affected by this: > - checkstyle : Java style checker > - commons-beanutils : Bean Utilities > - commons-digester : XML to Java Object Configuration > - commons-logging : Logging Library Package > - commons-logging-step-1 : Logging Library Package > - jakarta-bsf : Bean Scripting Framework > - logging-log4j-12 : Fast and flexible logging package for Java > - logging-log4j-12-tests : Fast and flexible logging package for Java > - tomcat-tc7.0.x-validate : Tomcat 7.x, a web server implementing Java > Servlet 3.0, > ... > - tomcat-tc8.5.x-validate : Tomcat 8.x, a web server implementing the > Java Servlet 3.1, > ... > - tomcat-trunk-validate : Tomcat 9.x, a web server implementing the Java > Servlet 4.0, > ... > > > Full details are available at: > http://gump-vm.apache.org/logging-log4j-12/logging-log4j-12/index.html > > That said, some information snippets are provided here. > > The following annotations (debug/informational/warning/error messages) were > provided: > -DEBUG- (Apache Gump generated) Apache Maven Settings in: > /srv/gump/public/workspace/logging-log4j-12/gump_mvn_settings.xml > -INFO- Failed with reason build failed > -DEBUG- Maven POM in: /srv/gump/public/workspace/logging-log4j-12/pom.xml > -DEBUG- Extracted fallback artifacts from Gump Repository > > > > The following work was performed: > http://gump-vm.apache.org/logging-log4j-12/logging-log4j-12/gump_work/build_logging-log4j-12_logging-log4j-12.html > Work Name: build_logging-log4j-12_logging-log4j-12 (Type: Build) > Work ended in a state of : Failed > Elapsed: 2 secs > Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true > -Dmaven.javadoc.failOnError=false --settings > /srv/gump/public/workspace/logging-log4j-12/gump_mvn_settings.xml package > [Working Directory: /srv/gump/public/workspace/logging-log4j-12] > M2_HOME: /opt/maven2 > - > [INFO] Scanning for projects... > Downloading: > http://localhost:8192/maven2/org/apache/felix/maven-bundle-plugin/2.1.0/maven-bundle-plugin-2.1.0.pom > [WARNING] Unable to get resource > 'org.apache.felix:maven-bundle-plugin:pom:2.1.0' from repository central > (http://repo1.maven.org/maven2): Error transferring file: Server returned > HTTP response code: 501 for URL: > http://localhost:8192/maven2/org/apache/felix/maven-bundle-plugin/2.1.0/maven-bundle-plugin-2.1.0.pom > Downloading: > http://localhost:8192/maven/2/org/apache/felix/maven-bundle-plugin/2.1.0/maven-bundle-plugin-2.1.0.pom > 0b downloaded (maven-bundle-plugin-2.1.0.pom) > [WARNING] *** CHECKSUM FAILED - Invalid checksum file - RETRYING > Downloading: > http://localhost:8192/maven/2/org/apache/felix/maven-bundle-plugin/2.1.0/maven-bundle-plugin-2.1.0.pom > 0b downloaded (maven-bundle-plugin-2.1.0.pom) > [WARNING] *** CHECKSUM FAILED - Invalid checksum file - IGNORING > [INFO] Unable to find resource > 'org.apache.felix:maven-bundle-plugin:pom:2.1.0' in
Re: BATCH: All dressed up, with nowhere to go...
FYI: The gump-vm instance (the new one) is taking a little over 6 hours for a complete run. I am currently starting some of the runs manually to try and get three runs a day rather than two. I will also take a look at the machine specs and the configuration of the long running Tomcat tests to see if the Tomcat tests can be configured to run a little faster. Mark On 13/06/2019 06:26, g...@gump-vm.apache.org wrote: > Dear Gumpmeisters, > > The following 5 notifys should have been sent > > *** G U M P > [GUMP@gump-vm]: Module commons-digester-2.x failed > [GUMP@gump-vm]: Project commons-digester (in module commons-digester-2.x) > failed > [GUMP@gump-vm]: Project commons-jxpath (in module commons-jxpath) failed > [GUMP@gump-vm]: Project test-ant (in module ant) failed > [GUMP@gump-vm]: Project commons-bcel (in module apache-commons) failed > *** G U M P > [GUMP@gump-vm]: Module commons-digester-2.x failed > To whom it may engage... > > This is an automated request, but not an unsolicited one. For > more information please visit http://gump.apache.org/nagged.html, > and/or contact the folk at general@gump.apache.org. > > Module commons-digester-2.x has an issue affecting its community integration, > and has been outstanding for 72 runs. > The current state of this module is 'Failed', with reason 'Update Failed'. > > Full details are available at: > http://gump-vm.apache.org/commons-digester-2.x/index.html > > That said, some information snippets are provided here. > > The following annotations (debug/informational/warning/error messages) were > provided: > -INFO- Failed with reason update failed > > > > The following work was performed: > http://gump-vm.apache.org/commons-digester-2.x/gump_work/update_commons-digester-2.x.html > Work Name: update_commons-digester-2.x (Type: Update) > Work ended in a state of : Failed > Elapsed: > Command Line: svn --quiet checkout > http://svn.apache.org/repos/asf/commons/proper/digester/branches/DIGESTER_2_X > --non-interactive commons-digester-2.x > [Working Directory: /srv/gump/public/workspace/cvs] > - > svn: E17: URL > 'http://svn.apache.org/repos/asf/commons/proper/digester/branches/DIGESTER_2_X' > doesn't exist > - > > To subscribe to this information via syndicated feeds: > - RSS: http://gump-vm.apache.org/commons-digester-2.x/rss.xml > - Atom: http://gump-vm.apache.org/commons-digester-2.x/atom.xml > > == Gump Tracking Only === > Produced by Apache Gump(TM) version 2.3. > Gump Run 2019061306, gump-vm.apache.org:vmgump:2019061306 > Gump E-mail Identifier (unique within run) #1. > > *** G U M P > [GUMP@gump-vm]: Project commons-digester (in module commons-digester-2.x) > failed > To whom it may engage... > > This is an automated request, but not an unsolicited one. For > more information please visit http://gump.apache.org/nagged.html, > and/or contact the folk at general@gump.apache.org. > > Project commons-digester has an issue affecting its community integration, > and has been outstanding for 72 runs. > The current state of this project is 'Failed', with reason 'Update Failed'. > > Full details are available at: > http://gump-vm.apache.org/commons-digester-2.x/commons-digester/index.html > > That said, some information snippets are provided here. > > The following annotations (debug/informational/warning/error messages) were > provided: > -DEBUG- Sole jar output [commons-digester-2.2-SNAPSHOT.jar] identifier set > to project name > -WARNING- Bad *Optional* Dependency. Project: velocity-engine : unknown to > *this* workspace > -INFO- Failed with reason update failed > -INFO- Failed to extract fallback artifacts from Gump Repository > > To subscribe to this information via syndicated feeds: > - RSS: http://gump-vm.apache.org/commons-digester-2.x/commons-digester/rss.xml > - Atom: > http://gump-vm.apache.org/commons-digester-2.x/commons-digester/atom.xml > > == Gump Tracking Only === > Produced by Apache Gump(TM) version 2.3. > Gump Run 2019061306, gump-vm.apache.org:vmgump:2019061306 > Gump E-mail Identifier (unique within run) #2. > > *** G U M P > [GUMP@gump-vm]: Project commons-jxpath (in module commons-jxpath) failed > To whom it may engage... > > This is an automated request, but not an unsolicited one. For > more information please visit http://gump.apache.org/nagged.html, > and/or contact the folk at general@gump.apache.org. > > Project commons-jxpath has an issue affecting its community integration. > This issue affects 4 projects, > and has been outstanding for 72 runs. > The
Re: BATCH: All dressed up, with nowhere to go...
On 22/04/18 20:02, Stefan Bodewig wrote: > On 2018-04-22, Mark Thomas wrote: > >> I think I've fixed this. > > Don't forget to update the checked out copy on vmgump-vm3 (I forgot to > do so for hamcrest-library :-). All good on that one. I didn't know the packages were in svn. I added the JAR to vmgump-vm3 first then did 'svn st' to see if it needed to be checked it ;) Mark - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: BATCH: All dressed up, with nowhere to go...
On 2018-04-22, Mark Thomas wrote: > I think I've fixed this. Don't forget to update the checked out copy on vmgump-vm3 (I forgot to do so for hamcrest-library :-). Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: BATCH: All dressed up, with nowhere to go...
I think I've fixed this. Sorry for the noise. Mark On 22/04/18 18:46, g...@vmgump-vm3.apache.org wrote: > Dear Gumpmeisters, > > The following 1 notifys should have been sent > > *** G U M P > [GUMP@vmgump-vm3]: Project eclipse (in module eclipse) failed > *** G U M P > [GUMP@vmgump-vm3]: Project eclipse (in module eclipse) failed > To whom it may engage... > > This is an automated request, but not an unsolicited one. For > more information please visit http://gump.apache.org/nagged.html, > and/or contact the folk at general@gump.apache.org. > > Project eclipse has an issue affecting its community integration. > This issue affects 17 projects. > The current state of this project is 'Failed', with reason 'Bad Package > Installation'. > For reference only, the following projects are affected by this: > - eclipse : The Eclipse jars > - forrest-test : Apache Forrest software is a publishing framework that > trans... > - forrest-test-basic : Apache Forrest software is a publishing framework > that trans... > - forrest-test-deploy-plugins : Apache Forrest software is a publishing > framework that trans... > - tomcat-tc7.0.x : Tomcat 7.x, a web server implementing Java Servlet > 3.0, > ... > - tomcat-tc7.0.x-test-apr : Tomcat 7.x, a web server implementing Java > Servlet 3.0, > ... > - tomcat-tc7.0.x-test-bio : Tomcat 7.x, a web server implementing Java > Servlet 3.0, > ... > - tomcat-tc7.0.x-test-nio : Tomcat 7.x, a web server implementing Java > Servlet 3.0, > ... > - tomcat-tc8.0.x : Tomcat 8.x, a web server implementing the Java > Servlet 3.1, > ... > - tomcat-tc8.0.x-test-apr : Tomcat 8.x, a web server implementing the > Java Servlet 3.1, > ... > - tomcat-tc8.0.x-test-bio : Tomcat 8.x, a web server implementing the > Java Servlet 3.1, > ... > - tomcat-tc8.0.x-test-nio : Tomcat 8.x, a web server implementing the > Java Servlet 3.1, > ... > - tomcat-tc8.0.x-test-nio2 : Tomcat 8.x, a web server implementing the > Java Servlet 3.1, > ... > - tomcat-trunk : Tomcat 9.x, a web server implementing the Java Servlet > 4.0, > ... > - tomcat-trunk-test-apr : Tomcat 9.x, a web server implementing the Java > Servlet 4.0, > ... > - tomcat-trunk-test-nio : Tomcat 9.x, a web server implementing the Java > Servlet 4.0, > ... > - tomcat-trunk-test-nio2 : Tomcat 9.x, a web server implementing the > Java Servlet 4.0, > ... > > > Full details are available at: > http://vmgump-vm3.apache.org/eclipse/eclipse/index.html > > That said, some information snippets are provided here. > > The following annotations (debug/informational/warning/error messages) were > provided: > -INFO- This is a packaged project, location: /srv/gump/packages/eclipse > -INFO- Failed with reason bad package installation > -ERROR- Missing Packaged Output: > /srv/gump/packages/eclipse/plugins/R-4.7.3a-201803300640/ecj-4.7.3a.jar > > To subscribe to this information via syndicated feeds: > - RSS: http://vmgump-vm3.apache.org/eclipse/eclipse/rss.xml > - Atom: http://vmgump-vm3.apache.org/eclipse/eclipse/atom.xml > > == Gump Tracking Only === > Produced by Apache Gump(TM) version 2.3. > Gump Run 20180422180006, vmgump-vm3.apache.org:vmgump:20180422180006 > Gump E-mail Identifier (unique within run) #1. > > > -- > Apache Gump > http://gump.apache.org/ [Instance: vmgump-vm3] > > - > To unsubscribe, e-mail: general-unsubscr...@gump.apache.org > For additional commands, e-mail: general-h...@gump.apache.org > - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: BATCH: All dressed up, with nowhere to go...
There was an svn glitch overnight. Things should sort themselves out in the next run. Mark On 15/03/18 01:23, g...@vmgump-vm3.apache.org wrote: > Dear Gumpmeisters, > > The following 24 notifys should have been sent > > *** G U M P > [GUMP@vmgump-vm3]: Module pdfbox failed > [GUMP@vmgump-vm3]: Project pdfbox-parent (in module pdfbox) failed > [GUMP@vmgump-vm3]: Module apache-httpd failed > [GUMP@vmgump-vm3]: Project apache-httpd-buildconf (in module apache-httpd) > failed > [GUMP@vmgump-vm3]: Module tomcat-taglibs failed > [GUMP@vmgump-vm3]: Project apache-httpd-configure (in module apache-httpd) > failed > [GUMP@vmgump-vm3]: Module xml-stylebook failed > [GUMP@vmgump-vm3]: Project xml-stylebook2 (in module xml-stylebook) failed > [GUMP@vmgump-vm3]: Module jakarta-servletapi-5 failed > [GUMP@vmgump-vm3]: Project jakarta-servletapi-5-servlet (in module > jakarta-servletapi-5) failed > [GUMP@vmgump-vm3]: Module commons-codec-1.x failed > [GUMP@vmgump-vm3]: Project commons-codec (in module commons-codec-1.x) failed > [GUMP@vmgump-vm3]: Project txt2html-task (in module jakarta-servletapi-5) > failed > [GUMP@vmgump-vm3]: Module forrest failed > [GUMP@vmgump-vm3]: Module tomcat-7.0.x failed > [GUMP@vmgump-vm3]: Module tomcat-8.0.x failed > [GUMP@vmgump-vm3]: Module tomcat-trunk failed > [GUMP@vmgump-vm3]: Project compress-antlib-test (in module antlibs-compress) > failed > [GUMP@vmgump-vm3]: Module jakarta-bsf failed > [GUMP@vmgump-vm3]: Project fontbox (in module pdfbox) failed > [GUMP@vmgump-vm3]: Module xmlgraphics-commons failed > [GUMP@vmgump-vm3]: Module xmlsec failed > [GUMP@vmgump-vm3]: Module commons-digester-2.x failed > [GUMP@vmgump-vm3]: Project test-ant (in module ant) failed > *** G U M P > [GUMP@vmgump-vm3]: Module pdfbox failed > To whom it may engage... > > This is an automated request, but not an unsolicited one. For > more information please visit http://gump.apache.org/nagged.html, > and/or contact the folk at general@gump.apache.org. > > Module pdfbox has an issue affecting its community integration, > and has been outstanding for 54 runs. > The current state of this module is 'Failed', with reason 'Update Failed'. > > Full details are available at: > http://vmgump-vm3.apache.org/pdfbox/index.html > > That said, some information snippets are provided here. > > The following annotations (debug/informational/warning/error messages) were > provided: > -INFO- Failed with reason update failed > > > > The following work was performed: > http://vmgump-vm3.apache.org/pdfbox/gump_work/update_pdfbox.html > Work Name: update_pdfbox (Type: Update) > Work ended in a state of : Failed > Elapsed: > Command Line: svn --quiet update --non-interactive pdfbox > [Working Directory: /srv/gump/public/workspace/cvs] > - > svn: E175013: Unable to connect to a repository at URL > 'http://svn.apache.org/repos/asf/pdfbox/trunk' > svn: E175013: Access to '/repos/asf/pdfbox/trunk' forbidden > - > > To subscribe to this information via syndicated feeds: > - RSS: http://vmgump-vm3.apache.org/pdfbox/rss.xml > - Atom: http://vmgump-vm3.apache.org/pdfbox/atom.xml > > == Gump Tracking Only === > Produced by Apache Gump(TM) version 2.3. > Gump Run 2018031506, vmgump-vm3.apache.org:vmgump:2018031506 > Gump E-mail Identifier (unique within run) #1. > > *** G U M P > [GUMP@vmgump-vm3]: Project pdfbox-parent (in module pdfbox) failed > To whom it may engage... > > This is an automated request, but not an unsolicited one. For > more information please visit http://gump.apache.org/nagged.html, > and/or contact the folk at general@gump.apache.org. > > Project pdfbox-parent has an issue affecting its community integration, > and has been outstanding for 54 runs. > The current state of this project is 'Failed', with reason 'Update Failed'. > > Full details are available at: > http://vmgump-vm3.apache.org/pdfbox/pdfbox-parent/index.html > > That said, some information snippets are provided here. > > The following annotations (debug/informational/warning/error messages) were > provided: > -INFO- Failed with reason update failed > > To subscribe to this information via syndicated feeds: > - RSS: http://vmgump-vm3.apache.org/pdfbox/pdfbox-parent/rss.xml > - Atom: http://vmgump-vm3.apache.org/pdfbox/pdfbox-parent/atom.xml > > == Gump Tracking Only === > Produced by Apache Gump(TM) version 2.3. > Gump Run 2018031506, vmgump-vm3.apache.org:vmgump:2018031506 > Gump E-mail Identifier (unique within run) #2. > > *** G U M P > [GUMP@vmgump-vm3]: Module apache-httpd failed > To whom it may
Re: BATCH: All dressed up, with nowhere to go...
On 24/06/2015 01:31, g...@vmgump.apache.org wrote: Dear Gumpmeisters, The following 20 notifys should have been sent *** G U M P [GUMP@vmgump]: Module apache-commons failed I've removed the broken externals caused by some components (not built by gump) moving to Git. That should fix things for the next run. Mark - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: BATCH: All dressed up, with nowhere to go...
Dear Plutomeisters, g...@vmgump.apache.org wrote: Dear Gumpmeisters, The following 1 notifys should have been sent *** G U M P [g...@vmgump]: Project portals-pluto-trunk-test (in module [portals-pluto-trunk) failed *** G U M P [g...@vmgump]: Project portals-pluto-trunk-test (in module [portals-pluto-trunk) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project portals-pluto-trunk-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - portals-pluto-trunk-test : JSR168 Container Full details are available at: http://vmgump.apache.org/gump/public/portals-pluto-trunk/portals- pluto-trunk-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/portals-pluto-trunk/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/portals-pluto-trunk/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/portals-pluto-trunk/pom.xml The following work was performed: http://vmgump.apache.org/gump/public/portals-pluto-trunk/portals-pluto- trunk-test/gump_work/build_portals-pluto-trunk_portals-pluto-trunk-test.html Work Name: build_portals-pluto-trunk_portals-pluto-trunk-test (Type: Build) Work ended in a state of : Failed Elapsed: 28 secs Command Line: mvn --batch-mode --settings /srv/gump/public/workspace/portals-pluto-trunk/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/portals-pluto-trunk] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/portals- pluto-trunk/pluto-taglib/target/pluto-taglib-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto- util/target/pluto-util-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto-container- driver-api/target/pluto-container-driver-api-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto-container- api/target/pluto-container-api-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto-portal- driver/target/pluto-portal-driver-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto- container/target/pluto-container-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto-ant- tasks/target/pluto-ant-tasks-2.0.2-SNAPSHO T.jar:/srv/gump/public/workspace/portals-pluto-trunk/maven-pluto- plugin/target/maven-pluto-plugin-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto-portal- driver-impl/t arget/pluto-portal-driver-impl-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto- portal/target/pluto-portal-2.0.2-SNAPSHOT.war - [INFO] [ [INFO] org/xmlpull/v1/XmlPullParserFactory org.xmlpull.v1.XmlPullParserFactory [INFO] [ [INFO] Trace java.lang.NoClassDefFoundError: org/xmlpull/v1/XmlPullParserFactory at com.thoughtworks.xstream.io.xml.XppDriver.createParser(XppDriver.java:57) at com.thoughtworks.xstream.io.xml.AbstractXppDriver.createReader(AbstractXppDriver.java:56) at com.thoughtworks.xstream.XStream.fromXML(XStream.java:871) at org.apache.maven.plugin.war.util.WebappStructureSerializer.fromXml(WebappStructureSerializer.java:73) at [snip] It seems somebody is building against the XStream trunk. XStream supports now generic XPP implementations. The spec requires that such an implementation can be loaded normally with the XmlPullFactory, which is unfortunately not part of the Xpp3 library. So you have to do one of this: - use directly the new Xpp3Driver circumventing the usage of the XPP factory - add xmlpull:xmlpull as dependency - use net.sf.kxml:kxml2-min instead of xpp3:xpp3_min as dependency, since it contains the XPP factory as normally required and it seems even faster Cheers, Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: BATCH: All dressed up, with nowhere to go...
[EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 5 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Project xstream (in module xstream) failed [snip] Tried to fix the descriptor... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Sep 9, 2006, at 5:51 AM, [EMAIL PROTECTED] wrote: The following work was performed: http://vmgump.apache.org/gump/public/jaxen/gump_work/update_jaxen.html Work Name: update_jaxen (Type: Update) Work ended in a state of : Failed Elapsed: Command Line: cvs -q -z3 - d :pserver:[EMAIL PROTECTED]:/home/projects/jaxen/ scm update -P -d -A [Working Directory: /usr/local/gump/public/workspace/cvs/jaxen] - /home/projects/jaxen/scm: no such repository What is up with Codehaus anyway. I'm seeing two projects fail in exactly this way. Also, their Annogen thing fails its svn checkout but I think I may have that fixed. The Subversion information on their page is broken but I found it. Jaxen and Jmock are visible through Codehaus' Fisheye. Does that mean they have been migrated to Subversion? This is not reflected through their websites and svn.{jaxen,jmock}.codehaus.org don't resolve. What can we do about this? Do we communicate with these Codehaus groups? Is there overlap? Their mailinglists don't seem to have archives. Or do we just revers-engineer their svn setup? Thanks, S. -- [EMAIL PROTECTED]http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: Important Change | Re: BATCH: All dressed up, with nowhere to go...
Gotta love this response: -[99ABF8] Leo Simons, Your ticket concerning 'Ticket: aanval.com mailconfig' has a new response. Message: System is operating as intended. Loop was already in place and prevented further damage past 10 messages. Ticket closed. --- Instruction: To respond, simply use the reply button within your email client. --- Ticket ID: 99ABF8 Email: [EMAIL PROTECTED] -- Aanval Product Support -- I might dedicate a blog entry to it :) LSD On Sun, Jul 30, 2006 at 01:42:48PM -0700, [EMAIL PROTECTED] wrote: This message is for all users sending submissions to [EMAIL PROTECTED]; ** This address is no longer receiving support or assistance submissions. ** Aanval now requires all support and assistance requests to be entered into our new form based support ticket system. To submit for support or request assistance, please visit: http://www.aanval.com/?op=pub_ticketForm or http://www.aanval.com/?op=pub_support This new system takes effect on 06/24/06 and should be used until further notice. Thank you, -- Your original message was not forwarded to support and has been deleted. You will be required to use the new form based ticket submission system. Do not reply to this email address. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important Change | Re: BATCH: All dressed up, with nowhere to go...
Leo Simons wrote: Gotta love this response: -[99ABF8] Leo Simons, Your ticket concerning 'Ticket: aanval.com mailconfig' has a new response. Message: System is operating as intended. Loop was already in place and prevented further damage past 10 messages. Ticket closed. --- I am trying to think, how do you implement a loop detection algorithm that counts the depth. Either you use headers to detect and block a loop immediately, you filter messages from yourself, or, well, what? It's hard. Someone has gone to a lot of effort to do this - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important Change | Re: BATCH: All dressed up, with nowhere to go...
On Mon, 31 Jul 2006, Leo Simons [EMAIL PROTECTED] wrote: Gotta love this response: Nice, really. --- Instruction: To respond, simply use the reply button within your email client. --- I like this part as well. I unsubscribed the Aanval address BTW. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important Change | Re: Important Change | Re: Important Change | Re: Important Change | Re: BATCH: All dressed up, with nowhere to go...
This message is for all users sending submissions to [EMAIL PROTECTED]; ** This address is no longer receiving support or assistance submissions. ** Aanval now requires all support and assistance requests to be entered into our new form based support ticket system. To submit for support or request assistance, please visit: http://www.aanval.com/?op=pub_ticketForm or http://www.aanval.com/?op=pub_support This new system takes effect on 06/24/06 and should be used until further notice. Thank you, -- Your original message was not forwarded to support and has been deleted. You will be required to use the new form based ticket submission system. Do not reply to this email address. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Important Change | Re: Important Change | Re: Important Change | Re: Important Change | Re: Important Change | Re: BATCH: All dressed up, with nowhere to go...
This message is for all users sending submissions to [EMAIL PROTECTED]; ** This address is no longer receiving support or assistance submissions. ** Aanval now requires all support and assistance requests to be entered into our new form based support ticket system. To submit for support or request assistance, please visit: http://www.aanval.com/?op=pub_ticketForm or http://www.aanval.com/?op=pub_support This new system takes effect on 06/24/06 and should be used until further notice. Thank you, -- Your original message was not forwarded to support and has been deleted. You will be required to use the new form based ticket submission system. Do not reply to this email address. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: BATCH: All dressed up, with nowhere to go...
-Original Message- From: Sander Temme [mailto:[EMAIL PROTECTED] Sent: Sun 3/5/2006 4:39 PM To: Gump code and data Subject: Re: BATCH: All dressed up, with nowhere to go... On Mar 5, 2006, at 2:43 AM, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]: Project junit (in module junit) failed So, what is the scenario when something like this happens? Do the JUnit folks know? Care? Do we just wait for them to get their s**t together? It looks like somebody forgot to do a 'cvs add' before they did a 'cvs ci'. The current Gump descriptor doesn't nag / so they won't have found out about it from us (although there just was a long discussion of it on [EMAIL PROTECTED] :). Given how inactive the CVS is, I'm guessing that they simply don't know (it works for the person that broke it, and nobody else has done a 'cvs up ant' :). Normally, we just wait for them to get their s**t together. If anybody is on their mailing list (or cares to join :), they could point it out to the JUnit developers. However, if you just want to get your system up and running, it looks easy to patch: $ cd cvs/junit/junit/runner $ cp Version.java Version.java.template Personally, I'm for giving them more time to work out their constipation issues (or, I'd have done the above myself already :). However, it is killing a big part of Gump, so won't complain if somebody wants to 'fix' this outside of the JUnit project. FWIW blowing away the checkout doesn't seem to help. S. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: BATCH: All dressed up, with nowhere to go...
Bill Barker wrote on Monday, March 06, 2006 2:12 AM: -Original Message- From: Sander Temme [mailto:[EMAIL PROTECTED] Sent: Sun 3/5/2006 4:39 PM To: Gump code and data Subject: Re: BATCH: All dressed up, with nowhere to go... On Mar 5, 2006, at 2:43 AM, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]: Project junit (in module junit) failed So, what is the scenario when something like this happens? Do the JUnit folks know? Care? Do we just wait for them to get their s**t together? It looks like somebody forgot to do a 'cvs add' before they did a 'cvs ci'. The current Gump descriptor doesn't nag / so they won't have found out about it from us (although there just was a long discussion of it on [EMAIL PROTECTED] :). Given how inactive the CVS is, I'm guessing that they simply don't know (it works for the person that broke it, and nobody else has done a 'cvs up ant' :). Add David Saff [saff at mit.edu] into the nag if he agrees, he's currently doing the job. [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)
On Nov 1, 2005, at 9:31 PM, Stefan Bodewig wrote: Can you use a striplinebreaks filter reader in your loadfile task? Definitely. I hadn't thought of that. Checked in, should build tomorrow. Thanks again, Stefan! andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)
On Mon, 31 Oct 2005, Andrew McIntyre [EMAIL PROTECTED] wrote: This output, recorded to a file using the output attribute of an Ant exec task, is then read back in to a property using Ant's loadfile task. Ant diligently includes the newline as a part of the property read in from the file, which I'm sure is correct behavior on the part of Ant. Can you use a striplinebreaks filter reader in your loadfile task? This would throw out any line feeds and should allow us to build derby without upgrading svn. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)
On Oct 29, 2005, at 6:31 AM, Stefan Bodewig wrote: I can't promise to find time to do more research No worries, I got it. :-) Most trivial idea: ${changenumber} expands to a value that ends with a new-line or a cariage-return new-line sequence. This guess is correct, and it turns out that it's a subversion problem, not an Ant or platform issue. The problem is that 'svnversion -n .' is returning a value that contains a newline when the directory whose version you are getting is 'exported,' when it should not be adding a newline. (FWIW, i think the problem is at svnversion's main.c, line 287.) This output, recorded to a file using the output attribute of an Ant exec task, is then read back in to a property using Ant's loadfile task. Ant diligently includes the newline as a part of the property read in from the file, which I'm sure is correct behavior on the part of Ant. Go Ant! :-D When the property is later added to the manifest, it includes the newline, which causes the manifest to be invalid. I'll need to follow up with the subversion folks. Thanks for all the help from the gumpers! andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)
On Oct 31, 2005, at 12:12 AM, Andrew McIntyre wrote: it turns out that it's a subversion problem, not an Ant or platform issue. The problem is that 'svnversion -n .' is returning a value that contains a newline when the directory whose version you are getting is 'exported,' when it should not be adding a newline. I'll need to follow up with the subversion folks. Thanks for all the help from the gumpers! FYI, fixed in Subversion 1.2.x with revision 10987 to Subversion. Which means, of course, that it exists with Subversion 1.1.4 which is currently in use with Gump. An upgrade to Subversion 1.2.x should fix the Derby build problem. cheers, andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)
On Wed, 26 Oct 2005, Andrew McIntyre [EMAIL PROTECTED] wrote: That's what I suspected, but any idea why Ant would do that on vmgump, but not elsewhere? I can't promise to find time to do more research Here's the first few lines of the manifest task: manifest file=${derby.jar.dir}/lists/smf.mf attribute name=Bundle-Vendor value=Apache Software Foundation/ attribute name=Bundle-Name value=Apache Derby ${major}.$ {minor}/ attribute name=Bundle-Version value=${major}.${minor}.$ {maint}.${changenumber}/ Most trivial idea: ${changenumber} expands to a value that ends with a new-line or a cariage-return new-line sequence. vmgump is Linux, this could happen if the property gets read from a file that has extra cariage returns (checked in binary on a Windows box, for example). Other than that, a bug in Ant's trunk version? Can you try building Ant for yourself and give it a try? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)
Hi andrew, Don't really understand the problem but I've put the db-derby dir from vmgump at http://vmgump.apache.org/derby-gump-snapshot.tgz please holler when we can remove it. cheers! Leo On Tue, Oct 25, 2005 at 03:11:01PM -0700, Andrew McIntyre wrote: Just noticed that this is still failing. I am unable to reproduce the problem. Please see my previous mail concerning this problem. It would appear on the surface to be an issue with how Ant generates the manifest file in the derbyjarwithoutosgi target. Is there any way that I can get access to the manifest file in the zone where gump is run to compare with a copy generated outside of the gump run? cheers, andrew On 10/25/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: *** G U M P ... [EMAIL PROTECTED]: Project derby (in module db-derby) failed ... snip other failures *** G U M P [EMAIL PROTECTED]: Project derby (in module db-derby) failed snip other targets derbyjarwithoutosgi: [jar] Building jar: /x1/gump/public/workspace/db-derby/jars/insane/derby.jar [jar] Manifest is invalid: Manifest sections should start with a Name attribute and not Sealed BUILD FAILED /x1/gump/public/workspace/db-derby/build.xml:775: The following error occurred while executing this line: /x1/gump/public/workspace/db-derby/build.xml:854: Invalid Manifest: /x1/gump/public/workspace/db-derby/jars/insane/lists/smf.mf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)
On Oct 27, 2005, at 7:19 AM, Leo Simons wrote: Hi andrew, Don't really understand the problem but I've put the db-derby dir from vmgump at http://vmgump.apache.org/derby-gump-snapshot.tgz please holler when we can remove it. I've got the file, so you can go ahead and remove it. Thanks much, Leo! andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)
On Tue, 25 Oct 2005, Andrew McIntyre [EMAIL PROTECTED] wrote: Just noticed that this is still failing. I am unable to reproduce the problem. At least on vmgump there is an empty line in smf.mf between Bundle-Version in the main section and Sealed: true. This line makes the Sealed attribute the first one of a new section, which in turn makes the manifest invalid. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)
On Oct 26, 2005, at 9:22 PM, Stefan Bodewig wrote: At least on vmgump there is an empty line in smf.mf between Bundle-Version in the main section and Sealed: true. This line makes the Sealed attribute the first one of a new section, which in turn makes the manifest invalid. That's what I suspected, but any idea why Ant would do that on vmgump, but not elsewhere? Here's the first few lines of the manifest task: manifest file=${derby.jar.dir}/lists/smf.mf attribute name=Bundle-Vendor value=Apache Software Foundation/ attribute name=Bundle-Name value=Apache Derby ${major}.$ {minor}/ attribute name=Bundle-Version value=${major}.${minor}.$ {maint}.${changenumber}/ attribute name=Sealed value=true/ section name=org/apache/derby/impl/tools/sysinfo/ attribute name=Sealed value=false/ /section .. /manifest What I get is: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.2 Created-By: 1.4.2 Bundle-Vendor: Apache Software Foundation Bundle-Name: Apache Derby 10.2 Bundle-Version: 10.2.0.233223 Sealed: true Name: org/apache/derby/impl/tools/sysinfo/ Sealed: false .. Any clues? Maybe an old, invalid manifest hanging around that's not being overwritten? Thanks, andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Derby build (Re: BATCH: All dressed up, with nowhere to go...)
Just noticed that this is still failing. I am unable to reproduce the problem. Please see my previous mail concerning this problem. It would appear on the surface to be an issue with how Ant generates the manifest file in the derbyjarwithoutosgi target. Is there any way that I can get access to the manifest file in the zone where gump is run to compare with a copy generated outside of the gump run? cheers, andrew On 10/25/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: *** G U M P ... [EMAIL PROTECTED]: Project derby (in module db-derby) failed ... snip other failures *** G U M P [EMAIL PROTECTED]: Project derby (in module db-derby) failed snip other targets derbyjarwithoutosgi: [jar] Building jar: /x1/gump/public/workspace/db-derby/jars/insane/derby.jar [jar] Manifest is invalid: Manifest sections should start with a Name attribute and not Sealed BUILD FAILED /x1/gump/public/workspace/db-derby/build.xml:775: The following error occurred while executing this line: /x1/gump/public/workspace/db-derby/build.xml:854: Invalid Manifest: /x1/gump/public/workspace/db-derby/jars/insane/lists/smf.mf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Aug 19, 2005, at 5:27 AM, [EMAIL PROTECTED] wrote: derbyjarwithoutosgi: [jar] Building jar: /x1/gump/public/workspace/db-derby/jars/ insane/derby.jar [jar] Manifest is invalid: Manifest sections should start with a Name attribute and not Sealed BUILD FAILED /x1/gump/public/workspace/db-derby/build.xml:770: The following error occurred while executing this line: /x1/gump/public/workspace/db-derby/build.xml:849: Invalid Manifest: /x1/gump/public/workspace/db-derby/jars/insane/lists/smf.mf I'm unable to reproduce this error myself. From the error, it would seem that Ant has generated a bad manifest file in the manifest task of the derbyjarwithoutosgi target, presumably by putting space between the other top-level attributes and the top-level Sealed attribute. Works for me in my view, though. Is this maybe an Ant issue? Or stale files hanging around somehow? Would it be possible to get access to the bad manifest to better understand the problem? Thanks, andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Mon, 15 Aug 2005, Andrew McIntyre [EMAIL PROTECTED] wrote: I've attached a patch which updates the URLs (and adds repository/db-svn.xml), Didn't reach the list, but I think I managed to guess it. but I think someone is going to have to go to where the source is checked out on vmgump and 'svn switch' the source to the new URL. I simply removed the working copy so gump will replace it on the next run, same for a few other broken modules (the directory stuff). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On 8/15/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 11 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Module db-derby success, but with warnings. *** G U M P snip Work ended in a state of : Failed Elapsed: 6 secs Command Line: svn --quiet update --non-interactive db-derby [Working Directory: /usr/local/gump/public/workspace/cvs] - svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within This is due to Derby's recent graduation and move out of the incubator, along with its source tree, to live in the db part of the repository. I've attached a patch which updates the URLs (and adds repository/db-svn.xml), but I think someone is going to have to go to where the source is checked out on vmgump and 'svn switch' the source to the new URL. I think there may still be an error to deal with past that, but at least the source will resume updating properly. Thanks, andrew A repository\db-svn.xml M project\db-derby.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On 24-06-2005 15:25, Stefan Bodewig [EMAIL PROTECTED] wrote: On Fri, 24 Jun 2005, Adam R. B. Jack [EMAIL PROTECTED] wrote: Yes, I look for module failures and even worse for module success but with warnings. The later usually means stuff has been moved in svn, we are now unable to check it out, but Gump doesn't consider it a failure. Want this to go away now that SF.net have their CVS act together we are doing a lot of SVN migrations? No, it doesn't go away. FWIW, the algorithm I have in my head (come to apachecon! We can talk about it! :-)) would mean that a migrated project would be *-ed, ie built and linked against but considered to have an error, and that the corresponding module would be considered failed, and that the failure cause for the project would point to the module. The following e-mails would be sent: - to the module owner about the problem (every day) - to the project owner about the problem if it doesn't go (after n days...in the event module owner and project owner are the same its just one e-mail listing two problems) - to the gump list in a summary e-mail (every day) that lists the problems with causes, the owners of the affected modules, and the duration in that state Basically, we make modules (and repositories and other parts of the object model) first-class citizens in the gump world, and support notification about them just as well or just as bad as for projects. Cheers! Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Mon, 27 Jun 2005, Leo Simons [EMAIL PROTECTED] wrote: FWIW, the algorithm I have in my head (come to apachecon! We can talk about it! :-)) I'll be there - and at the hackathon. Plenty of time to discuss it. would mean that a migrated project would be *-ed, ie built and linked against but considered to have an error, and that the corresponding module would be considered failed, and that the failure cause for the project would point to the module. Sounds fine. The following e-mails would be sent: - to the module owner about the problem (every day) only works if the module owner is able to change the module defintion in Gump's metadata. Basically, we make modules (and repositories and other parts of the object model) first-class citizens in the gump world, and support notification about them just as well or just as bad as for projects. +1 Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
Does anyone ever do anything with the content of these messages? Yes, I look for module failures and even worse for module success but with warnings. The later usually means stuff has been moved in svn, we are now unable to check it out, but Gump doesn't consider it a failure. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
Does anyone ever do anything with the content of these messages? Yes, I look for module failures and even worse for module success but with warnings. The later usually means stuff has been moved in svn, we are now unable to check it out, but Gump doesn't consider it a failure. Want this to go away now that SF.net have their CVS act together we are doing a lot of SVN migrations? As I know you'll recall, this was due to cvs updates from SF.net working/failing/working/failing ... and with junit at that repository a failure was causing huge parts of the tree not to be built. If currently says if I have a copy and an update fails I'll simple warn it is stale not set it as failed. Want this to be fail is fail -- or configurable on the module/repository? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Fri, 24 Jun 2005, Adam R. B. Jack [EMAIL PROTECTED] wrote: Yes, I look for module failures and even worse for module success but with warnings. The later usually means stuff has been moved in svn, we are now unable to check it out, but Gump doesn't consider it a failure. Want this to go away now that SF.net have their CVS act together we are doing a lot of SVN migrations? No, it doesn't go away. Velocity tools recently moved from /jakarta/velocity-tools/trunk to /jakarta/velocity/tools/trunk and dvsl did the same. Velocity itself went from /jakarta/velocity/trunk to /jakarta/velocity/core/trunk. Now that people have the option of moving stuff around in SVN, they will start to do so ;-) Want this to be fail is fail -- or configurable on the module/repository? Yes, please. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
Hi gang, Does anyone ever do anything with the content of these messages? I tend to use them as a gauge of gump ran and it sent e-mail, but as the actual content I would much rather have something like a list of failures/successes, i.e. a condensed version of log.html. Do you agree? Just planning for the future here... Cheers, LSD On 23-06-2005 12:57, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 7 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Module castor success, but with warnings. [EMAIL PROTECTED]: Project nant (in module nant) failed [EMAIL PROTECTED]: Module jaxen success, but with warnings. [EMAIL PROTECTED]: Project txt2html-task (in module jakarta-servletapi-5) success, but with warnings. [EMAIL PROTECTED]: Project httpunit (in module httpunit) failed [EMAIL PROTECTED]: Project derby-split-2 (in module db-derby) failed [EMAIL PROTECTED]: Project jaxen (in module jaxen) failed *** G U M P [EMAIL PROTECTED]: Module castor success, but with warnings. To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Module castor contains errors. The current state of this module is 'Success'. Full details are available at: http://vmgump.apache.org/gump/public/castor/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://vmgump.apache.org/gump/public/castor/gump_work/update_castor.html Work Name: update_castor (Type: Update) Work ended in a state of : Failed Elapsed: 11 secs Command Line: cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:/scm/castor update -P -d -A [Working Directory: /usr/local/gump/public/workspace/cvs/castor] - cvs server: failed to create lock directory for `/scm/castor/castor/lib/tests' (/home/projects/castor/haus.d/lock/cvs/castor/lib/tests/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/scm/castor/castor/lib/tests' cvs [server aborted]: read lock failed - giving up - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/castor/rss.xml - Atom: http://vmgump.apache.org/gump/public/castor/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2323062005, vmgump.apache.org:vmgump-public:2323062005 Gump E-mail Identifier (unique within run) #1. *** G U M P [EMAIL PROTECTED]: Project nant (in module nant) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project nant has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 46 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - nant : NAnt is a free .NET build tool. In theory it is kind of like... Full details are available at: http://vmgump.apache.org/gump/public/nant/nant/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/nant/nant/gump_work/build_nant_nant.html Work Name: build_nant_nant (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: make [Working Directory: /usr/local/gump/public/workspace/nant] - mkdir -p bootstrap cp -R lib/ bootstrap/lib # Mono loads log4net before privatebinpath is set-up, so we need this in the same directory # as NAnt.exe cp lib/log4net.dll bootstrap cp src/NAnt.Console/App.config bootstrap/NAnt.exe.config mcs -target:exe -define:MONO -out:bootstrap/NAnt.exe -r:bootstrap/log4net.dll \ -recurse:src/NAnt.Console/*.cs src/CommonAssemblyInfo.cs Compilation succeeded resgen src/NAnt.Core/Resources/Strings.resx bootstrap/NAnt.Core.Resources.Strings.resources make: resgen: Command not found make: *** [bootstrap/NAnt.Core.dll] Error 127 - To subscribe to this information via syndicated feeds: - RSS:
Re: BATCH: All dressed up, with nowhere to go...
I also use it as you use it, a sanity check that it ran (and these days -- on vmgump -- didn't stall.) That said, I also often eyeball it for candidates that I can go bug. When Gump is stable, sending notifications as needed, it annoys me if ASF projects don't accept notification. I also go and (politely) as other projects if they'll accept notification. That, I could do that w/ or w/o this e-mail. The other one like this (i.e. failed to send, not nowhere to send) is more interesting, e.g. when the host (vmgump) isn't allowed to relay: http://issues.apache.org/jira/browse/INFRA-365 regards, Adam - Original Message - From: Leo Simons [EMAIL PROTECTED] To: Gump code and data general@gump.apache.org Sent: Thursday, June 23, 2005 1:26 PM Subject: Re: BATCH: All dressed up, with nowhere to go... Hi gang, Does anyone ever do anything with the content of these messages? I tend to use them as a gauge of gump ran and it sent e-mail, but as the actual content I would much rather have something like a list of failures/successes, i.e. a condensed version of log.html. Do you agree? Just planning for the future here... Cheers, LSD On 23-06-2005 12:57, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 7 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Module castor success, but with warnings. [EMAIL PROTECTED]: Project nant (in module nant) failed [EMAIL PROTECTED]: Module jaxen success, but with warnings. [EMAIL PROTECTED]: Project txt2html-task (in module jakarta-servletapi-5) success, but with warnings. [EMAIL PROTECTED]: Project httpunit (in module httpunit) failed [EMAIL PROTECTED]: Project derby-split-2 (in module db-derby) failed [EMAIL PROTECTED]: Project jaxen (in module jaxen) failed *** G U M P [EMAIL PROTECTED]: Module castor success, but with warnings. To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Module castor contains errors. The current state of this module is 'Success'. Full details are available at: http://vmgump.apache.org/gump/public/castor/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://vmgump.apache.org/gump/public/castor/gump_work/update_castor.html Work Name: update_castor (Type: Update) Work ended in a state of : Failed Elapsed: 11 secs Command Line: cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:/scm/castor update -P -d -A [Working Directory: /usr/local/gump/public/workspace/cvs/castor] - cvs server: failed to create lock directory for `/scm/castor/castor/lib/tests' (/home/projects/castor/haus.d/lock/cvs/castor/lib/tests/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/scm/castor/castor/lib/tests' cvs [server aborted]: read lock failed - giving up - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/castor/rss.xml - Atom: http://vmgump.apache.org/gump/public/castor/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2323062005, vmgump.apache.org:vmgump-public:2323062005 Gump E-mail Identifier (unique within run) #1. *** G U M P [EMAIL PROTECTED]: Project nant (in module nant) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project nant has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 46 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - nant : NAnt is a free .NET build tool. In theory it is kind of like... Full details are available at: http://vmgump.apache.org/gump/public/nant/nant/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/nant/nant/gump_work/build_nant_nant.html Work Name: build_nant_nant (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs
Re: BATCH: All dressed up, with nowhere to go...
On Thu, 24 Mar 2005, [EMAIL PROTECTED] wrote: failed -ERROR- Synchronize Failed: Unicode Error. Can't copy ['spec1109ab\xe7d\xe9'] in [u'/usr/local/gump/public/workspace/cvs/xml-xalan/test/tests/accept/spec11'] to [u'/usr/local/gump/public/workspace/xml-xalan/test/tests/accept/spec11']: ['ascii' codec can't decode byte 0xe7 in position 11: ordinal not in range(128)] Is this responsible for the java_cup and jlex failures as well? The jars are present in /usr/local/gump/public/workspace/cvs/xml-xalan/java/bin/ No, they also are in /usr/local/gump/public/workspace/xml-xalan/java/bin/ Any idea what has happened? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
does this mean that you worked around log4j? On Nov 30, 2004, at 1:10 PM, [EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 2 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Module jakarta-velocity success [EMAIL PROTECTED]: Project werken.xpath (in module jakarta-velocity) success *** G U M P [EMAIL PROTECTED]: Module jakarta-velocity success To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Module jakarta-velocity *no longer* has an issue. The current state of this module is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-velocity/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://brutus.apache.org/gump/public/jakarta-velocity/gump_work/ update_jakarta-velocity.html Work Name: update_jakarta-velocity (Type: Update) Work ended in a state of : Failed Elapsed: Command Line: svn --quiet update --non-interactive jakarta-velocity [Working Directory: /usr/local/gump/public/workspace/cvs] - svn: 'jakarta-velocity' is not a working copy - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-velocity/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-velocity/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18000930112004, brutus:brutus-public:18000930112004 Gump E-mail Identifier (unique within run) #1. *** G U M P [EMAIL PROTECTED]: Project werken.xpath (in module jakarta-velocity) success To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project werken.xpath *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-velocity/werken.xpath/ index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [werken.xpath.jar] identifier set to project name -INFO- No license on redistributable project with outputs. To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-velocity/werken.xpath/ rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-velocity/werken.xpath/ atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18000930112004, brutus:brutus-public:18000930112004 Gump E-mail Identifier (unique within run) #2. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: BATCH: All dressed up, with nowhere to go...
Hi all, I am a bit confused by this.. Is this message saying that the module level work, which I guess is checking out from CVS, worked properly, but then the build failed? I followed the link provided and everything says Success. Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 8:42 PM To: [EMAIL PROTECTED] Subject: BATCH: All dressed up, with nowhere to go... Dear Gumpmeisters, The following 2 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Module dumbster success [EMAIL PROTECTED]: Project dumbster (in module dumbster) failed *** G U M P [EMAIL PROTECTED]: Module dumbster success To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Module dumbster *no longer* has an issue. The current state of this module is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/dumbster/index.html That said, some information snippets are provided here. The following work was performed: http://brutus.apache.org/gump/public/dumbster/gump_work/update_dum bster.html Work Name: update_dumbster (Type: Update) Work ended in a state of : Success Elapsed: 2 secs Command Line: cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:2401/cvsroot/dumbster update -P -d -A [Working Directory: /usr/local/gump/public/workspace/cvs/dumbster] - No output - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/dumbster/rss.xml - Atom: http://brutus.apache.org/gump/public/dumbster/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 19000925112004, brutus:brutus-public:19000925112004 Gump E-mail Identifier (unique within run) #1. *** G U M P [EMAIL PROTECTED]: Project dumbster (in module dumbster) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project dumbster has an issue affecting its community integration. This issue affects 2 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-email : Commons Email Package - dumbster : The Dumbster is a very simple fake SMTP server designed for ... Full details are available at: http://brutus.apache.org/gump/public/dumbster/dumbster/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [dumbster.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/dumbster/dumbster/gump_work/b uild_dumbster_dumbster.html Work Name: build_dumbster_dumbster (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/jav a/build/xercesImpl.jar:/usr/local/gump/public/work space/xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only world [Working Directory: /usr/local/gump/public/workspace/dumbster] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/dumbste r/build/classes:/usr/local/gump/public/workspace/dumbster/build/te st:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar :/usr/local/gump/public/workspace/ant/dist/lib/ant -jmf.jar:/usr/local/gump /public/workspace/ant/dist/lib/ant-swing.j ar:/usr/local/gump/public/workspace/ant/dist/lib/a nt-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-juni t.jar:/usr/local/gump/public/workspace/ant/dist/li b/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/a nt-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.ja r:/usr/local/gump/packages/jaf-1.0.1/activation.jar:/usr/local/gum p/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/j avamail-1.3.2/mail.jar:/usr/local/gump/packages/javamail-1.3.2/lib /mailapi.jar - Buildfile: build.xml init: [mkdir] Created dir: /home/gump/workspaces2/public/workspace/dumbster/build/classes [mkdir] Created dir: /home/gump/workspaces2/public/workspace/dumbster/build/test
Re: BATCH: All dressed up, with nowhere to go...
[EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 4 notifys should have been sent [EMAIL PROTECTED]: Module lenya success, but with warnings. There is something wrong. Lenya is not successful at all! -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
[EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 4 notifys should have been sent [EMAIL PROTECTED]: Module lenya success, but with warnings. There is something wrong. Lenya is not successful at all! This stems from the old days when SF.net CVS was so flaky. Basically, if we attempt to do a CVS|SVN update and fail -- but we have old code (yesterdays) -- we look the other way (setting this error message below). If we didn't we'd been sending out failures (and not building trees) with no real reason (just a suspicion.) Error *** Failed to update from source control. Stale contents *** We probably ought only allow this to occur for a finite period. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED]: Module james-server success, but with warnings. this should be fixed (was looking in the wrong directory of the repository) [EMAIL PROTECTED]: Project txt2html-task (in module jakarta-servletapi-5) success, but with warnings. this is due to this line !-- not a jar, but I don't see a way to create one either -- jar name=jsr152/build/ant/ the task seems not to be generating a jar, can we publish a directory of classes instead of a jar? is jar dir=/ allowed? [EMAIL PROTECTED]: Module werkz success, but with warnings. the werkz module is gone and Maven is the only one that depends on it. Should we blast it? [EMAIL PROTECTED]: Project jtidy-cvs (in module jtidy) failed this requires these maven plugins maven-sourceforge-plugin-1.0.jar maven-statcvs-plugin-2.4.jar maven-findbugs-plugin-0.8.4.jar maven-xhtml-plugin-1.2.jar maven-checkstyle-plugin-2.4.1.jar so I just added them to the maven repository on brutus (kudos to Eric for the IRC help!) [EMAIL PROTECTED]: Project jetty-plus (in module jetty) failed I added the JMX jar to the jetty project, this should make this work -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: BATCH: All dressed up, with nowhere to go...
Gump wrote: Dear Gumpmeisters, The following 1 notifys should have been sent Sorry folks, this run got away on me. Please go about your business, nothing to see here. :) -- Sometimes the Universe needs a change of perspective. --J. Michael Straczynski smime.p7s Description: S/MIME Cryptographic Signature
Re: BATCH: All dressed up, with nowhere to go...
On Thu, 14 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: Instead, I suggest that we take the prettyprinter.jar from the xdoclet CVS and make it into an installed package in Gump. Just create a project for it inside xdoclet's descriptor. Name it xdoclet-pretty or something. No need to turn it into a full installed package (which would require access to Brutus to update) IMHO. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: BATCH: All dressed up, with nowhere to go...
-Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: 14 October 2004 06:59 To: Gump code and data Subject: Re: BATCH: All dressed up, with nowhere to go... On Thursday 14 October 2004 12:33, Niclas Hedhman wrote: I would suggest we mavenize xdoclet and remove jrefactory and friends since they are clearly not enough friends of gump to live in the house with him. I will start on it straight away... IIUIC, Xdoclet is not yet Mavenized. They use Ant as the build system, and call upon Maven for the documentation generation. Instead, I suggest that we take the prettyprinter.jar from the xdoclet CVS and make it into an installed package in Gump. WDYT? Yep. /Steve. Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Thursday 14 October 2004 14:38, Stefan Bodewig wrote: On Thu, 14 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: Instead, I suggest that we take the prettyprinter.jar from the xdoclet CVS and make it into an installed package in Gump. Just create a project for it inside xdoclet's descriptor. Name it xdoclet-pretty or something. No need to turn it into a full installed package (which would require access to Brutus to update) IMHO. Done. But not entirely sure if it will work. Review appreciated. + project name=xdoclet-prettyprinter +jar name=lib/prettyprinter.jar/ + /project -depend project=jrefactory-pretty/ +depend project=xdoclet-prettyprinter/ Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
Niclas Hedhman wrote: On Thursday 14 October 2004 12:33, Niclas Hedhman wrote: I would suggest we mavenize xdoclet and remove jrefactory and friends since they are clearly not enough friends of gump to live in the house with him. I will start on it straight away... IIUIC, Xdoclet is not yet Mavenized. They use Ant as the build system, and call upon Maven for the documentation generation. Instead, I suggest that we take the prettyprinter.jar from the xdoclet CVS and make it into an installed package in Gump. +1! -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: BATCH: All dressed up, with nowhere to go...
Stefan Bodewig wrote: On Thu, 14 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: Instead, I suggest that we take the prettyprinter.jar from the xdoclet CVS and make it into an installed package in Gump. Just create a project for it inside xdoclet's descriptor. Name it xdoclet-pretty or something. No need to turn it into a full installed package (which would require access to Brutus to update) IMHO. right! even better! -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: BATCH: All dressed up, with nowhere to go...
On Thursday 14 October 2004 12:33, Niclas Hedhman wrote: I would suggest we mavenize xdoclet and remove jrefactory and friends since they are clearly not enough friends of gump to live in the house with him. I will start on it straight away... IIUIC, Xdoclet is not yet Mavenized. They use Ant as the build system, and call upon Maven for the documentation generation. Instead, I suggest that we take the prettyprinter.jar from the xdoclet CVS and make it into an installed package in Gump. WDYT? Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Thursday 14 October 2004 12:17, Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]: Project findbugs (in module findbugs) failed [javac] Compiling 371 source files to /usr/local/gump/public/workspace/findbugs/build/classes [javac] javac: invalid target release: jsr14 I turns out that xdoclet - jrefactory-pretty - jrefactory - findbugs and findbugs *NEEDS* jdk 1.5 I think this is fucked up. Yes, I can confirm this is the case. Including that the findbugs.jar that is part of the jrefactory CVS checkout contains JDK1.4 incompatible classes, so jrefactory doesn't build either from its CVS checkout. now, xdoclet appears to be using maven now, and that dependency on jrefactory-pretty is gone in their POM. I would suggest we mavenize xdoclet and remove jrefactory and friends since they are clearly not enough friends of gump to live in the house with him. I will start on it straight away... Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
At 11:45 AM 8/23/2004, you wrote: Dear Gumpmeisters, The following 13 notifys should have been sent *** G U M P [snip] [EMAIL PROTECTED]: jetty/jetty-plus failed *** G U M P [snip] Regarding the jetty-plus build failure, I would like to note that as far as log4j tests are concerned, we are not interested in the jetty API but its ability to act as a web-server with JNDI support. From our perspective, it would be sufficient to link to jetty-plus.jar without building jetty afresh each day. In other words, we are more interested in gumps ability to run test scripts regularly on different platforms rather then its ability to track API changes and resolve compatibility issues. These are related but distinct goals. Just my 2c. -- Ceki Gülcü - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
Stefan Bodewig wrote: [EMAIL PROTECTED]: mx4j/mx4j-tools-from-packaged-jetty failed The top item on my TODO list. A real API compatibility problem between mx4j and Axis. hehehe. It's high on mine too...I need jetty to build :D Another random thought: it would be nice to be able to annotate parts of the build tree with comments like this. As in being able to attach a comment to the failure state of mx4j/mx4j-tools-from-packaged-jetty. With comments CCed to the mailing list of course :D -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Thu, 25 Mar 2004, Leo Simons [EMAIL PROTECTED] wrote: hehehe. It's high on mine too...I need jetty to build :D You can fall back to the packaged jetty for the time being. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Wed, 24 Mar 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: Tapestry is a problem in itself, since the Gump descriptor is inside the tapestry module. A manual nag together with a patch to the descriptor may help. Number two on my TODO list, helping hands welcome 8-) Actually it is number three since jelly-tags-ant is holding up a lot and it may even be a backwards compatibility problem in Ant. I may try using the 1.5 branch of Ant to see whether it works there. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Tue, 23 Mar 2004, Adam Jack [EMAIL PROTECTED] wrote: Can we find a community e-mail address that would possible be willing to 'hear' these, and approach them? Difficult, the issues are too diverse. Let's look at them case by case [EMAIL PROTECTED]: webwork/webwork failed At least one missing dependcy. We just build this project as a detector for some Apache projects. I doubt that they are aware that Gump is building the project. [EMAIL PROTECTED]: mx4j/mx4j-tools-from-packaged-jetty failed The top item on my TODO list. A real API compatibility problem between mx4j and Axis. [EMAIL PROTECTED]: freemarker/freemarker failed Uses old jdom API. Same as webwork. [EMAIL PROTECTED]: jakarta-tapestry/ognl failed Tapestry is a problem in itself, since the Gump descriptor is inside the tapestry module. A manual nag together with a patch to the descriptor may help. Number two on my TODO list, helping hands welcome 8-) [EMAIL PROTECTED]: javasrc/javasrc failed Nag! [EMAIL PROTECTED]: xml-xerces/xml-xerces1 failed Simply needs 1.4.2_04 on LSD, not a problem with the project. [EMAIL PROTECTED]: jakarta-turbine-tdk/jakarta-turbine-tdk-docs failed Odd. Works fine on gump.covalent.net. We should work this out before we nag anybody. [EMAIL PROTECTED]: eyebrowse/eyebrowse failed Missing Mysql JDBC driver. Similar to webwork (they don't know what we are doing with their project). [EMAIL PROTECTED]: castor/castor failed Missing work entry. Similar to webwork, but this time we really need to build it since some of our projects (jetspeed, pluto) depend on it. [EMAIL PROTECTED]: jrefactory/jrefactory failed See webwork. It would probably suffice to turn the pretty printer it into an installed package. [EMAIL PROTECTED]: jgen/jgen failed Hasn't upgraded to later released versions of FOP in years (looks more or less dead[1]), will probably never build. Only project that depends on it is Turbine 3 which itself hasn't built since years. Could be turned into an installed package. On the other hand it is quite possible that they've never been told that jgen doesn't build against any recent FOP version. We could ask the FOP people for advice and send a patch to the jgen list to bring them up to FOP 0.20.5. Low on my personal priority list. Stefan Footnotes: [1] http://sourceforge.net/mailarchive/forum.php?forum_id=2500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
These are just the ones that don't have a nag entry, so don't have anywhere to be sent -- hence they return to the Gumpmeisters. I believe Nicola has plans for javasrc. regards Adam - Original Message - From: Stefano Mazzocchi [EMAIL PROTECTED] To: Gump code and data [EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 9:09 AM Subject: Re: BATCH: All dressed up, with nowhere to go... [EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 6 nags should have been sent G U M P [EMAIL PROTECTED]: webwork/webwork failed [EMAIL PROTECTED]: jakarta-tapestry/ognl failed [EMAIL PROTECTED]: javasrc/javasrc failed [EMAIL PROTECTED]: jetty/jetty failed [EMAIL PROTECTED]: xml-xerces/xml-xerces1 failed [EMAIL PROTECTED]: eyebrowse/eyebrowse failed is this all? you gotta be kidding! and what about the stuff at http://lsd.student.utwente.nl/gump/project_todos.html Ah, another thing, javasrc is failing, not used by anybody and hosted on sourceforge. Why are we building it? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
Change the wording to The following projects had failures but I don't know who to notify. I looked at the code, to modify it but it was unclear which line was for unwanted and which was for unsent. Adam R. B. Jack wrote: These are just the ones that don't have a nag entry, so don't have anywhere to be sent -- hence they return to the Gumpmeisters. I believe Nicola has plans for javasrc. regards Adam - Original Message - From: Stefano Mazzocchi [EMAIL PROTECTED] To: Gump code and data [EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 9:09 AM Subject: Re: BATCH: All dressed up, with nowhere to go... [EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 6 nags should have been sent G U M P [EMAIL PROTECTED]: webwork/webwork failed [EMAIL PROTECTED]: jakarta-tapestry/ognl failed [EMAIL PROTECTED]: javasrc/javasrc failed [EMAIL PROTECTED]: jetty/jetty failed [EMAIL PROTECTED]: xml-xerces/xml-xerces1 failed [EMAIL PROTECTED]: eyebrowse/eyebrowse failed is this all? you gotta be kidding! and what about the stuff at http://lsd.student.utwente.nl/gump/project_todos.html Ah, another thing, javasrc is failing, not used by anybody and hosted on sourceforge. Why are we building it? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
this is a very cool feature. I just love all the intelligence that gump is developing lately! -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]