Time for xpp to go to packaged project
The module for xpp no longer updates, and the site says that it is no longer developed. So it looks like it is time to package it. Just sending this out in case someone has an opinion before I go ahead and do it. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
cocoon status
It seem that cocoon has moved a lot of their external svn links. So the first step to fixing it is to wipe the cvs/cocoon directory, and then find where everything moved to. Since cocoon only depends on cocoon, this is more work than I want to do. But sharing my research incase anyone wants to put the work into fixing it. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Resolving reference to commons-io-*[0-9T].jar file in a property
I forgot some of my python coding basics, but can recheckin the fix to
trunk, even if I haven't fully tested it (setting up packaged projects is a
PIB). That is probably the best move, since it is now now failing for
non-globbed projects in my test. So can see if it will run on trunk before
moving to live.
-Original Message-
From: Konstantin Kolinko
Sent: Tuesday, April 17, 2012 4:39 PM
To: Gump code and data
Subject: Resolving reference to commons-io-*[0-9T].jar file in a property
Hi!
It is essentially the same issue that I wrote about a year ago, [1]
Now it is occurring in jakarta-tomcat-catalina project [2]. It
started to nagging dev@tomcat on April 12th, but I do not see what
could cause it. I guess that earlier it did not run due to some
dependency. Another change is that commons-io 2.3 was released about
that time.
The problem: When Tomcat 5.5 builds it needs to copy commons-io.jar
into its Manager webapp. There is the following code in its Ant
file:
/tomcat/tc5.5.x/trunk/container/webapps/manager/build.xml
[[[
target name=copy-io.jar
copy todir=${webapps.build}/${webapp.name}/WEB-INF/lib
file=${commons-io.jar}/
/target
]]]
In Gump this is configured in project/jakarta-tomcat-catalina.xml as
ant ...
depend property=commons-io.jar project=commons-io /
/ant
It results in
[[[
BUILD FAILED
/srv/gump/public/workspace/jakarta-tomcat-catalina/build.xml:74: The
following error occurred while executing this line:
/srv/gump/public/workspace/jakarta-tomcat-catalina/webapps/build.xml:58:
The following error occurred while executing this line:
/srv/gump/public/workspace/jakarta-tomcat-catalina/webapps/manager/build.xml:56:
Warning: Could not find file
/srv/gump/public/workspace/apache-commons/io/target/commons-io-*[0-9T].jar
to copy.
]]]
The actual name of the file is commons-io-2.4-SNAPSHOT.jar [3]
Should I change the dependency to explicitly name the file? Like this:
property name=commons-io.jar project=commons-io
path=io/target/commons-io-2.4-SNAPSHOT.jar /
or there is a chance to make those patterns to work?
[1] Dependency on checkstyle.jar in tomcat-trunk-validate returns
glob instead of actual name, 2011-04
http://markmail.org/message/to3dvdwwciqzgrgh
[2] jakarta-tomcat-catalina project summary
http://vmgump.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/index.html
[3] apache-commons/commons-io Build output
http://vmgump.apache.org/gump/public/apache-commons/commons-io/gump_work/build_apache-commons_commons-io.html
Best regards,
Konstantin Kolinko
-
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: Resolving reference to commons-io-*[0-9T].jar file in a property
s/now now/now not/
-Original Message-
From: Bill Barker
Sent: Tuesday, April 17, 2012 9:40 PM
To: Gump code and data
Subject: Re: Resolving reference to commons-io-*[0-9T].jar file in a
property
I forgot some of my python coding basics, but can recheckin the fix to
trunk, even if I haven't fully tested it (setting up packaged projects is a
PIB). That is probably the best move, since it is now now failing for
non-globbed projects in my test. So can see if it will run on trunk before
moving to live.
-Original Message-
From: Konstantin Kolinko
Sent: Tuesday, April 17, 2012 4:39 PM
To: Gump code and data
Subject: Resolving reference to commons-io-*[0-9T].jar file in a property
Hi!
It is essentially the same issue that I wrote about a year ago, [1]
Now it is occurring in jakarta-tomcat-catalina project [2]. It
started to nagging dev@tomcat on April 12th, but I do not see what
could cause it. I guess that earlier it did not run due to some
dependency. Another change is that commons-io 2.3 was released about
that time.
The problem: When Tomcat 5.5 builds it needs to copy commons-io.jar
into its Manager webapp. There is the following code in its Ant
file:
/tomcat/tc5.5.x/trunk/container/webapps/manager/build.xml
[[[
target name=copy-io.jar
copy todir=${webapps.build}/${webapp.name}/WEB-INF/lib
file=${commons-io.jar}/
/target
]]]
In Gump this is configured in project/jakarta-tomcat-catalina.xml as
ant ...
depend property=commons-io.jar project=commons-io /
/ant
It results in
[[[
BUILD FAILED
/srv/gump/public/workspace/jakarta-tomcat-catalina/build.xml:74: The
following error occurred while executing this line:
/srv/gump/public/workspace/jakarta-tomcat-catalina/webapps/build.xml:58:
The following error occurred while executing this line:
/srv/gump/public/workspace/jakarta-tomcat-catalina/webapps/manager/build.xml:56:
Warning: Could not find file
/srv/gump/public/workspace/apache-commons/io/target/commons-io-*[0-9T].jar
to copy.
]]]
The actual name of the file is commons-io-2.4-SNAPSHOT.jar [3]
Should I change the dependency to explicitly name the file? Like this:
property name=commons-io.jar project=commons-io
path=io/target/commons-io-2.4-SNAPSHOT.jar /
or there is a chance to make those patterns to work?
[1] Dependency on checkstyle.jar in tomcat-trunk-validate returns
glob instead of actual name, 2011-04
http://markmail.org/message/to3dvdwwciqzgrgh
[2] jakarta-tomcat-catalina project summary
http://vmgump.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/index.html
[3] apache-commons/commons-io Build output
http://vmgump.apache.org/gump/public/apache-commons/commons-io/gump_work/build_apache-commons_commons-io.html
Best regards,
Konstantin Kolinko
-
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
-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
xml-commons RIP
It seems that xml-commons' repository has gone away. I found this out while testing a local version of Gump that had no checkouts. Given that it is stale, and in the boot-classpath of just about every ant project, it should go away for modern JVMs. I just want opinions on options. As I see it the choices are: 1) leave the stale projects, but remove the boot attribute. Upside, least amount of work. Downside, nobody will be able to set up a fresh Gump. 2) make the projects empty, and think of something for the couple of projects that have a property .../ depend (or just let them fail). 3) remove it completely and edit a large number of projects that refer to it 4) Ignore the problem completely until there is a break with the JVM. My personal preference is in order 2,1,4,3, but want to hear other opinions first. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: xml-commons RIP
-Original Message- From: Konstantin Kolinko Sent: Saturday, April 14, 2012 7:47 PM To: Gump code and data Subject: Re: xml-commons RIP 2012/4/15 Bill Barker billwbar...@verizon.net: It seems that xml-commons' repository has gone away. I found this out while testing a local version of Gump that had no checkouts. Given that it is stale, and in the boot-classpath of just about every ant project, it should go away for modern JVMs. I just want opinions on options. As I see it the choices are: 1) leave the stale projects, but remove the boot attribute. Upside, least amount of work. Downside, nobody will be able to set up a fresh Gump. 2) make the projects empty, and think of something for the couple of projects that have a property .../ depend (or just let them fail). 3) remove it completely and edit a large number of projects that refer to it 4) Ignore the problem completely until there is a break with the JVM. My personal preference is in order 2,1,4,3, but want to hear other opinions first. I did not find it in ASF Attic so I went on looking into svn log. So I see that it was moved into /xerces/xml-commons: http://svn.apache.org/viewvc?view=revisionrevision=1311708 http://svn.apache.org/viewvc/xerces/xml-commons/trunk/ About the above list of options : I do not understand what you meant by 2). You clear the metadata file of that module? Or you meant start over with empty list of modules in profile/gump.xml? Regarding 3) the only projects that explicitly refer to xml-commons are ant, ant-1.8.x, xml-xerces2. That is not much. The rest should be an indirect dependency. I wonder whether Ant really needs it. When dealing with svn repositories it is also possible to 5) freeze them in time by setting certain peg and operative revisions. I do not know whether Gump supports that (as it defeats its purpose), but it might be doable. If those repository paths are passed to command-line client as is, this syntax might be already working: svn repository=asf dir=xml/commons/trunk@1311707/ I am not doing any updates to the metadata now - I think you would better try on a standalone Gump that you have, because so many projects depend on it. Best regards, Konstantin Kolinko Well, you did more research than me :). So that gives the option 6) reset the svn .../ tag to point to the new location That would make 6) my favorite now, but still wonder if xml-api should still be on the boot classpath anymore with modern JVMs. By 2) I meant something like : project name=xml-api /project in the Gump metadata. It will resolve for the couple hundred ant projects that use it, but use the JVM's xml parser. There are a couple of old (and largely dead) projects that reference a project in xml-api via a property .../ tag. And almost every ant build references it since it (used to be) needed at runtime to boot up ant. - 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
Some help with maven
I'm trying to set up docbkx to run under Gump. Unfortunately the reactor build runs into an incompatibility with Gump's version of fop. However this is to resolve a dependency from coocon3 on docbkx (since the maven-central version looks broken for a long time) and it doesn't look like it wants the fop component. The problem I am having is that the parent pom http://vmgump.apache.org/gump/public/google-docbkx/google-docbkx/gump_file/pom.xml.html is also building a component. I'm asking if there is a setting or target in maven that would cause it to build only its tools component and skip the reactor build? Then I can then just build the plugin components as separate projects. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: svn commit: r1303274 - /gump/metadata/repository/google-guava.xml
-Original Message- From: Stefan Bodewig Sent: Tuesday, March 20, 2012 10:28 PM To: general@gump.apache.org Subject: Re: svn commit: r1303274 - /gump/metadata/repository/google-guava.xml On 2012-03-21, Bill Barker wrote: It seems that I've forgotten my opie password on vmgump. I've changed your password, there is a file in your home dir holding the new one. You can use opiepasswd to change it again. Ha ha, very funny :). I actually can speak German. Could someone clear the google-guava cvs repository? That's not necessary, gump will detect the new scm definition doesn't match what is on the disk and remove the old directory by itself. Stefan - 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: svn commit: r1303274 - /gump/metadata/repository/google-guava.xml
It seems that I've forgotten my opie password on vmgump. Could someone clear the google-guava cvs repository? I doubt it will go down well with infra, but changing the umask for gump to include group-writable and adding me to the gump group would allow me to do this sort of routine cleanup without having access to sudo. -Original Message- From: billbar...@apache.org Sent: Tuesday, March 20, 2012 9:11 PM To: comm...@gump.apache.org Subject: svn commit: r1303274 - /gump/metadata/repository/google-guava.xml Author: billbarker Date: Wed Mar 21 04:11:40 2012 New Revision: 1303274 URL: http://svn.apache.org/viewvc?rev=1303274view=rev Log: It seems that guava has moved to git, but still not sure this will work Modified: gump/metadata/repository/google-guava.xml Modified: gump/metadata/repository/google-guava.xml URL: http://svn.apache.org/viewvc/gump/metadata/repository/google-guava.xml?rev=1303274r1=1303273r2=1303274view=diff == --- gump/metadata/repository/google-guava.xml (original) +++ gump/metadata/repository/google-guava.xml Wed Mar 21 04:11:40 2012 @@ -16,13 +16,13 @@ limitations under the License. -- -repository name=google-guava type=svn +repository name=google-guava type=git titleGoogle Guava/title home-pagehttp://code.google.com/p/guava-libraries//home-page webhttp://code.google.com/p/guava-libraries/source/browse/trunk/web - urlhttp://guava-libraries.googlecode.com/svn/trunk//url + urlhttps://code.google.com/p/guava-libraries//url redistributable/ /repository - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: compatibility issue
-- From: Ludmila Shikhvarg ludmila.shikhv...@oracle.com Sent: Monday, November 08, 2010 5:47 PM To: general@gump.apache.org Subject: compatibility issue Hi, I'm a new gump user and started to use gump for jdk compatibility testing. I'm using gump source from https://svn.apache.org/repos/asf/gump/trunk/ (use http://gump.apache.org/gettingstarted.html as a reference) with different build of jdk7 from https://jdk7.dev.java.net/index.html Some projects (exp: junit, hamcrest) are failed to build due to: [javac] javac: target release 1.5 conflicts with default source release 1.7 Is it a known issue? Where can I report any issues related to jdk7? Welcome to the Gump community! Gump doesn't normally override these properties (and doesn't for the two projects you mentioned). So normally you have to contact the projects themselves and lobby to change their build settings. The main purpose of Gump is to give projects warning that changes down the road will cause them to break, so what you are doing fits with Gump. The junit project has generally been responsive to changes, but haven't worked with hamcrest. Since both the projects you mentioned are Ant builds, another possibility is to lobby Ant to change their defaults. The mailing list for that is d...@ant.apache.org. However, since I'm not really involved with Ant personally, I don't know what their community feels about such a change. It is possible that Stefan can weigh in on that if he wants to. Thanks, Ludmila - 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: Problem with collections test dependency
-- From: sebb seb...@gmail.com Sent: Sunday, September 12, 2010 5:00 AM To: general@gump.apache.org Subject: Problem with collections test dependency Digester depends on collections, but fails at run-time because the class org/apache/commons/collections/FastHashMap is not present. However, the classpath includes commons-collections-3.3-SNAPSHOT.jar which should include this class. Is there a way to get access to the jar to check its contents? I thought you had a login account on vmgump. But anyway: billbar...@vmgump:~/gump/public/workspace/commons-collections-3.x/target$ jar tf commons-collections-3.3-SNAPSHOT.jar | grep Fast org/apache/commons/collections/FastArrayList$SubList$SubListIter.class org/apache/commons/collections/FastHashMap.class org/apache/commons/collections/FastHashMap$CollectionView$CollectionViewIterator.class org/apache/commons/collections/FastHashMap$EntrySet.class org/apache/commons/collections/FastTreeMap.class org/apache/commons/collections/FastTreeMap$Values.class org/apache/commons/collections/FastTreeMap$1.class org/apache/commons/collections/FastHashMap$Values.class org/apache/commons/collections/FastArrayList.class org/apache/commons/collections/FastArrayList$SubList.class org/apache/commons/collections/FastHashMap$CollectionView.class org/apache/commons/collections/FastHashMap$KeySet.class org/apache/commons/collections/FastTreeMap$EntrySet.class org/apache/commons/collections/FastHashMap$1.class org/apache/commons/collections/FastArrayList$ListIter.class org/apache/commons/collections/FastTreeMap$CollectionView$CollectionViewIterator.class org/apache/commons/collections/FastTreeMap$KeySet.class org/apache/commons/collections/FastTreeMap$CollectionView.class Is it possible that the test phase is picking up the wrong collections jar somehow? The project commons-collections4 isn't doing an 'install' target, so shouldn't be overwriting commons-collections. However the commons-digester build log shows: Downloading: http://localhost:8192/maven2/commons-collections/commons-collections/2.0/commons-collections-2.0.jar Downloading: http://localhost:8192/maven2/org/codehaus/plexus/plexus-velocity/1.1.3/plexus-velocity-1.1.3.jar 566K downloaded (commons-collections-2.0.jar) Is there a way to show the classpath used by Surefire? Don't know enough about M2 to answer this one. Note that collections4 does not contain FastHashMap. - 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: [g...@vmgump]: Project dist-xerces (in module xml-xerces2) failed
All ASF committers have access to the Gump metadata. Simply check out https://svn.apache.org/repos/asf/gump/metadata and make the changes that you want in the file under project, and check it in. -- From: Michael Glavassevich mrgla...@ca.ibm.com Sent: Saturday, August 14, 2010 8:25 AM To: j-...@xerces.apache.org Cc: general@gump.apache.org Subject: Re: [g...@vmgump]: Project dist-xerces (in module xml-xerces2) failed Looks like Gump recently changed over to using Open JDK 6 and that causes something in the Apache Stylebook to fail. No one works on that component anymore so don't see how this could be fixed (aside from switching Gump over to a JDK which Stylebook actually works with). We have no plans to move off of Stylebook for generating Xerces' documentation. Perhaps 'dist-xerces' should be disabled for now or at least the nag e-mails which are becoming noise on our development mailing list. Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org Sam Ruby ru...@us.ibm.com wrote on 08/13/2010 09:12:15 PM: 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 dist-xerces has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 12 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - dist-xerces : Java XML Parser - the sequel with no equal Full details are available at: http://vmgump.apache.org/gump/public/xml-xerces2/dist-xerces/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/xml-xerces2/dist-xerces/ gump_work/build_xml-xerces2_dist-xerces.html Work Name: build_xml-xerces2_dist-xerces (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 41 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java - Djava.awt.headless=true -Dant.build.clonevm=true -Xbootclasspath/p:/ srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar:/srv/ gump/public/workspace/xml-xalan/build/serializer.jar:/srv/gump/ public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/ workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/ merge.xml -Dbuild.sysclasspath=only pack-bin [Working Directory: /srv/gump/public/workspace/xml-xerces2] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/ public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/ lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant- junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/ srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/ gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/ packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml- commons/java/build/resolver.jar:/srv/gump/public/workspace/xml- xerces2/tools/bin/xjavac.jar:/srv/gump/public/workspace/xml- stylebook/bin/stylebook-1.0-b3_xalan-2.jar:/srv/gump/public/ workspace/xml-commons/java/external/build/xml-apis-ext.jar - [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL sheet sbk:/style/ stylesheets/any2project.xsl [java] [Xalan2Processor] Applying XSL
Re: expat-configure problem
Yes, the problem is that the version of libtool is too new. The buildconf script needs to copy additional files to make this work on vmgump's version of autoconf. From google, it seems that the expat project knows this as well. Since this has to be done by the project, not much we can do with the existing setup. However, I made a copy of expat to my home directory, and saw that if the exconf-buildconfig project uses the autoreconf as it's script, then expat seems to build fine. Of course, this means that other Gump installs would need to update their version of libtool (or it will fail on them). As such, I'm going to wait for feed back from the list before jumping in and making changes to the expat metadata. The other alternative is to downgrade libtool on vmgump. -- From: Bill Barker billwbar...@verizon.net Sent: Thursday, August 12, 2010 7:19 PM To: Gump code and data general@gump.apache.org Subject: Re: expat-configure problem It looks like this version of autoconf wants gettext installed. I've gone ahead and installed it on vmgump (apt-get install gettext). If this doesn't fix the next cycle for expat, I'll dig deeper. -- From: Bill Barker billwbar...@verizon.net Sent: Tuesday, August 10, 2010 12:43 AM To: Gump code and data general@gump.apache.org Subject: Re: expat-configure problem From the errors, it looks like it doesn't like the new 64bit environment. But I don't have login access to vmgump2 to poke around more. -- From: Stefan Bodewig bode...@apache.org Sent: Monday, August 09, 2010 8:14 AM To: general@gump.apache.org Subject: expat-configure problem Hi, is anybody around here familiar enough with autoconf or whatever is involved in the build failure to know whether we can do anything about http://vmgump.apache.org/gump/public/expat/expat-configure/gump_work/buildscript_expat_expat-configure.html? It used to work on the old vmgump (with older autotools) and still works on helios. Stefan - 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 - 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: expat-configure problem
It looks like this version of autoconf wants gettext installed. I've gone ahead and installed it on vmgump (apt-get install gettext). If this doesn't fix the next cycle for expat, I'll dig deeper. -- From: Bill Barker billwbar...@verizon.net Sent: Tuesday, August 10, 2010 12:43 AM To: Gump code and data general@gump.apache.org Subject: Re: expat-configure problem From the errors, it looks like it doesn't like the new 64bit environment. But I don't have login access to vmgump2 to poke around more. -- From: Stefan Bodewig bode...@apache.org Sent: Monday, August 09, 2010 8:14 AM To: general@gump.apache.org Subject: expat-configure problem Hi, is anybody around here familiar enough with autoconf or whatever is involved in the build failure to know whether we can do anything about http://vmgump.apache.org/gump/public/expat/expat-configure/gump_work/buildscript_expat_expat-configure.html? It used to work on the old vmgump (with older autotools) and still works on helios. Stefan - 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 - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: expat-configure problem
From the errors, it looks like it doesn't like the new 64bit environment. But I don't have login access to vmgump2 to poke around more. -- From: Stefan Bodewig bode...@apache.org Sent: Monday, August 09, 2010 8:14 AM To: general@gump.apache.org Subject: expat-configure problem Hi, is anybody around here familiar enough with autoconf or whatever is involved in the build failure to know whether we can do anything about http://vmgump.apache.org/gump/public/expat/expat-configure/gump_work/buildscript_expat_expat-configure.html? It used to work on the old vmgump (with older autotools) and still works on helios. Stefan - 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: svn commit: r953937 - /gump/metadata/project/excalibur.xml
-- From: bode...@apache.org Sent: Friday, June 11, 2010 10:18 PM To: comm...@gump.apache.org Subject: svn commit: r953937 - /gump/metadata/project/excalibur.xml Author: bodewig Date: Sat Jun 12 05:18:53 2010 New Revision: 953937 URL: http://svn.apache.org/viewvc?rev=953937view=rev Log: install excalibur-event-api POM. We need to find a better way for this kind of stuff. Why isn't the install goal pushing the POM into the local repository? This can't hurt, but it looked like we were just getting a lot of server errors here. I was going to give another cycle before diving in. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: svn commit: r941172 - in /gump/metadata/project: apache-httpd.xml logging-log4cxx.xml
-- From: bode...@apache.org Sent: Wednesday, May 05, 2010 12:05 AM To: comm...@gump.apache.org Subject: svn commit: r941172 - in /gump/metadata/project: apache-httpd.xml logging-log4cxx.xml Author: bodewig Date: Wed May 5 07:05:50 2010 New Revision: 941172 URL: http://svn.apache.org/viewvc?rev=941172view=rev Log: what would break if we removed the old apr-util branch? Urm, pretty much every thing. The problem is that current apr-util/trunk won't build with apr/trunk. IMHO this is a problem for the Apache-Apr community to work out. We could provide a legacy apr build to fix this in the meantime, but not really the Gump Way. Modified: gump/metadata/project/apache-httpd.xml gump/metadata/project/logging-log4cxx.xml Modified: gump/metadata/project/apache-httpd.xml URL: http://svn.apache.org/viewvc/gump/metadata/project/apache-httpd.xml?rev=941172r1=941171r2=941172view=diff == --- gump/metadata/project/apache-httpd.xml (original) +++ gump/metadata/project/apache-httpd.xml Wed May 5 07:05:50 2010 @@ -29,11 +29,11 @@ script name=buildconf arg name=--with-apr project=apr-make-install reference=home/ - arg name=--with-apr-util project=apr-util-make-install -reference=home/ + !--arg name=--with-apr-util project=apr-util-make-install +reference=home/-- /script depend project=apr-make-install/ -depend project=apr-util-make-install/ +!--depend project=apr-util-make-install/-- /project project name=apache-httpd-configure @@ -41,8 +41,8 @@ arg name=--prefix path=dest-@@DATE@@/ arg name=--with-apr project=apr-configure reference=home/ - arg name=--with-apr-util project=apr-util-configure -reference=home/ + !--arg name=--with-apr-util project=apr-util-configure +reference=home/-- arg name=--with-pcre project=pcre-configure reference=home/ /configure Modified: gump/metadata/project/logging-log4cxx.xml URL: http://svn.apache.org/viewvc/gump/metadata/project/logging-log4cxx.xml?rev=941172r1=941171r2=941172view=diff == --- gump/metadata/project/logging-log4cxx.xml (original) +++ gump/metadata/project/logging-log4cxx.xml Wed May 5 07:05:50 2010 @@ -31,8 +31,8 @@ !-- property name=version value=@@DATE@@/ -- property name=apr.dir project=apr-configure reference=home/ - property name=aprutil.dir project=apr-util-configure -reference=home/ + !--property name=aprutil.dir project=apr-util-configure +reference=home/-- property name=find value=false/ /ant @@ -42,7 +42,7 @@ depend project=ant-contrib-cpptasks/ depend project=ant-contrib inherit=runtime/ depend project=apr-make-install/ -depend project=apr-util-make-install/ +!--depend project=apr-util-make-install/-- nag to=carn...@apache.org from=Gump Integration Build lt;carn...@apache.orggt;/ @@ -55,8 +55,8 @@ !-- property name=version value=@@DATE@@/ -- property name=apr.dir project=apr-configure reference=home/ - property name=aprutil.dir project=apr-util-configure -reference=home/ + !--property name=aprutil.dir project=apr-util-configure +reference=home/-- property name=find value=false/ /ant @@ -66,7 +66,7 @@ depend project=ant-contrib-cpptasks/ depend project=ant-contrib inherit=runtime/ depend project=apr-make-install/ -depend project=apr-util-make-install/ +!--depend project=apr-util-make-install/-- nag to=carn...@apache.org from=Gump Integration Build lt;carn...@apache.orggt;/ @@ -79,8 +79,8 @@ !-- property name=version value=@@DATE@@/ -- property name=apr.dir project=apr-configure reference=home/ - property name=aprutil.dir project=apr-util-configure -reference=home/ + !--property name=aprutil.dir project=apr-util-configure +reference=home/-- property name=lib.type value=static/ property name=find value=false/ /ant @@ -91,7 +91,7 @@ depend project=ant-contrib-cpptasks/ depend project=ant-contrib inherit=runtime/ depend project=apr-make-install/ -depend project=apr-util-make-install/ +!--depend project=apr-util-make-install/-- nag to=carn...@apache.org from=Gump Integration Build lt;carn...@apache.orggt;/ @@ -106,11 +106,11 @@ configure arg name=--prefix path=dest-@@DATE@@/ arg name=--with-apr project=apr-make-install reference=home/ - arg name=--with-apr-util project=apr-util-make-install reference=home/ + !--arg name=--with-apr-util project=apr-util-make-install reference=home/-- /configure depend project=logging-log4cxx-autogen/ depend project=apr-make-install/ -depend
Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml
-- From: Stefan Bodewig bode...@apache.org Sent: Friday, March 19, 2010 6:39 AM To: general@gump.apache.org Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml On 2010-03-19, Antoine Levy Lambert anto...@gmx.de wrote: On 2010-03-16, Bill Barker billwbar...@verizon.net wrote: I was thinking of adding a localRepository=name to the mvn / builder that allows projects to share a local repo when they can't be trusted to use the central repo. These would be cleaned when Gump finishes (or maybe on startup). Is it the same like installing the snapshot artifacts in the local ~/.m2 cache ? Yes, I think so. Only that we'd be using a directory other than ~/.m2 that would get purged after the Gump run has finished. Yes, that is the idea. It lets a group of projects that depend on each other's snapshot artifacts to install them in a local cache where they can then be found by M2, since M2 doesn't like to get snapshot artifacts from any of the remote repos that are currently mirrored. This would also be helpful for M2 projects that define their own remote repo in the POM, that isn't mirrored, since they can't be trusted to use the common local cache (because if they have a dependency on an Ant-built project, and are the first to request it, it will get the versioned jar from their remote repo, and then other M2 projects will use that jar instead of the Gump-built jar). This would have made setting up portals-pluto-trunk much easier, instead of the sordid hack I used to convince Gump to make it the last project to build. Stefan - 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: svn commit: r920715 - /gump/metadata/project/excalibur.xml
-- From: Stefan Bodewig bode...@apache.org Sent: Monday, March 15, 2010 8:01 AM To: general@gump.apache.org Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml On 2010-03-15, Bill Barker billwbar...@verizon.net wrote: -- From: Stefan Bodewig bode...@apache.org Sent: Sunday, March 14, 2010 10:20 PM To: general@gump.apache.org Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml On 2010-03-13, Bill Barker billwbar...@verizon.net wrote: Yeah, downloaded the src distro for maven 2.2.1, and it is that it is that the 'central' repo is disabled for SNAPSHOTs (and it is looking for a SNAPSHOT POM). So Maven never asks to get it (even though it is there). Do I understand this correctly that with Maven 2.2 Gump will not be able to inject its own jars if the POM specifies a dependency on a SNAPSHOT version? I think that this is a setting for 'central', that it disables SNAPSHOT versions (understandable from the Maven prospective). It's just that Maven won't download a SNAPSHOT version from 'central'. Reactor builds with SNAPSHOT should still work. I see. SNAPSHOTs then will likely be pulled from different repositories and we'd need to make the Maven proxy intercept those as well. Or, like for hudson, they just won't be found. I was thinking of adding a localRepository=name to the mvn / builder that allows projects to share a local repo when they can't be trusted to use the central repo. These would be cleaned when Gump finishes (or maybe on startup). Then the projects could use a goal of 'install', and it looks like Maven will accept it for another project that wants to depend on that SNAPSHOT version. Briefly thought of overriding this in either the local or global settings, but then realized that I don't know enough about Maven to get it right in the first 10 tries ;). That is why I was hoping that there is still a Maven guru lurking here. Same here. Stefan - 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: svn commit: r920715 - /gump/metadata/project/excalibur.xml
-- From: Stefan Bodewig bode...@apache.org Sent: Sunday, March 14, 2010 10:20 PM To: general@gump.apache.org Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml On 2010-03-13, Bill Barker billwbar...@verizon.net wrote: Yeah, downloaded the src distro for maven 2.2.1, and it is that it is that the 'central' repo is disabled for SNAPSHOTs (and it is looking for a SNAPSHOT POM). So Maven never asks to get it (even though it is there). Do I understand this correctly that with Maven 2.2 Gump will not be able to inject its own jars if the POM specifies a dependency on a SNAPSHOT version? I think that this is a setting for 'central', that it disables SNAPSHOT versions (understandable from the Maven prospective). It's just that Maven won't download a SNAPSHOT version from 'central'. Reactor builds with SNAPSHOT should still work. Briefly thought of overriding this in either the local or global settings, but then realized that I don't know enough about Maven to get it right in the first 10 tries ;). That is why I was hoping that there is still a Maven guru lurking here. Stefan - 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: svn commit: r920715 - /gump/metadata/project/excalibur.xml
-- From: Stefan Bodewig bode...@apache.org Sent: Thursday, March 11, 2010 5:38 AM To: general@gump.apache.org Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml On 2010-03-11, Bill Barker billwbar...@verizon.net wrote: If you have any ideas why portals-pluto-trunk can't find it's parent, It isn't even trying to download it. Since I don't know enough about Maven I can't say why a repository may get disabled, but [DEBUG] Skipping disabled repository central [DEBUG] portals-pom: using locally installed snapshot [DEBUG] Skipping disabled repository central [DEBUG] Using mirror: http://localhost:8192/maven2 (id: gump-central) sounds suspicios. Yeah, downloaded the src distro for maven 2.2.1, and it is that it is that the 'central' repo is disabled for SNAPSHOTs (and it is looking for a SNAPSHOT POM). So Maven never asks to get it (even though it is there). The work-arounds that I've seen are too complex for Gump, and the project is largely dormant, so for the moment will just let it fail. Of course, if there are any Maven gurus lurking here with better ideas, would love to hear them. In particular, if there was an access-log (that I haven't found), this would be great. The mvnrepo log doesn't show it at all, but looks like it only logs 200 OK requests. The proxy uses ju.logging and I think it should be logging to stdout by default which should make it end up in Gump's own log file (since this is the parent process). I can't promise it would log failed requests, though. Stefan - 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: svn commit: r920715 - /gump/metadata/project/excalibur.xml
-- From: Stefan Bodewig bode...@apache.org Sent: Wednesday, March 10, 2010 12:27 AM To: general@gump.apache.org Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml first of all: it worked ;-) Yes, I didn't look to see that Gump was still running when I replied, so saw the old page :(. On 2010-03-10, Bill Barker billwbar...@verizon.net wrote: The maven-fortress-plugin runs with a goal of install' against the public local repo, so copies it's POM there as well as the jar file. Yes, but it installs it as -SNAPSHOT version, not the released version the excalibur projects have been looking for. Then M2 running on say excalibur-pool-impl sees it in the local repo, and thinks it has it already. Shouldn't be since it has the wrong version. Yeah, wondered about that, but couldn't see where it was getting the file from, so I guess your right, and it is packaged with the plugin. It then opens the POM, sees the wrong version number and throws a hissy fit. I still think it must be something inside the jar. 8-) It's possible that restoring the jar, but removing the 'install' goal on maven-fortress-plugin will trick M2 into getting the proxied POM, but the built plugin. I'm still working through how the mvnrepo proxy works, so this is just a guess. Let me try to help you out WRT the proxy. In general the proxy really only acts as a proxy using a few hard-coded paths to identify known Maven repos based on the request's pathinfo. Every jar in a Gump descriptor will publish a jar or POM to the repo proxy after the project containing it has finished. POMs that don't use the jar-hack will not be published to the proxy at all. Most of the time this means mvn projects will see the original POMs of the released versions but get the latest jars. If you have any ideas why portals-pluto-trunk can't find it's parent, I'd love to know them (but this is just to migrate projects off of the 1.0 release, so isn't really important now that castor is building). In particular, if there was an access-log (that I haven't found), this would be great. The mvnrepo log doesn't show it at all, but looks like it only logs 200 OK requests. Of course, I'll do the grunt-work if I only knew the right grunt ;). It looks as if such a combination would cause trouble for Maven plugins since the jar has embeded version information (at least that's my understanding of it). From: Stefan Bodewig bode...@apache.org Sent: Tuesday, March 09, 2010 12:53 AM The jar itself has been downloaded a few minutes before the build of excalibur-pool-impl so the installed version has been provided by the proxy. It shouldn't have been, unless the project that downloaded it used separateLocalRepository. No, it has just been looking for a non-SNAPSHOT version since the plugin build has only installed a -SNAPSHOT. Stefan - 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: svn commit: r920715 - /gump/metadata/project/excalibur.xml
-- From: Stefan Bodewig bode...@apache.org Sent: Tuesday, March 09, 2010 12:53 AM To: general@gump.apache.org Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml On 2010-03-09, Bill Barker billwbar...@verizon.net wrote: Don't think this is going to help. It's complaining about the installed POM, not the artifact from the mvnrepo proxy. It's complaining about Plugin's descriptor which I guess not to be the POM but some sort of descriptor contained withing the jar. No, it's the POM. The maven-fortress-plugin runs with a goal of 'install' against the public local repo, so copies it's POM there as well as the jar file. Then M2 running on say excalibur-pool-impl sees it in the local repo, and thinks it has it already. It then opens the POM, sees the wrong version number and throws a hissy fit. It's possible that restoring the jar, but removing the 'install' goal on maven-fortress-plugin will trick M2 into getting the proxied POM, but the built plugin. I'm still working through how the mvnrepo proxy works, so this is just a guess. The jar itself has been downloaded a few minutes before the build of excalibur-pool-impl so the installed version has been provided by the proxy. It shouldn't have been, unless the project that downloaded it used separateLocalRepository. This is guesswork, I know. Stefan - 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: Advise wanted on build issues
I've updated M2 on vmgump to 2.2.1. However, apt-get thinks that subversion 1.5.1 is the latest. I don't feel like manually installing 1.6.x, so lucene-java is out of luck for now. -- From: Bill Barker billwbar...@verizon.net Sent: Monday, February 22, 2010 10:56 PM To: Gump code and data general@gump.apache.org Subject: Re: Advise wanted on build issues -- From: Stefan Bodewig bode...@apache.org Sent: Monday, February 22, 2010 9:22 PM To: general@gump.apache.org Subject: Re: Advise wanted on build issues On 2010-02-21, Bill Barker billwbar...@verizon.net wrote: It looks like most of the problems related to castor-xml wanting to download an older version of itself are related to portals-pluto's dependency on it. The castor-xml build is trying to download the trunk version of castor-core from http://snapshots.repository.codehaus.org which isn't proxied by the Maven proxy. This means it will not get the version just built - and there doesn't seem to be a jar available at codehaus. So far I expected the build would heal itself at one point by a snapshot jar becoming available, but I agree it has been taking a long time by now. One alternative would be to make the Maven proxy webapp aware of the codehaus snapshots repo but that isn't trivial either (the current webapp decides which real repository to use as fallback by looking at a path prefix and there is none for this specific repository so multiple fallbacks would be needed). The current Gump portals-pluto is the 1.0 version (which has been dead for years). So one option is to switch it to be a packaged project. The other is to change portals-pluto to be the current version (which is the Gump way). The downstream dependencies of pluto are likely to require a newer version at one point anyway. But that project is huge, and so would take considerable time to set up by anyone (such as myself) that isn't familiar with it. It uses Maven 2 and a reactor, doesn't it? If so you can start out with a reactor build in a separate local repository and then add options for all things it downloads during the build. This works pretty well. Yes, it is M2 and reactor, so will try and set it up. The castor-reactor build wants Maven 2.1, which is probably a good idea to be running on Gump. True. I'm happy to do the upgrade for vmgump (and others, if granted access to them), but don't know how Maven 2 was installed in the first place. I'm guessing it was just downloaded and installed, but if it was installed by apt then it should be updated the same way. No, it has been installed manually. http://wiki.apache.org/gump/VmgumpConfig is likely outdated in many ways by now, but at least for the Maven part it still tells the truth 8-) Ok, will try and find time between builds to update on vmgump However, I'm not holding out hope that this will fix castor. It may fix the reactor build. The lucene-java build is complaining that we have an ancient version of svn installed. I'm guessing that this was installed by apt, but it would be nice to confirm before I try and update it. It should be the apt version. Ok, will update on vmgump Stefan - 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 - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Advise wanted on build issues
-- From: Stefan Bodewig bode...@apache.org Sent: Monday, February 22, 2010 9:22 PM To: general@gump.apache.org Subject: Re: Advise wanted on build issues On 2010-02-21, Bill Barker billwbar...@verizon.net wrote: It looks like most of the problems related to castor-xml wanting to download an older version of itself are related to portals-pluto's dependency on it. The castor-xml build is trying to download the trunk version of castor-core from http://snapshots.repository.codehaus.org which isn't proxied by the Maven proxy. This means it will not get the version just built - and there doesn't seem to be a jar available at codehaus. So far I expected the build would heal itself at one point by a snapshot jar becoming available, but I agree it has been taking a long time by now. One alternative would be to make the Maven proxy webapp aware of the codehaus snapshots repo but that isn't trivial either (the current webapp decides which real repository to use as fallback by looking at a path prefix and there is none for this specific repository so multiple fallbacks would be needed). The current Gump portals-pluto is the 1.0 version (which has been dead for years). So one option is to switch it to be a packaged project. The other is to change portals-pluto to be the current version (which is the Gump way). The downstream dependencies of pluto are likely to require a newer version at one point anyway. But that project is huge, and so would take considerable time to set up by anyone (such as myself) that isn't familiar with it. It uses Maven 2 and a reactor, doesn't it? If so you can start out with a reactor build in a separate local repository and then add options for all things it downloads during the build. This works pretty well. Yes, it is M2 and reactor, so will try and set it up. The castor-reactor build wants Maven 2.1, which is probably a good idea to be running on Gump. True. I'm happy to do the upgrade for vmgump (and others, if granted access to them), but don't know how Maven 2 was installed in the first place. I'm guessing it was just downloaded and installed, but if it was installed by apt then it should be updated the same way. No, it has been installed manually. http://wiki.apache.org/gump/VmgumpConfig is likely outdated in many ways by now, but at least for the Maven part it still tells the truth 8-) Ok, will try and find time between builds to update on vmgump However, I'm not holding out hope that this will fix castor. It may fix the reactor build. The lucene-java build is complaining that we have an ancient version of svn installed. I'm guessing that this was installed by apt, but it would be nice to confirm before I try and update it. It should be the apt version. Ok, will update on vmgump Stefan - 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: svn commit: r887621 - /gump/metadata/project/commons-jexl-1.x.xml
I'm guessing that it is using mine at the moment, but I don't know maven well enough to be sure. If yours works, then it is cleaner (my requires jexl-1.x to build before jexl so that the correct jar is in Gump's M2 repository and that no project that depends on jexl-1.x switches to an M2 build). So +1 to trying it without the id. - Original Message - From: Niall Pemberton niall.pember...@gmail.com To: general@gump.apache.org Sent: Sunday, December 06, 2009 11:11 AM Subject: Re: svn commit: r887621 - /gump/metadata/project/commons-jexl-1.x.xml I also tried another approach to fix this at the same time - but which change made this work - yours or mine? http://svn.apache.org/viewvc?view=revisionrevision=887616 I'm thinking of removing that id element and see if it still works with my change. Niall On Sun, Dec 6, 2009 at 12:47 AM, billbar...@apache.org wrote: Author: billbarker Date: Sun Dec 6 00:47:23 2009 New Revision: 887621 URL: http://svn.apache.org/viewvc?rev=887621view=rev Log: Let's try it without the version number and see if that makes maven happy Modified: gump/metadata/project/commons-jexl-1.x.xml Modified: gump/metadata/project/commons-jexl-1.x.xml URL: http://svn.apache.org/viewvc/gump/metadata/project/commons-jexl-1.x.xml?rev=887621r1=887620r2=887621view=diff == --- gump/metadata/project/commons-jexl-1.x.xml (original) +++ gump/metadata/project/commons-jexl-1.x.xml Sun Dec 6 00:47:23 2009 @@ -28,7 +28,7 @@ packageorg.apache.commons.jexl/package descriptionCommons Jexl 1.x/description mvn goal=package / - jar name=target/commons-jexl-1.1.1-SNAPSHOT.jar id=commons-jexl-1.1/ + jar name=target/commons-jexl-1.1.1-SNAPSHOT.jar id=commons-jexl/ option project=ant/ option project=commons-beanutils/ option project=commons-collections/ - 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: Commons Jelly - JEXL 1.x dependency
- Original Message - From: Niall Pemberton niall.pember...@gmail.com To: general@gump.apache.org Sent: Thursday, December 03, 2009 1:56 AM Subject: Commons Jelly - JEXL 1.x dependency Commons JEXL has changed its package names in the trunk (version 2.x) , so I added a JEXL 1.x project (maven 2) to gump which builds from the JEXL 1.x branch: http://svn.apache.org/repos/asf/gump/metadata/project/commons-jexl-1.x.xml Commons Jelly is a maven 1 project and I changed the dependency to commons-jexl-1.x - but its failing with the following message: The build cannot continue because of the following unsatisfied dependency:commons-jexl-1.1.jar http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/gump_work/build_commons-jelly_commons-jelly.html http://svn.apache.org/viewvc?view=revisionrevision=886220 Any idea why? If in the jexl 1.1 metadata you do: jar name=target/commons-jexl-1.1.1-SNAPSHOT.jar id=commons-jexl-1.1/then it should work for jelly. Haven't looked enough (and not familiar enough with Maven) to see if it will break someone else. Niall - 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: svn commit: r817123 - /gump/metadata/project/tomcat-tc6.xml
- Original Message - From: Stefan Bodewig bode...@apache.org To: general@gump.apache.org Sent: Sunday, September 20, 2009 9:06 PM Subject: Re: svn commit: r817123 - /gump/metadata/project/tomcat-tc6.xml On 2009-09-21, billbar...@apache.org wrote: Try and convince the maven repo to serve up the correct servlet jars We should probably remove the like-named projects from jakarta-servletapi-5.xml and start migrating all projects that use the jakarta-servlet-api project(s) over to tomcat-6's version. +1 For a start, there don't seem that many M2 projects depending on these , and just seem to want the basic API, so shouldn't be to hard to switch them to TC6. Stefan - 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: How to depend on legacy projects?
- Original Message - From: sebb seb...@gmail.com To: general@gump.apache.org Sent: Saturday, September 19, 2009 2:50 AM Subject: How to depend on legacy projects? JMeter currently depends on some legacy Excalibur modules: excalibur-datasource-1.1.1.jar excalibur-i18n-1.1.jar excalibur-instrument-1.0.jar excalibur-logger-1.1.jar excalibur-pool-1.2.jar These are currently referenced using work nested=lib/xxx. All of these are also available in Maven repos, but JMeter does not use Maven to build - is it possible to tell Gump to depend on the copies in the repo? Not really except for M2 builds, and even then you wouldn't get the specific version if Gump knows how to build it. If you need this specific version, then work ... / is probably the way to go. JMeter also depends on jCharts 0.75 and htmlparser, which are not in Maven as far as I can tell - how can one make these available to Gump? Gump used to have jCharts 0.75 as a packaged project. It could probably be resurrected. Htmlparser is a Gump project so depend project=htmlparser / is enough. - 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: Problem running Apache Gump [vmgump-public]
-Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Sunday, September 13, 2009 9:00 PM To: general@gump.apache.org Subject: Re: Problem running Apache Gump [vmgump-public] On 2009-09-09, Stefan Bodewig bode...@apache.org wrote: I'm currently working going through the code in order to see where a retry on error logic could best be introduced. Looks as if it worked. Yes, cool Stefan - 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: Problem running Apache Gump [vmgump-public]
- Original Message - From: Bill Barker billwbar...@verizon.net To: Gump code and data general@gump.apache.org Sent: Tuesday, September 08, 2009 7:11 PM Subject: Re: Problem running Apache Gump [vmgump-public] - Original Message - From: Stefan Bodewig bode...@apache.org To: general@gump.apache.org Sent: Tuesday, September 08, 2009 2:00 AM Subject: Re: Problem running Apache Gump [vmgump-public] On 2009-09-08, g...@vmgump.apache.org wrote: Failed to build project #[(704, 704)] : [test-ant], state:Failed SQL Warning:class '_mysql_exceptions.OperationalError':(2006, 'MySQL server has gone away') We keep getting this since a few weeks over and over again. I guess it started when somebody upgraded vmgump's OS (many thanks for that!) and either a newer MySQL or python-mysqldb isn't working as expected. What I can tell by now is that the database is still there (executed a few minutes after the emial arrived): It has a correlation of nearly 1 with commons-lang-2.x failing. I'm guessing that since the later event hoses all M2 builds, that Gump is temporarily running out of connections with so many projects failing quickly. It's only a theory, but it is the one that I based splitting the tests out of commons-lang-2.x. Ok, so much for that theory :(. , | r...@vmgump:/var/log# /etc/init.d/mysql status | * /usr/bin/mysqladmin Ver 8.41 Distrib 5.0.51a, for debian-linux-gnu on i486 | Copyright (C) 2000-2006 MySQL AB | This software comes with ABSOLUTELY NO WARRANTY. This is free software, | and you are welcome to modify and redistribute it under the GPL license | | Server version 5.0.51a-3ubuntu5.4 | Protocol version10 | Connection Localhost via UNIX socket | UNIX socket /var/run/mysqld/mysqld.sock | Uptime: 1 day 23 hours 11 min 10 sec | | Threads: 1 Questions: 6286 Slow queries: 0 Opens: 34 Flush tables: 1 Open tables: 28 Queries per second avg: 0.037 ` and hasn't restarted during the Gump run. http://dev.mysql.com/doc/refman/5.0/en/gone-away.html hints at various reasons why this might happen. The server side timeout is at eight hours and we shouldn't be hitting that. It seems as if the python wrapper was not enabling automatic reconnect and unfortunately the python-mysqldb version installed by hardy (1.2.2) doesn't have the ping(reconnect) method later versions have added (by looking through python-mysqldb's svn logs, that is), mysql error logs don't say anything (or I just don't find them, quite possible). My next step would be to wrap each execute() going against the database in a try/catch that clears the connection and creates a new one if an OperationalError is caught. But before I get my feet wet with another area of Python I've never used, maybe anybody knows of a better approach. BTW, after this type of error occurs we get Gump runs where bcel and many other early building mvn projects fail. This is because the mvn proxy of the previous run is still up and thinks it could serve commons-lang but the jar has already been removed by the sync operation (and thus mvn fails because it cannot download commons-lang). This needs to be fixed in a separate way, either by making sure the mvn proxy is shut down at the end or by clearing it at the start (the later is probably easier to implement). Stefan - 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 - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Problem running Apache Gump [vmgump-public]
- Original Message - From: Stefan Bodewig bode...@apache.org To: general@gump.apache.org Sent: Tuesday, September 08, 2009 2:00 AM Subject: Re: Problem running Apache Gump [vmgump-public] On 2009-09-08, g...@vmgump.apache.org wrote: Failed to build project #[(704, 704)] : [test-ant], state:Failed SQL Warning:class '_mysql_exceptions.OperationalError':(2006, 'MySQL server has gone away') We keep getting this since a few weeks over and over again. I guess it started when somebody upgraded vmgump's OS (many thanks for that!) and either a newer MySQL or python-mysqldb isn't working as expected. What I can tell by now is that the database is still there (executed a few minutes after the emial arrived): It has a correlation of nearly 1 with commons-lang-2.x failing. I'm guessing that since the later event hoses all M2 builds, that Gump is temporarily running out of connections with so many projects failing quickly. It's only a theory, but it is the one that I based splitting the tests out of commons-lang-2.x. , | r...@vmgump:/var/log# /etc/init.d/mysql status | * /usr/bin/mysqladmin Ver 8.41 Distrib 5.0.51a, for debian-linux-gnu on i486 | Copyright (C) 2000-2006 MySQL AB | This software comes with ABSOLUTELY NO WARRANTY. This is free software, | and you are welcome to modify and redistribute it under the GPL license | | Server version 5.0.51a-3ubuntu5.4 | Protocol version10 | Connection Localhost via UNIX socket | UNIX socket /var/run/mysqld/mysqld.sock | Uptime: 1 day 23 hours 11 min 10 sec | | Threads: 1 Questions: 6286 Slow queries: 0 Opens: 34 Flush tables: 1 Open tables: 28 Queries per second avg: 0.037 ` and hasn't restarted during the Gump run. http://dev.mysql.com/doc/refman/5.0/en/gone-away.html hints at various reasons why this might happen. The server side timeout is at eight hours and we shouldn't be hitting that. It seems as if the python wrapper was not enabling automatic reconnect and unfortunately the python-mysqldb version installed by hardy (1.2.2) doesn't have the ping(reconnect) method later versions have added (by looking through python-mysqldb's svn logs, that is), mysql error logs don't say anything (or I just don't find them, quite possible). My next step would be to wrap each execute() going against the database in a try/catch that clears the connection and creates a new one if an OperationalError is caught. But before I get my feet wet with another area of Python I've never used, maybe anybody knows of a better approach. BTW, after this type of error occurs we get Gump runs where bcel and many other early building mvn projects fail. This is because the mvn proxy of the previous run is still up and thinks it could serve commons-lang but the jar has already been removed by the sync operation (and thus mvn fails because it cannot download commons-lang). This needs to be fixed in a separate way, either by making sure the mvn proxy is shut down at the end or by clearing it at the start (the later is probably easier to implement). Stefan - 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: svn commit: r809220 - /gump/metadata/project/commons-proper.xml
- Original Message - From: Stefan Bodewig bode...@apache.org To: general@gump.apache.org Sent: Sunday, August 30, 2009 7:56 PM Subject: Re: svn commit: r809220 - /gump/metadata/project/commons-proper.xml On 2009-08-30, billbar...@apache.org wrote: Author: billbarker Date: Sat Aug 29 23:05:13 2009 New Revision: 809220 URL: http://svn.apache.org/viewvc?rev=809220view=rev Log: It seems that ant includes the body in property statements now Yes, is/was this causing problems? If so, we (Ant) should at least flag this under the could break older builds section for 1.8.0. Yes, the older maven-1 generated build.xml files produce output like: property name=distdir value=dist /property With the current HEAD of ant, this produces: distdir=dist\n Stefan - 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
Fwd: [g...@vmgump]: Project junit (in module junit) failed
I'm sorry: we had to switch our dependency back to hamcrest 1.1, which I'm relatively sure has caused this problem. If someone can re-point me to the 5-minute version of how to prevent this in the future, I can try harder next time. David Saff I've changed the metadata for junit to point to the hamcrest 1.1 jar. The next Gump run after the one that is currently running now should pick it up.Unless you are also an ASF committer, there is very little that can be done to prevent at least one run failing. You just have to notify this list and hope that somebody changes the metadata. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Expat for APR on vmgump
It seems that APR now assumes that expat is installed on *nix systems. I tried to do `apt-get install expat` on vmgump, but that fails :(. I've tried a couple of other combinations, but at this point I've hit my comfort level as a Linux admin (mainly use Solaris in my day job). If someone with more Linux experiance can install expat on vmgump (or in the Gump Way, set it up to build), we'll clear some 20 odd projects that depend on APR. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Commons JCI failure
Niall Pemberton niall.pember...@gmail.com wrote in message news:55afdc850901191308m49d78de1gcb985b18a3008...@mail.gmail.com... Commons JCI is currently failing[1] because of its janino dependency - which appears to be a packaged 2.3.8 version. JCI currently depends on the latest janino 2.5.10 release. Since JCI use a maven2 build - could it not download the version it requires and get rid of this packaged project (doesn't seem like anything else uses it) - or update the packaged janino to the latest version? I usually don't have a lot of spare cycles during the work week. But as I understand mvn / builds, simply removing the reference to janino from the commons metadata will do what you want. tia Niall [1] http://vmgump.apache.org/gump/public/apache-commons/commons-jci/gump_work/build_apache-commons_commons-jci.html [2] http://vmgump.apache.org/gump/public/janino/janino/index.html - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: svn commit: r735591 - /gump/metadata/project/velocity-engine.xml
The build script is overly complicated, but the relevant part is:
project name=Velocity default=world basedir=..
xmlns:artifact=urn:maven-
artifact-ant
path id=basedir-os
pathelement location=${basedir} /
/path
!-- This is the relative base dir. This must be the root of the --
!-- Velocity distribution. All relative pathes are prefixed with --
!-- velocity.dir --
pathconvert property=velocity.dir refid=basedir-os targetos=unix/
After enabling debug in Gump, I could see that Ant found the right directory
for the pathconvert, but prepended a ':' character to it. As the comments
say, this is used to build paths for the rest of the script, so none of the
resulting paths are valid. The build.xml file lives in the 'build'
directory of the project, so .. is the srcdir from Gump's point of view.
Stefan Bodewig bode...@apache.org wrote in message
news:y1uab9nq38t@v30161.1blu.de...
On 2009-01-19, billbar...@apache.org wrote:
Attempt to work around what looks like an Ant bug so this builds
Modified:
gump/metadata/project/velocity-engine.xml
What is going wrong, what do we need to fix in Ant?
Stefan
-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
Updating jdtcore.jar
We've had some build failures due to an outdated jdtcore eclipse jar (Tomcat in particular). Since for all practical purposes, this is the only eclipse jar that projects depend / on, I only replaced this jar and only on vmgump (which AFAIK is the only one I have a login to). I backed up the previous jar to jdtcore-3.1.jar in case anybody has strong objections. While the directory is now mis-named, jdtcore.jar is now at 3.4.2. I did it this way, since without access to helios and claris, I wanted a solution that didn't involve changing metadata. Of course, the true gump-way trade; would be to make eclipse a built project ;). - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: [g...@vmgump]: Project jakarta-taglibs-standard (in module jakarta-taglibs) failed
Henri Yandell flame...@gmail.com wrote in message news:31cc37360901030022r2f0f7e0dw7f06f8a6b6555...@mail.gmail.com... Repeating as I suspect the gump email got stuck in moderation. Any idea on the gump side? I'm not sure how things appear in bootclasspath and then not in classpath. There's a debug that it's decided not to include tomcat6 for the jsp21/servlet25 properties, but that doesn't seem to imply it's going to forget them all together. It's not on the bootclasspath (or on the classpath). What you are seeing is the -Dservlet25.jar=blah on the command line. If taken the liberty of commenting out the work ... / references to the produced artifacts to see if that lets gump at least build the classpath correctly. It looks like it is quitting in the middle of building it. I need to go back and see how to set up the fake MVN repository before I can actually debug the gump code. Hen On Tue, Dec 23, 2008 at 2:08 PM, Henri Yandell flame...@gmail.com wrote: [cc'ing gene...@gump.apache.org] Any ideas why this is failing? servlet-api and jsp-api appear in the bootclasspath debug, but then are absent from the CLASSPATH debug. Hen On Tue, Dec 23, 2008 at 3:20 AM, Martin Cooper mart...@apache.org wrote: 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 jakarta-taglibs-standard has an issue affecting its community integration. This issue affects 45 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-soap : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-jelly-test : Commons Jelly - htmlunit : A tool for testing web based applications - jakarta-taglibs-standard : Standard Taglib - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://vmgump.apache.org/gump/public/jakarta-taglibs/jakarta-taglibs-standard/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on jaxp exists, no need to add for property jaxp-api.jar. -DEBUG- Dependency on jaxp exists, no need to add for property sax.jar. -DEBUG- Dependency on tomcat-tc6 exists, no need to add for property jsp21.jar. -DEBUG- Dependency on tomcat-tc6 exists, no need to add for property servlet25.jar. -DEBUG- Dependency on xalan exists, no need to add for property xalan.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xercesImpl.jar. -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-taglibs/jakarta-taglibs-standard/gump_work/build_jakarta-taglibs_jakarta-taglibs-standard.html Work Name:
Re: ActiveMQ...?
Robert Burrell Donkin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] i added some activeMQ integration code into JAMES but i can't see a project descriptor for activeMQ in gump. have i just missed it? I haven't seen a commit message for this, so I doubt that it is there. if not, activeMQ is mavenised - is there a special arrangement for this...? I haven't had time to look if the M2 repository change is working yet. If it is, then you have no chance of activeMQ ever building, since it depends on a bunch of projects that don't build (actually pretty much nothing is building at the moment, since junit is broken :). In this case, activeMQ would probably need to be a packaged project, unless you don't care that Gump won't run James ;). If the repository change isn't working yet, then it's just a matter of specifing a mvn / tag for the build task. This will build activeMQ against the maven-specified versions (and so is virtually useless to the activeMQ community). But it at least lets the James community know if the activeMQ community makes an incompatible change. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r577287 - /gump/metadata/project/jamonapi.xml
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 5:43 AM To: [EMAIL PROTECTED] Subject: svn commit: r577287 - /gump/metadata/project/jamonapi.xml Author: bodewig Date: Wed Sep 19 05:42:56 2007 New Revision: 577287 URL: http://svn.apache.org/viewvc?rev=577287view=rev Log: JaMon cannot be built by Gump since having two versions of Tomcat on CLASSPATH doesn't work. Unfortunately both javac tasks are in the same target. Allow JaMON to use its own versions of Tomcat jars Which is why it can't possibly build with the newer Tomcat's. If you look in build.xml, it only uses TC 4 (effectively meaning that they don't support Tomcat). 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: AW: [EMAIL PROTECTED]: Project dotnet-antlib-test (in module ant-antlibs) failed]
Steve Loughran [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I know there's been some discussion of mono-on-gump. I think this test failure may be related. I don't know enough about NAnt to really say, I'm just the sysadmin :). Running what looks like it should be the command from src/tests/antunit/build-tasks on vmgump gives: screen-output $ NAnt.exe -buildfile:src/nant.build -D:foo=bar echo NAnt 0.85 (Build 0.85.2478.0; release; 10/14/2006) Copyright (C) 2001-2006 Gerry Shaw http://nant.sourceforge.net Buildfile: file:///srv/gump/public/workspace/ant-antlibs/dotnet/src/tests/antunit/build-tasks/src/nant.build Target framework: Mono 2.0 Profile Target(s) specified: echo echo: [echo] foo is bar BUILD SUCCEEDED Total time: 0 seconds. /screen-output You could try putting debug=true on the ant / in the gump descriptor to get a better idea what is going on. Original Message Subject: AW: [EMAIL PROTECTED]: Project dotnet-antlib-test (in module ant-antlibs) failed Date: Wed, 18 Jul 2007 11:56:56 +0200 From: [EMAIL PROTECTED] Reply-To: Ant Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] [au:antunit] Build File: /srv/gump/public/workspace/ant-antlibs/dotnet/src/tests/antunit/build-tasks/nant-test.xml [au:antunit] Tests run: 6, Failures: 0, Errors: 3, Time elapsed: 0.783 sec [au:antunit] Target: test-echo caused an ERROR [au:antunit] at line 36, column 8 [au:antunit] Message: null returned: 2 [au:antunit] took 0.061 sec [au:antunit] Target: test-nested-task caused an ERROR [au:antunit] at line 59, column 43 [au:antunit] Message: null returned: 2 [au:antunit] took 0.069 sec [au:antunit] Target: test-nested-file caused an ERROR [au:antunit] at line 45, column 14 [au:antunit] Message: null returned: 2 [au:antunit] took 0.064 sec [au:antunit] Build File: /srv/gump/public/workspace/ant-antlibs/dotnet/src/tests/antunit/dir with spaces/nant-test.xml [au:antunit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.112 sec [au:antunit] Target: test-echo caused an ERROR [au:antunit] at line 48, column 8 [au:antunit] Message: null returned: 2 [au:antunit] took 0.067 sec Jan -Ursprüngliche Nachricht- Von: Gump Integration Build [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 18. Juli 2007 10:22 An: [EMAIL PROTECTED] Betreff: [EMAIL PROTECTED]: Project dotnet-antlib-test (in module ant-antlibs) 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 dotnet-antlib-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 14 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - dotnet-antlib-test : Task and Type Libraries for Apache Ant Full details are available at: http://vmgump.apache.org/gump/public/ant-antlibs/dotnet-antlib- test/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/ant-antlibs/dotnet-antlib- test/gump_work/build_ant-antlibs_dotnet-antlib-test.html Work Name: build_ant-antlibs_dotnet-antlib-test (Type: Build) Work ended in a state of : Failed Elapsed: 14 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/ xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dant-testutil.jar=/srv/gump/public/workspace/ant/build/lib/ant -testutil.jar test [Working Directory: /srv/gump/public/workspace/ant-antlibs/dotnet] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/work space/ant-antlibs/dotnet/build/test-classes:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/sr v/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-re solver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar: /srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps .jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant-antlibs/antunit/build/ant-antunit-18072007.j ar:/srv/gump/public/workspace/ant-antlibs/dotnet/build/ant-dotnet-18072007.jar:/srv/gump/public/workspace/xml-commons/java /external/build/xml-apis-ext.jar - [au:antunit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.029 sec
Re: size of java cache dirs - .ivy is huge!
Leo Simons [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Of interest: [EMAIL PROTECTED]:/home/gump# cd ~gump [EMAIL PROTECTED]:/home/gump# du -hs .ivy 1.2G.ivy [EMAIL PROTECTED]:/home/gump# du -hs .maven 41M .maven [EMAIL PROTECTED]:/home/gump# du -hs .m2 791M.m2 While we have a bunch of different stuff in .maven and .m2, almost all of the stuff in ~gump/.ivy is smartfrog artifacts, going back months and months and months. There's no reason for gump to keep months of generated jars. I'd argue that either * there must be a way to configure ivy to do a SNAPSHOT thingie or * we must erase ~/.ivy after every run opinions? Actually, I guess we could also just erase .maven and .m2, once a week, too. I disabled the cleanup for .maven, since it nuked all of the plugins maven needs to do anything. We run maven with --offline, so it shouldn't grow too big. cheers, Leo Simons -- http://www.leosimons.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mono broken on new vmgump?
Curt Arnold [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I do not believe it is a regression,but it was also broken on the old vmgump. If you search the archives for log4net , the later entries should describe the issue. If I remember correctly mono places a nant ( lower case no extension) on the path while gump invokes Nant.exe. Either should work on windows but only nant would work on a nix. Alternatively you could place a symlink for Nant.exe on the path and link it to nant. Ok, I've done an 'apt-get install mono' and 'apt-get install nant' on the new vmgump, and have taken Curt's suggestion to create NAnt.exe - nant. On Jul 8, 2007, at 1:46 PM, Sander Temme [EMAIL PROTECTED] wrote: On Jul 8, 2007, at 7:06 AM, Leo Simons wrote: Hi all, See http://140.211.11.135/gump/public/nant/nant/gump_work/build_nant_nant.html Who knows something about mono? What's broken? Any volunteer to fix it? I see I used a package on Clarus... no I don't know anything about Mono. How did you install? S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mono broken on new vmgump?
Bill Barker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Curt Arnold [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I do not believe it is a regression,but it was also broken on the old vmgump. If you search the archives for log4net , the later entries should describe the issue. If I remember correctly mono places a nant ( lower case no extension) on the path while gump invokes Nant.exe. Either should work on windows but only nant would work on a nix. Alternatively you could place a symlink for Nant.exe on the path and link it to nant. Ok, I've done an 'apt-get install mono' and 'apt-get install nant' on the new vmgump, and have taken Curt's suggestion to create NAnt.exe - nant. Sorry, typo, it should be 'apt-get install mono-jit'. On Jul 8, 2007, at 1:46 PM, Sander Temme [EMAIL PROTECTED] wrote: On Jul 8, 2007, at 7:06 AM, Leo Simons wrote: Hi all, See http://140.211.11.135/gump/public/nant/nant/gump_work/build_nant_nant.html Who knows something about mono? What's broken? Any volunteer to fix it? I see I used a package on Clarus... no I don't know anything about Mono. How did you install? S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project lucene-java (in module lucene-java) failed
I've modified your Gump descriptor to use the downloaded version of the jar. However, this prevents you from getting warnings if that project makes imcompatible changes that would break your project. It would be better to set up that project to build under Gump, and then depend / on it in your project. Chris Hostetter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Greetings Gumpers, The Lucene-Java gump build seems to been failing consistently for the past few days. The problem seems to relate to some cleanup we did recently to our build files to help ensure that the various contrib sub projects could be cleanly built/tested on their own, or as part of hte master build. currently gump is reporting some javac errors when compiling the contrib/db/bdb subproject relating to packages and symbols which can't be found -- these are defined in the db-4.3.29.jar which is automaticly downloaded in the get-db-jar task executed just prior to compilation. This seems to work fine for develoeprs locally, as well as for our own nightly build system running on Hudson... ...If someone could take a look at the GUMP setup for Lucene-Java and either: a) fix whatever problem it is currently having or b) let us know if there is something wrong with out build process that we're not noticing becuase we are too close to the problem. ...we would greatly appreciate it. -Hoss : Date: Sun, 03 Jun 2007 03:20:44 PDT : Subject: [EMAIL PROTECTED]: Project lucene-java (in module lucene-java) 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 lucene-java has an issue affecting its community integration. : This issue affects 4 projects, : and has been outstanding for 6 runs. : The current state of this project is 'Failed', with reason 'Build Failed'. : For reference only, the following projects are affected by this: : - eyebrowse : Web-based mail archive browsing : - jakarta-lucene : Java Based Search Engine : - jakarta-slide : Content Management System based on WebDAV technology : - lucene-java : Java Based Search Engine : : : Full details are available at: : http://vmgump.apache.org/gump/public/lucene-java/lucene-java/index.html : : That said, some information snippets are provided here. : : The following annotations (debug/informational/warning/error messages) were provided: : -DEBUG- Sole output [lucene-core-03062007.jar] identifier set to project name : -DEBUG- Dependency on javacc exists, no need to add for property javacc.home. : -INFO- Failed with reason build failed : -INFO- Failed to extract fallback artifacts from Gump Repository : : : : The following work was performed: : http://vmgump.apache.org/gump/public/lucene-java/lucene-java/gump_work/build_lucene-java_lucene-java.html : Work Name: build_lucene-java_lucene-java (Type: Build) : Work ended in a state of : Failed : Elapsed: 20 secs : Command Line: /opt/jdk1.5/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=03062007 -Djavacc.home=/usr/local/gump/packages/javacc-3.1 package : [Working Directory: /usr/local/gump/public/workspace/lucene-java] : CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/lucene-java/build/classes/java:/usr/local/gump/public/workspace/lucene-java/build/classes/demo:/usr/local/gump/public/workspace/lucene-java/build/classes/test:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/packages/je-1.7.1/lib/je.jar:/usr/local/gump/public/w orkspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspa ce :
Re: [EMAIL PROTECTED]: Project logging-log4j-component (in module logging-log4j-component) failed
Curt Arnold [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hope ApacheCON EU is starting well.
I've been getting suspicious nags from logging-log4j-component. The
behavior in the following message strongly suggests that the project is
trying to compile the wrong code base. The report looks just as I would
expect if project/logging-log4j-component.xml had:
svn repository=logging dir=sandbox/juli-to-log4j-bridge/
Yes, vmgump had a copy of juli-to-log4j-bridge checked out in
the -components dir. I nuked the cvs/logging-log4j-component dir on vmgump,
so that Gump will do a full fresh checkout next run.
instead of:
svn repository=logging dir=sandbox/log4j/component/
There had been a logging-log4j-bridge.xml project descriptor (which would
have used that URL) and maybe somehow project directories got switched.
On Apr 29, 2007, at 3:49 AM, [EMAIL PROTECTED] wrote:
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 logging-log4j-component has an issue affecting its community
integration.
This issue affects 2 projects,
and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build
Failed'.
For reference only, the following projects are affected by this:
- logging-log4j-component : Back-port of log4j 1.3 component
framework for use with log4...
- logging-log4j-receivers : Back-port of log4j 1.3 receivers for
use with log4j 1.2. (E...
Full details are available at:
http://vmgump.apache.org/gump/public/logging-log4j-component/
logging-log4j-component/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
-DEBUG- Extracted fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/logging-log4j-component/
logging-log4j-component/gump_work/build_logging-log4j-
component_logging-log4j-component.html
Work Name: build_logging-log4j-component_logging-log4j-component (Type:
Build)
Work ended in a state of : Failed
Elapsed: 2 secs
Command Line: java -Djava.awt.headless=true
org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/
merge.xml -Dbuild.sysclasspath=only -Dproject.version=29042007 jar
[Working Directory: /usr/local/gump/public/workspace/logging-log4j-
component]
CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/
workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/
ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/
dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/
ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/
lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-
launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-
nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/
usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/
workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/
public/workspace/logging-log4j-12/dist/lib/log4j-29042007.jar
-
Buildfile: build.xml
init:
compile:
[mkdir] Created dir: /x1/gump/public/workspace/logging-log4j-
component/target/classes
[javac] Compiling 6 source files to /x1/gump/public/workspace/
logging-log4j-component/target/classes
[javac] /x1/gump/public/workspace/logging-log4j-component/src/
main/java/org/apache/log4j/jul/JULReceiver.java:19: package
org.apache.log4j.plugins does not exist
[javac] import org.apache.log4j.plugins.Plugin;
[javac] ^
[javac] /x1/gump/public/workspace/logging-log4j-component/src/
main/java/org/apache/log4j/jul/JULReceiver.java:20: package
org.apache.log4j.plugins does not exist
[javac] import org.apache.log4j.plugins.PluginSkeleton;
[javac] ^
[javac] /x1/gump/public/workspace/logging-log4j-component/src/
main/java/org/apache/log4j/jul/JULReceiver.java:25: cannot find symbol
[javac] symbol: class PluginSkeleton
[javac] public class JULReceiver extends PluginSkeleton implements
Plugin{
[javac] ^
[javac] /x1/gump/public/workspace/logging-log4j-component/src/
main/java/org/apache/log4j/jul/JULReceiver.java:25: cannot find symbol
[javac] symbol: class Plugin
[javac] public class JULReceiver extends PluginSkeleton implements
Plugin{
[javac]^
[javac] /x1/gump/public/workspace/logging-log4j-component/src/
main/java/org/apache/log4j/jul/JULReceiver.java:42: cannot find symbol
RE: Project ant-contrib (inmodule ant-contrib) failed
It looks like a simple versioning error: AntContrib now wants 1.4.1, but is still configured to use 1.3.1. Since it is using it's own version of ivy instead of Gump's, it is probably an easy change to make. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 12, 2007 11:27 PM To: general@gump.apache.org Subject: Project ant-contrib (inmodule ant-contrib) failed I think AntContrib does not get the right (or no) ivy.jar. But the Classpath contains a /usr/local/gump/public/workspace/ant-contrib/lib/ivy/jars/ivy -1.3.1.jar . AntContrib uses Ivy itself for its dependency management. I dont know Ivy - does the ivy-conf.xml [1] eliminate the downloading from Maven2-Repo? Another thing is using Ivy itself - it's good to use Ivy for dependency management, but Gump wants (and should) overwrite that. That's the spirit of Continuous Integration. Another idea ... Ivy has changed its package due its incubator process. Could that be the reason for the error? Jan [1] http://ant-contrib.svn.sourceforge.net/viewvc/ant-contrib/trun k/ant-cont rib/ivy-conf.xml?view=markup BUILD OUTPUT ---888888--- -8--- -8- resolve: :: resolving dependencies :: [ sourceforge | ant-contrib | [EMAIL PROTECTED] ] confs: [default, provided, test] found [ apache | bcel | 5.1 ] in default-resolver found [ apache | commons-httpclient | 3.0.1 ] in default-resolver found [ apache | commons-logging | 1.0.4 ] in default-resolver found [ jayasoft | ivy | 1.4.1 ] in default-resolver found [ apache | ant | 1.6.5 ] in default-resolver found [ apache | xercesImpl | 2.6.2 ] in default-resolver found [ junit | junit | 3.8.1 ] in default-resolver :: resolution report :: - | |modules|| artifacts | | conf | number| search|dwnlded|evicted|| number|dwnlded| - | default | 4 | 0 | 0 | 0 || 4 | 0 | | provided | 6 | 0 | 0 | 0 || 6 | 0 | | test | 5 | 0 | 0 | 0 || 5 | 0 | - classpath: compile: [mkdir] Created dir: /x1/gump/public/workspace/ant-contrib/target/classes [javac] Compiling 109 source files to /x1/gump/public/workspace/ant-contrib/target/classes [javac] /x1/gump/public/workspace/ant-contrib/src/java/net/sf/antcontr ib/net/URL ImportTask.java:33: cannot find symbol [javac] symbol : class IvyContext [javac] location: package fr.jayasoft.ivy [javac] import fr.jayasoft.ivy.IvyContext; [javac]^ GUMP MESSAGE ---888888--- -8--- -8- Project ant-contrib has an issue affecting its community integration. This issue affects 9 projects, and has been outstanding for 28 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - ant-contrib : Useful little Ant tasks - ant-contrib-test : Useful little Ant tasks - antbook-diary-core : Examples to go with Java Development with Ant - forrest-whiteboard-forrestdoc : Apache Forrest is an XML standards-oriented documentation fr... - forrest-whiteboard-forrestdoc-autotest : Apache Forrest is an XML standards-oriented documentation fr... - invicta : Open-source build management tool. - logging-log4cxx-ant : Apache log4cxx - logging-log4cxx-ant-no_wchar_t : Apache log4cxx - logging-log4cxx-ant-static : Apache log4cxx Full details are available at: http://vmgump.apache.org/gump/public/ant-contrib/ant-contrib/i ndex.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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.
Re: mina
Antoine Levy-Lambert [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, mina has become a top level project, and seems to build with maven2. Urm, you do realize that the mvn tag is only in trunk, and even there it doesn't do anything useful :(. I have adapted the metadata, someone needs to clean the SVN sandbox. Best regards, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency on commons VFS sandbox
We could install a packaged version of it. Gump can't currently build it because vfs-sandbox only supports a M2 build. Maarten Coene [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, Jakarta Commons VFS has been split in a core and sandbox part. Ivy has a dependency on the VFS sandbox part, but this doesn't seems to be available in gump. How can this be solved? Maarten __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 builds
Brett Porter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 14/11/06, Bill Barker [EMAIL PROTECTED] wrote: It's more expertise than time :). I could probably pull the time together for a custom repository or repositoryManager, but not enough to learn M2 well enough to know which I would need :(. I'm jealous :) I'll happily dedicate the time to walk you through and answer questions (hopefully prodding us to improve our API/architecture documentation on the way). I just don't have a whole lot of contiguous chunks to sit down and do the rest. Ok, then let's start with the simple stuff :). What interface(s) do I need to implement, and how would I tell M2 to use my widget instead of it's? At least this way, I can read the javadocs and get far enough along to actually know what I want to ask. With my extremely limited knowedge of M2, I can't tell if it's a repository, an artifact manager . And, I come from a project (Tomcat) that has some of the worst API documentation at the ASF ;-). - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Installing a fresh gump2 yields lots of issues
Sander Temme [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Nov 11, 2006, at 11:47 AM, Stefan Bodewig wrote: Many thanks. Stefano had already picked up the jmock change and I fixed cargo and groovy. I also removed the working copies of all projects we fixed on vmgump and helios. Just for reference, what do I need to remove if I want to get rid of a working copy? work/workspace/project-name and/or work/workspace/cvs/ project-name? You just need to kill cvs/project-name (where Gump checks out to). Gump will take care of /project-name. I may just get rid of every checkout on Clarus for the 6PM run. S. -- [EMAIL PROTECTED]http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bcel failure
Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Fri, 10 Nov 2006, Stefan Bodewig [EMAIL PROTECTED] wrote: Once Gump says it can find mvn in http://gump.zones.apache.org/gump/test/index.html So far it doesn't, I only set M2_HOME which didn't seem to be enough. I've now added $M2_HOME/bin to PATH as well, that hopefully does the trick. Yes, it's the same as for M1. It needs to be on the path as well. I just cloned what Gump was doing for M1. we can use bcel as our test project for the Maven2 support in Gump. bcel doesn't have any dependencies to speak of, so the missing pieces won't hurt too badly. What would be the correct mvn goal to invoke if we want a jatr and maybe run tests? The default goal is package. Of course, mvn will run offline, so all of the dependant jars will have to be in the local repository. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Guidance on the Pluto Portal Gump build
Elliot Metsger [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Jan.Materne wrote: Gump _could_ use a fix version of Castor. But that's more an intend of a Continous _Build_ Server, not a Continous _Integration_ Server like Gump. Thanks for the clarification Jan. If my inital email wasn't a dead giveaway, I know next to nothing about Gump. Jan.Materne wrote: Gump should show, that a project is failing because it is not compatible with the latest version of another project. I agree with your points. Indeed, Gump has demonstrated its value to Pluto on occaison. Most recently we upgraded from commons-fileupload 1.0 to 1.1 based on Gump messages. However, the failed build due to Castor is somewhat different. With commons-fileupload, we realized that upgrading to 1.1 was the best course of action. But, we probably aren't ever going to change the Pluto 1.0.2's dependency on Castor, so we are going to continue to receive the nag emails to pluto-dev indefinitly. I'm wondering if there is a way that we can silence those emails concerning Castor. Otherwise people on the list will forward the Gump messages to /dev/null (which is a bad thing of course). We can set up a packaged-castor project and change Pluto to depend / on it. If you can send the download URL for the version you want, I can set it up (probably tomorrow, unless somebody else on the list feels an itch :). Of course, you can turn off the nags at any time, but it doesn't sound like this is what you want. Thanks for your help, Elliot Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: vmgump has problems
I was going to look into this this weekend, but it seems to be working now :). I really can't believe that it's just fixing the SF repo locations. Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi all Since about two weeks we don't finish a single Gump run on vmgump - the test builds on helios manage to go through, but they build a much smaller chunk of code. It isn't always the same project that gets built last (I looked into it sometime in the middle of last week and it was checkstyle, today it was test-ant). This is the tail of out.txt: Build Project: #[(595, 705)] : test-ant : [state:Unset] Run Ant on Project: #[(595, 705)] : test-ant Failed to build project #[(595, 705)] : [test-ant], state:Failed dynagumper.py processProject: need to implement project event processing Traceback (most recent call last): File bin/integrate.py, line 113, in ? irun() File bin/integrate.py, line 90, in irun result = getRunner(run).perform() File /x1/gump/public/gump/python/gump/core/runner/runner.py, line 249, in perform return self.performRun() File /x1/gump/public/gump/python/gump/core/runner/demand.py, line 195, in performRun self.performBuild(project) File /x1/gump/public/gump/python/gump/core/runner/demand.py, line 128, in performBuild self.run.generateEvent(project) File /x1/gump/public/gump/python/gump/core/run/gumprun.py, line 202, in generateEvent self._dispatchEvent(EntityRunEvent(self, entity)) File /x1/gump/public/gump/python/gump/core/run/gumprun.py, line 185, in _dispatchEvent actor._processEvent(event) File /x1/gump/public/gump/python/gump/core/run/actor.py, line 82, in _processEvent self.processEvent(event) File /x1/gump/public/gump/python/gump/core/run/actor.py, line 124, in processEvent self._processProject(entity) File /x1/gump/public/gump/python/gump/core/run/actor.py, line 168, in _processProject self.processProject(project) File /x1/gump/public/gump/python/gump/actor/document/xdocs/documenter.py, line 86, in processProject self.documentProject(project,True) File /x1/gump/public/gump/python/gump/actor/document/xdocs/documenter.py, line 1736, in documentProject note,warn) File /x1/gump/public/gump/python/gump/actor/document/xdocs/documenter.py, line 2356, in documentWorkList self.documentWork(work) File /x1/gump/public/gump/python/gump/actor/document/xdocs/documenter.py, line 2360, in documentWork spec=self.resolver.getFileSpec(work) File /x1/gump/public/gump/python/gump/actor/document/xdocs/resolver.py, line 247, in getFileSpec self.makePath(location.getPath(),self.xdocsDir) File /x1/gump/public/gump/python/gump/actor/document/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: xalan xsltc and bcel
Pretty much, the only way is to jump in and contribute to supporting Maven 2 on Gump ;). Otherwise, if BCEL isn't going to continue to support either a Maven 1 build or an Ant build, eventualy we'll probably just do the same thing to BCEL and it's dependants as we did to Cocoon, and nuke it :). -Original Message- From: [EMAIL PROTECTED] on behalf of Torsten Curdt Sent: Wed 6/7/2006 1:31 AM To: general@gump.apache.org Subject: xalan xsltc and bcel Guys, I probably should know by now but... We just recently switched bcel trunk to maven2 and juggled a bit with the directory layout. So gump keeps failing on xalan because of the xalan - bcel dependency. Where do I fix this? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: include not working properly under Gump
-Original Message- From: sebb [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 06, 2006 10:05 AM To: Jakarta General List; Gump code and data Subject: xsl:include not working properly under Gump On 03/06/06, sebb [EMAIL PROTECTED] wrote: On 03/06/06, Stefan Bodewig [EMAIL PROTECTED] wrote: To whom it may engage... news-gen: [mkdir] Created dir: /x1/gump/public/workspace/jakarta-site2/target/news-gen [xslt] Processing /x1/gump/public/workspace/jakarta-site2/news.xml to /x1/gump/public/workspace/jakarta-site2/docs/site/rss.xml [xslt] Loading stylesheet /x1/gump/public/workspace/jakarta-site2/xdocs/stylesheets/news 2content.xsl [xslt] /x1/gump/public/workspace/jakarta-site2/news2content.xsl:28:36 : Error! Had IO Exception with stylesheet file: common.xsl Cause: java.io.FileNotFoundException: /x1/gump/public/workspace/jakarta-site2/common.xsl (No such file or directory) Something odd going on here. The loaded style-sheet is .../jakarta-site2/xdocs/stylesheets/news2content.xsl but the error message quotes: .../jakarta-site2/news2content.xsl This may explain why it is looking for .../jakarta-site2/common.xsl rather than .../jakarta-site2/xdocs/stylesheets/common.xsl I'm going to try: - deleting .../jakarta-site2/news2content.xsl just in case there is a copy there - copying common.xsl into top-level Copying common.xsl to the top-level works. But that in turn then fails, because it also uses xsl:import. That can be fixed. But then later xslt transformations fail. Etc. According to the documentation I've read, relative references in xsl:import tags should be resolved with respect to the parent document. However, when run under Gump, the references seem to be resolved relative to the current working directory, which stops the build from working. Does anyone know how to fix this? Is it perhaps a feature of the xslt processor that is used? How do I find out what is being used? Well, from the dependancy page, it would be the Gump-built xalan. Note that the build script works fine under Java 1.4 and 1.5 when run outside Gump. Sebastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: jakarta-velocity-test problem
Henning Schmiedehausen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, well, I don't exactly understand why this build fails for you guys. It definitely works for me in the same environment... Can you send me the output of the workspace/bin/test-reports/TEST-org.apache.velocity.test.AbsoluteFileResourceLoaderTestCase.txt file after the run is complete? I'd really appreciate it (and I might even get that problem fixed... :-) It looks like a compatibility problem with JUnit-4 or Ant+JUnit-4. But, anyway, here it is: Testsuite: org.apache.velocity.test.AbsoluteFileResourceLoaderTestCase Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.043 sec Testcase: warning took 0.006 sec FAILED Class org.apache.velocity.test.AbsoluteFileResourceLoaderTestCase has no public constructor TestCase(String name) or TestCase() junit.framework.AssertionFailedError: Class org.apache.velocity.test.AbsoluteFileResourceLoaderTestCase has no public constructor TestCase(String name) or TestCase() Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development Linux, Java, perl, Solaris -- Consulting, Training, Engineering Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [EMAIL PROTECTED]: Project xml-batik (in module xml-batik) failed
-Original Message- From: Cameron McCormack [mailto:[EMAIL PROTECTED] Sent: Friday, March 24, 2006 4:03 AM To: batik-dev@xmlgraphics.apache.org Cc: general@gump.apache.org Subject: Re: [EMAIL PROTECTED]: Project xml-batik (in module xml-batik) failed Hi Gumpers. I've just made some changes to Batik so that it uses a modified version of Mozilla Rhino from CVS, but because of the classpath given to the build, it fails. Is it possible to let the build use the js.jar in Batik's lib directory? You would just have to change the Gump descriptor xml-batik.xml and replace depend project=rhino / with work nested=lib/js.jar / Of course, this will mean that you won't get notified if Rhino makes an incompatible change that would break Batik :). 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: svn commit: r383419 - /gump/metadata/project/smartfrog.xml
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sun 3/5/2006 2:15 PM To: commits@gump.apache.org Subject: svn commit: r383419 - /gump/metadata/project/smartfrog.xml Author: stevel Date: Sun Mar 5 14:15:03 2006 New Revision: 383419 URL: http://svn.apache.org/viewcvs?rev=383419view=rev Log: junit are trying very hard to make people stop using them ;-) Another option would be to depend project=junit3 / for awhile, if you don't actually need all the cool new stuff in JUnit4. The junit3 project is packaged, so you don't have to worry about it failing. 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...
-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: Problem while adding a new project to gump
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 02, 2006 2:02 AM To: general@gump.apache.org Subject: Problem while adding a new project to gump I checked out the Gump repo, placed a project definition in /metadata/project and the definition of the repository access in /metadata/repository. Then I did a 'svn add' (using TortoiseSVN). But I got an error while commiting: svn commit -m Add args4j - hopefully successful. (1st of setting up the integration build by Gump) project\args4j.xml repository\args4j.xml svn: Übertragen fehlgeschlagen (Details folgen): svn: MKACTIVITY von '/repos/asf/!svn/act/6c478208-4117-3b40-bf0f-5f209237fb2c': 403 Forbidden (http://svn.apache.org) MAYBE I got the wrong URL while checkout. 'svn info' gave me Pfad: . URL: http://svn.apache.org/repos/asf/gump UUID des Projektarchivs: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 382085 Knotentyp: Verzeichnis Plan: normal Letzter Autor: billbarker Letzte genderte Rev: 381896 Letztes Žnderungsdatum: 2006-03-01 04:54:41 +0100 (Mi, 01 Mrz 2006) Questions: * Was my first attempt (adding the two files) correct? You need to add them to profile/gump.xml, but otherwise yes. * If it was the wrong url while checkout (http instead https - maybe): is there any possibility for changing without a complete new checkout? Like any other ASF repo, you need to co with https if you want to ci. * Some else wrong? Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: svn commit: r382451 - /gump/metadata/project/args4j.xml
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thu 3/2/2006 9:18 AM To: commits@gump.apache.org Subject: svn commit: r382451 - /gump/metadata/project/args4j.xml Author: jhm Date: Thu Mar 2 09:18:10 2006 New Revision: 382451 URL: http://svn.apache.org/viewcvs?rev=382451view=rev Log: Add args4j - hopefully successful. (1st of setting up the integration build by Gump) Added: gump/metadata/project/args4j.xml You are going to have to add this to profiles/gump.xml if you want Gump to pick it up. 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: Maven question: bcel
They need to be in the Maven repository for Maven to find them. If you just want to get it working, you can copy ~gump/.maven/repository over. Sander Temme [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Folks, The bcel build on my Gump is failing and taking with it close to 150 projects. See: http://clarus.apache.org/jakarta-bcel/bcel/gump_work/build_jakarta- bcel_bcel.html I'm getting: __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependencies: dom4j-1.4-dev-8.jar commons-jelly-20030902.160215.jar commons-jelly-tags-jsl-20030211.143151.jar commons-jelly-tags-log-20030211.142821.jar commons-jelly-tags-velocity-20030303.205659.jar commons-jelly-tags-xml-20040613.030723.jar (try downloading from http://jakarta.apache.org/commons/jelly/libs/xml/) commons-logging-1.0.3.jar velocity-1.4-dev.jar velocity-dvsl-0.45.jar Total time: 4 seconds Finished at: Tue Feb 21 09:19:59 PST 2006 Now, I'm no Maven expert (to put it mildly), but in my Maven install, I'm seeing: clarus:~ sctemme$ ls /usr/local/maven-install/current/lib ant-1.5.3-1.jar ant-optional-1.5.3-1.jar commons-beanutils-1.6.1.jar commons-betwixt-1.0-beta-1.20030111.103454.jar commons-cli-1.0-beta-2.jar commons-collections-2.1.jar commons-digester-1.4.1.jar commons-grant-1.0-beta-4.jar commons-graph-0.8.1.jar commons-httpclient-2.0.jar commons-io-20030203.000550.jar commons-jelly-20030902.160215.jar commons-jelly-tags-ant-1.0.jar commons-jelly-tags-define-20030211.142932.jar commons-jelly-tags-util-20030211.141939.jar commons-jelly-tags-xml-20040613.030723.jar commons-jexl-1.0-beta-1.jar commons-lang-2.0.jar commons-logging-1.0.3.jar dom4j-1.4-dev-8.jar endorsed forehead-1.0-beta-5.jar log4j-1.2.8.jar maven-jelly-tags-1.0.1.jar maven.jar plexus-0.6.jar werkz-20040426.222000.jar which-1.0.jar Most of the missing jars are represented there, so why doesn't Maven pick those up? Do I need to have them anywhere else? I have the following environment: GUMP_PYTHON=/usr/local/python-install/current/bin/python MAVEN_HOME=/usr/local/maven-install/current PATH=/usr/local/maven-install/current/bin:/usr/local/maven2-install/ current/bin:/usr/local/python-install/current/bin:/bin:/sbin:/usr/ bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/local/svn-install/ current/bin JAVA_HOME=/Library/Java/Home M2_HOME=/usr/local/maven2-install/current Que pasa? Thanks, S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: what version of the maven2 ant tasks are installed?
Steve Loughran [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'm getting a build failing because the pom task of maven2 is absent: /x1/gump/public/workspace/antbook/diary/core/core-chapter-10-maven.xml:113: Problem: failed to create task or type antlib:org.apache.maven.artifact.ant:pom Cause: The name is undefined. What version of the m2 tasks is gump running? 2.0.0? Upgrading to 2.0.2 would be handy I'm pretty certain that no version of Maven2 is installed (Gump can't do anything with it, so why install it). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: what version of the maven2 ant tasks are installed?
Steve Loughran [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bill Barker wrote: Steve Loughran [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'm getting a build failing because the pom task of maven2 is absent: /x1/gump/public/workspace/antbook/diary/core/core-chapter-10-maven.xml:113: Problem: failed to create task or type antlib:org.apache.maven.artifact.ant:pom Cause: The name is undefined. What version of the m2 tasks is gump running? 2.0.0? Upgrading to 2.0.2 would be handy I'm pretty certain that no version of Maven2 is installed (Gump can't do anything with it, so why install it). The maven2 ant tasks are there. Otherwise smartfrog-xml wouldnt be failing with the m2 tasks unable to resolve dependencies :) You're right, and from maven2-ant-tasks.xml, it v2.0-a3. I also see that antbook isn't depend /ing on it, so that might be a problem as well :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: handling svn branches
-Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: Thursday, February 23, 2006 8:10 AM To: Gump code and data Subject: handling svn branches Question: what is the way to handle SVN tags in gump? I see there is a tag attribute for repository, but the docs hint that it is for CVS -does it work for SVN too, or should we change the URL? Usually for SVN it's the URL (or, rather, the dir=... attribute to svn /). Take a look at portals-pluto and commons-httpclient-2.0-branch for examples. On the subject of SVN, Sourceforge have just opened up the floodgates to move projects off CVS and onto SVN. Once a few projects have moved, expect a flood of them with the consequence breakage of all the repository elements. Fun, fun ;-). But we've already been through this with ASF, so we at least know the drill :). -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: svn commit: r379266 - /gump/metadata/profile/gump.xml
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Mon 2/20/2006 2:50 PM To: commits@gump.apache.org Subject: svn commit: r379266 - /gump/metadata/profile/gump.xml Author: billbarker Date: Mon Feb 20 14:50:47 2006 New Revision: 379266 URL: http://svn.apache.org/viewcvs?rev=379266view=rev Log: Fix location of xmlrpc metadata Modified: gump/metadata/profile/gump.xml The file name changed (along with the svn / tag), but the module and project name didn't. For this to build, somebody is going to have to wipe the cvs/ws-xmlrpc directory, so that it can do a clean checkout. As I've said before, it doesn't help *me* to have an account on vmgump, but if anyone feels it helps *them*, I won't turn it down either. 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: Upgraded vmgump to JDK 1.5
Leo Simons [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sun, Feb 19, 2006 at 10:37:37AM +0100, Stefan Bodewig wrote: On Sat, 18 Feb 2006, Leo Simons [EMAIL PROTECTED] wrote: This is to solve the junit stuff right? JUnit is the most prominent project to require Java 5 ATM, but hardly the only one. We've had other projects breaking for months now because we didn't provide a Java 5 environment. Oh. Do you have a (partial) list (in your head or elsewhere)? Are these projects leaf projects or core projects? I believe that mina was the only one with a significant number of dependant projects (and, it still won't build since it now requires Maven2 :). JacORB, jdbm were also on the list. I think that their were about 4 or 5 others, but I don't remember them off the top of my head. I'm personally not happy with how effectively there's this one project run by a bunch of people who don't particulary understand enough about backwards compatibility I don't think you are fair here. JUnit 4 uses a completely different approach that has been enabled by annotations. I'm a happy NUnit user (.NET unit testing framework) and can tell you that using annotations really is a step forward over the JUnit 3.x approach. Right. The other big one is the template collections (whatever its called, the FooList stuff). I understand how cool and useful it is. I agree I wasn't fair, sorry. However, JUnit is one of the corest of core projects, much like Xerces and/or Ant. The ant project is an example of a project which is very aware of its role like that. Log4j is one where its lead to friction in the past but where gump in the end was used as a tool to have a net positive effect on e.g. migration strategies and backward compatibility and the like. I feel that gump is failing in that role with this jdk 1.4 - 1.5 stuff, and failing in a big way, and I find it frustrating that we're not able as a team to contribute a whole lot to easing this kind of thing and this kind of mess. Its my perception that the people working on JUnit 4 have decided to take a bite the bullet (or the sour apple) approach to this migration, and I think this is wrong, and I know there is no way I can help here or change it and I probably shouldn't try (well, of course I could go and try and change the java landscape by contributing to having open source and open style change management processes for the JDK...hey...ehm...), and I'm sorry for mentioning people instead of project and casting it as a personal thing. The big picture is just so ugly. And when it comes to backwards compatibility, it is very likely that all our JUnit 3.8 tests in Gump will work with JUnit 4 as well. It's simply that JUnit wants to use annotations and the only way forward was to require Java 5 at compile time. Yeah I know. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is Gump the obsticle?
Steve [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -Original Message- From: Steve [mailto:[EMAIL PROTECTED] Sent: Sunday, 19 February 2006 3:32 AM To: 'Gump code and data' Subject: RE: Upgraded vmgump to JDK 1.5 -Original Message- From: Leo Simons [mailto:[EMAIL PROTECTED] Sent: Sunday, 19 February 2006 2:46 AM To: Gump code and data Subject: Re: Upgraded vmgump to JDK 1.5 This is to solve the junit stuff right? Will be interesting...I'm personally not happy with how effectively there's this one project run by a bunch of people who don't particulary understand enough about backwards compatibility and the like (just like Sun really) which force this kind of thing. It's not like 'that bunch of people' are taking away 3.8.1! Products evolve and there is a well established convention concerning major version increments. The JUnit team are working of 4.X - and that means they are working on a new product that is not compatible with the 3.X line. This is a trend commonly referred to as progress. The stupidness is that this is in part a limitation that gump has. Yes - which is the relevant subject for this list. Subscribers should not be moaning about the fact that an independent project is going the next step and building an even better testing framework - instead, subscribers should be looking at why this is an issue for Gump. IMO - the issue is that Gump project descriptors do not include a definition a major version identifier and the underlying support that this implies within respect to dependent builds (i.e. group/name is not sufficient). The absence of this creates a scenario where the assumption is that incompatible version changes are not recognized as a technical reality. Actually, the reason Gump came into being is because of incompatible version changes :). What it does is let other projects know that this is happening early enough that they can plan how they want to deal with it. A fair number of times, it's to switch from project foobar to project packaged-foobar, and deal with it later. But at least it's on their radar now :). It might be a nice feature to be able to create a packaged-foobar just from the metadata, without having to get Stefen involved with downloading the jars himself. Maybe something for Gump 3. This in-turn creates an inconsistency between: (a) the role of Gump as a technical community integrity checker (b) the decisions of a particular project/group concerning product evolution My suggestion would be to consider every Gump project as an implicit version 0 and enable an explicit major version identifier. From this consumer projects would be able to lock onto the assumed major version without fear of disruption from source project major-version evolution. You can do that now: Just create a foobar-v1.xml that builds off a branch instead of HEAD, and depend on that. Cheers, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Failure in derby-split-1
-Original Message- From: Andrew McIntyre [mailto:[EMAIL PROTECTED] Sent: Friday, February 17, 2006 3:22 PM To: Gump code and data Subject: Failure in derby-split-1 Just noticed this has been failing for a while. The failure is here: compile_reference: [javac] Compiling 10 source files to /x1/gump/public/workspace/db-derby/classes [javac] /x1/gump/public/workspace/db-derby/java/engine/org/apache/derb y/iapi/reference/SQLState.java:29: package org.apache.derby.shared.common.reference does not exist [javac] org.apache.derby.shared.common.reference.SQLState [javac] ^ [javac] 1 error BUILD FAILED This looks like svn did not properly update some files. The file that is missing exists in the source tree here: http://svn.apache.org/repos/asf/db/derby/code/trunk/java/share d/org/apache/derby/shared/common/reference/ Maybe those new files didn't update properly? Perhaps the pointers to the various source directories in tools/ant/properties/dirs.properties didn't update? Maybe there's something in the metadata I need to change to find the new files? Not sure what's going on, but I'll be glad to help if someone could take a look and make sure that the new files in java/shared are there. I can't check the files myself, but it's hard to believe that 'svn up' has been failing for this long. What I'd check is if 'ant gump_split_1' works. It's likely that the missing file simply needs to be added to what that target builds. Thanks! andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED]: Project lucene-java (in module lucene-java) failed
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 16, 2006 12:09 PM
To: java-dev@lucene.apache.org
Cc: Gump code and data
Subject: Re: [EMAIL PROTECTED]: Project lucene-java (in module
lucene-java) failed
What is going wrong with the Gump Lucene build? It is
missing JUnit
- but this is something Gump itself should provide somehow,
correct?
Please reply back to java-dev@lucene.apache.org if you have some
insight into this and it is something the Lucene team can address.
JUnit now requires Java 5 to build, and so is currently failing in Gump.
I'm guessing that Lucene is only declaring an option / instead of a
depend / on JUnit, so Gump tries to build it even though JUnit failed.
Thanks,
Erik
On Feb 16, 2006, at 4:26 AM, Jason van Zyl wrote:
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 lucene-java has an issue affecting its community
integration.
This issue affects 2 projects,
and has been outstanding for 197 runs.
The current state of this project is 'Failed', with reason 'Build
Failed'.
For reference only, the following projects are affected by this:
- jakarta-lucene : Java Based Search Engine
- lucene-java : Java Based Search Engine
Full details are available at:
http://vmgump.apache.org/gump/public/lucene-java/lucene-java/
index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error
messages) were provided:
-DEBUG- Sole output [lucene-core-16022006.jar] identifier set to
project name
-DEBUG- Dependency on javacc exists, no need to add for property
javacc.home.
-INFO- Failed with reason build failed
-DEBUG- Extracted fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/lucene-java/lucene-java/
gump_work/build_lucene-java_lucene-java.html
Work Name: build_lucene-java_lucene-java (Type: Build)
Work ended in a state of : Failed
Elapsed: 20 secs
Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/
local/gump/public/workspace/xml-commons/java/external/build/xml-
apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/
xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/
public/gump/work/merge.xml -Dbuild.sysclasspath=only -
Dversion=16022006
-Djavacc.home=/usr/local/gump/packages/javacc-3.1
package
[Working Directory: /usr/local/gump/public/workspace/lucene-java]
CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/
workspace/lucene-java/build/classes/java:/usr/local/gump/public/
workspace/lucene-java/build/classes/demo:/usr/local/gump/public/
workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/
ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/
dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/
ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/
lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-
launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-
nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/
ant.jar:junit-gump-15022006.jar:/usr/local/gump/public/workspace/
xml-commons/java/build/resolver.jar:/usr/local/gump/packages/
je-1.7.1/lib/je.jar:/usr/local/gump/packages/javacc-3.1/bin/lib/
javacc.jar:/usr/local/gump/public/workspace/httpunit/jars/Tidy.jar
-
[javac] location: class
org.apache.lucene.queryParser.TestMultiFieldQueryParser
[javac] public class TestMultiFieldQueryParser extends
TestCase {
[javac]^
[javac] /x1/gump/public/workspace/lucene-java/src/test/org/
apache/lucene/queryParser/TestQueryParser.java:19: package
junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] /x1/gump/public/workspace/lucene-java/src/test/org/
apache/lucene/queryParser/TestQueryParser.java:53: cannot resolve
symbol
[javac] symbol : class TestCase
[javac] location: class
org.apache.lucene.queryParser.TestQueryParser
[javac] public class TestQueryParser extends TestCase {
[javac] ^
[javac] /x1/gump/public/workspace/lucene-java/src/test/org/
apache/lucene/search/BaseTestRangeFilter.java:21: package
junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] /x1/gump/public/workspace/lucene-java/src/test/org/
apache/lucene/search/BaseTestRangeFilter.java:29: cannot resolve
symbol
Re: Gump on MacOSX
Sander Temme [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello all, When vendors donate hardware, I think it's a nice reciprocation if we make sure that our software runs on it. In that spirit, I have set up Gump (I think) on a dual CPU Xserve; results are here: http://clarus.apache.org/. Yay, a successful run! However, where vmgump boasts 768 projects, I get 18, of which only five succeed. So far, I have: * Checked out https://svn.apache.org/repos/asf/gump/trunk/ into a local directory * Set up GUMP_HOME and JAVA_HOME in cron/local-env-clarus.sh * Copied metadata/minimal-workspace.xml to clarus.local.xml * Installed a new Python 2.4.2 in /usr/local/python-install \ /2.4.2 symlinked to current in the same directory, and prepended /usr/local/python-install/current/bin to my PATH * Run ./gump run until it stopped bitching about missing Python modules (any way to get a list of those up-front?) * Enabled the bundled MySQL 4.1.x on the box, created the database but haven't generated tables or set up access yet, so it looks like Gump is simply not using it. * Set and exported JAVA_HOME in my environment * Set and exported GUMP_PYTHON in my environment since it seemed to fall back explicitly to pyton2.3 and I installed 2.4.2. I suppose the next step would be to embellish my local-env-clarus.sh and that clarus.local.xml file I copied. What does the vmware box run with? Any suggestions on where to look/expand first? Well, if you change the profile / tag in clarus.local.xml to: profile href=profile/gump.xml / you should start to see the 768 projects. You also haven't mentioned if you've installed Maven. You'll need that (version 1.0.2 unless you don't care about high failure rates :), as well as MAVEN_HOME defined and $MAVEN_HOME/bin on the PATH. The Xserve was donated by Apple and sits in the Apache infrastructure rack, above loki.apache.org which hosts VMGump. I can give out accounts as needed. Thanks, S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help for WSRP4J
Carsten Ziegeler [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] sebb schrieb: According to http://vmgump.apache.org/gump/public/ws-wsrp4j/ws-wsrp4j/details.html it only depends on the -api project currently Gosh, you're right. I thought I added this months ago...strange. Anyway, I just added the dependency, so let's see what happens know. It seems that you need a newer version than pluto-1.0. Unfortunately, the newer version of Pluto requires Maven2 to build, and Gump isn't quite up to supporting Maven2 quite yet :(. Many thanks Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help for WSRP4J
Carsten Ziegeler [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bill Barker wrote: It seems that you need a newer version than pluto-1.0. Unfortunately, the newer version of Pluto requires Maven2 to build, and Gump isn't quite up to supporting Maven2 quite yet :(. Actually, we need pluto 1.0.1 (or 1.0.x) which is not the trunk of Pluto in svn but a branch - and not one is still using maven 1. Is there a way to specify this for wsrp4j? Now, Pluto 1.0.1 might be the last release in the 1.0 branch, so perhaps it's ok to use the 1.0.1 jar directly for building wsrp4j instead of using the latest pluto from svn? We will migrate wsrp4j to Pluto 1.1 once 1.1 is stable enough, but this might take a little bit longer. The current Gump Pluto is built from pluto/branches/pluto-1.0.2. I haven't looked into it enough to see why it isn't good enough for ws4p4j. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [EMAIL PROTECTED]: Project commons-javaflow (in module jakarta-commons-sandbox) failed
-Original Message- From: Torsten Curdt [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 4:43 PM To: Gump Subject: Re: [EMAIL PROTECTED]: Project commons-javaflow (in module jakarta-commons-sandbox) failed The build cannot continue because of the following unsatisfied dependency: maven-xdoc-plugin-1.9.2.jar (try downloading from http:// maven.apache.org/reference/plugins/xdoc) Where is the gump descriptor anyway? https://svn.apache.org/repos/asf/gump/metadata cheers -- Torsten 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: svn migrations
Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, I've migrated everything that I found (or believed to find) from CVS to svn except for jakarta-tools - needed by watchdog now in Tomcat jakarta-tools is now living at http://svn.apache.org/repos/asf/tomcat/archive/tools/trunk/. However, both it and watchdog are dead projects. I (and probably everyone else :) don't really care if they are simply nuked. ws-wsil - no idea what it is I had to apply some guesswork to some webservices and xml projects as well as Torque, I also expect problems with Taglibs (since I only picked up trunks-proper, not the sandbox). db-commons seems to be gone, so I removed it rather than adding it to the list of modules I couldn't find. Expect a drop in success rate while we figure out the aftermath of the migration. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 support
Brett Porter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Bill, I sent a lengthy proposal some time back - I don't have time to grab it right now but you might like to look at it. If you have any trouble let me know and I'll take a look. It seems that the 'maven.final.name' property doesn't work anymore for Maven2, but otherwise it seems that I can build struts-action using an mvn / tag. This is still a bit preliminary, since I also used this project to (online) get Maven2 to download it's required plugins, so I'm not sure about dependency overrides. However, since I don't think that we are running against trunk anymore (and, even if it's copied to live, it won't do anything unless a project has an mvn / tag), I'm thinking that it's time to check in for review :) I'd really hoped to have time to work on this by now, but since I was told it wasn't going to be done until gump3, I've had an excuse not to :) Yeah, so did I. But we've already lost 'myfaces', and I don't think that 'struts' is far behind. Not to mention that we are only building the legacy parts of 'pluto' becuase of this :). I'm happy to help discuss the options and code up the necessary Java components to drop into the Maven install if you are going to take care of the python side. A good start within gump would be to get a build working with a pre-installed m2 that is online - once we're that far the improvements should all be on the Maven end and I have a good handle on that. From the Maven2 docs (which are suffering from the OS syndrome of being badly incomplete :), it looks like a plugin would be very helpful. If you look in 'trunk', you'll see my stab at attempting to override the jar paths via 'profiles.xml'. Criticisms are most welcome, since I really don't have a clue what I'm doing ;-). - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven2 support
We're starting to lose projects (e.g. myfaces) due to the fact that they
only support Maven2 builds. I know that Gump3 should be able to support
this much better, but in the meantime I've been trying to work out an
interim solution for Gump2 (pretty much by trying to clone the Maven1
stuff). The problem is that the Maven2 docs seem to be orientated to
'reasonable' developers, and not to 'extreme' developers like Gump.
It seems that 'project.properties' has gone away in favor of 'project.xml'
in Maven2. Not really a problem, since writing an xml file isn't that much
different from writing a properties file in Python. What I can't find is
what is the proper top-level element for 'project.xml'. I'm guessing that
it is project, but it isn't documented. Next, is the proper property to
override still
propertynamemaven.${project}.jar/namevalue${path.to.jar}/value/property?
I can't find this as well.
Of course, I could always grab the Maven2 source and find out all of the
answers for myself. I was just hoping that somebody would feel charitable
enough to share their wisdom with me :).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: VFS gump failed
Mario Ivankovits [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Stefan Bodewig wrote: Could someone please explain why gump fails with commons-vfs? In fact, the tests should fail with errors as there is no testserver for VFS to reach, but a ClassNotFoundException is strange, isnt it? Because the test-classes directory wasn't on the CLASSPATH (Nial changed the descriptor to include it via a work directory already, should work now). New the test classes will be found, but the next exception occured due to not correctly setup environment. Is it somehow possible to disable the test stuff for gump without disabling it in build.xml? For Maven it's easy enough. I haven't looked at your build.xml file, so I don't know. If you have a conditional on the internal-test target then it just needs to be set in the Gump project. Alternatively, if the rest builds fine without JUnit, then just remove the JUnit dependancy. Thanks! Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Turbine 2 Gump has weird prereq
Eric Pugh [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi all, I have just finished untangling the circular dependency between Turbine and Fulcrum Intake. So, I expected the build to run perfectly... I just checked the Turbine page: http://vmgump.apache.org/gump/public/jakarta-turbine-2/jakarta- turbine-2/index.html and it says that it failed: This project failed due to: Project: struts-action Now, what I can't figure out is how struts-action is being included as a prereq for the Turbine build.. I check the jakarta- turbine-2.xml file, and it doesn't mention struts-action or *struts* anywhere! This one is from : struts-action - jakarta-turbine-jcs - db-torque - fulcrum-security-adapter-turbine Maybe related is the fact that the previously failing Turbine Fulcrum components now pass, except for Fulcrum Quartz: http://vmgump.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum- quartz/index.html who is failing due to the same struts-action prerequisite! This is failing because: struts-action - quartz So close to a good build, yet still not there! Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (GUMP-157) Gump builds fail on Windows when projects include maven / tags
[ http://issues.apache.org/jira/browse/GUMP-157?page=all ] Bill Barker closed GUMP-157: Resolution: Fixed This is fixed now in trunk, and AFAIK nobody is using live under Windows. Gump builds fail on Windows when projects include maven / tags Key: GUMP-157 URL: http://issues.apache.org/jira/browse/GUMP-157 Project: Gump Type: Bug Components: Python-based Gump Environment: Windows Reporter: Bill Barker Priority: Minor Attachments: maven.diff Currently, any Gump project with a maven / tag fails when running on a Windows platform. The underlying reason is that Maven (or at least v1.0.2) is too brain-dead to parse 'project.properties' other than by using j.u.Properties. As a result, the standard Windows File.separator of \ is considered to be a quote character, and is dropped from the jarpath of the dependancies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r349170 - /gump/metadata/project/jakarta-jmeter-21.xml
- Original Message - From: [EMAIL PROTECTED] To: commits@gump.apache.org Sent: Saturday, November 26, 2005 6:21 PM Subject: svn commit: r349170 - /gump/metadata/project/jakarta-jmeter-21.xml Author: sebb Date: Sat Nov 26 18:21:24 2005 New Revision: 349170 URL: http://svn.apache.org/viewcvs?rev=349170view=rev Log: Try adding home to fix work ... I think that your biggest problem is that you have your mkdir / tags under your ant/ant tag (where they will be ignored :). According to http://gump.apache.org/metadata/project.html, you need to move them to be under your project/project tag. 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]
[jira] Commented: (GUMP-157) Gump builds fail on Windows when projects include maven / tags
[ http://issues.apache.org/jira/browse/GUMP-157?page=comments#action_12358590 ] Bill Barker commented on GUMP-157: -- It seems that I'm not permitted to change the status of this. I consider the status closed, since it is now fixed in trunk (so I can use it :), and nobody uses live on a Windows machine that I know of. Longer term, the Jira adminstrator should probably let Jira know that I'm on the PMC at some point, so should be allowed to play with bug's status ;-). Gump builds fail on Windows when projects include maven / tags Key: GUMP-157 URL: http://issues.apache.org/jira/browse/GUMP-157 Project: Gump Type: Bug Components: Python-based Gump Environment: Windows Reporter: Bill Barker Priority: Minor Attachments: maven.diff Currently, any Gump project with a maven / tag fails when running on a Windows platform. The underlying reason is that Maven (or at least v1.0.2) is too brain-dead to parse 'project.properties' other than by using j.u.Properties. As a result, the standard Windows File.separator of \ is considered to be a quote character, and is dropped from the jarpath of the dependancies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: apr-iconv-make failure
Martin van den Bemt [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Bill, vmgump:~# gcc --version gcc (GCC) 4.0.3 20051023 (prerelease) (Debian 4.0.2-3) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Thanks much. Just in case a whereis : vmgump:~# whereis gcc gcc: /usr/bin/gcc /usr/lib/gcc /usr/share/man/man1/gcc.1.gz Is it usefull for you to have an account on vmgump ? I'm not so sure how useful it is for me, but it might be useful for other people ;-). Mvgr, Martin Bill Barker wrote: This is actually the same as the apr-util-make failure. I want to file a bug report with apr-iconv for this, but since it seems to be related to the version of gcc I was wondering what version of gcc is on vmgump? The reason to suspect gcc is that these used to build, and the files in apr-iconv haven't changed in ages. - 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]
apr-iconv-make failure
This is actually the same as the apr-util-make failure. I want to file a bug report with apr-iconv for this, but since it seems to be related to the version of gcc I was wondering what version of gcc is on vmgump? The reason to suspect gcc is that these used to build, and the files in apr-iconv haven't changed in ages. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2
Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Wed, 16 Nov 2005, Leo Simons [EMAIL PROTECTED] wrote: -- support for maven2 in gump2 -- I'm not going to work on it I'd offer to do a monkey-see-monkey-do support if it is not too different from maven 1 support. In general I agree that gump3 is the way to go and that we should do it properly. It depends on how quickly we are going to need it. As soon as projects in our tree switch to Maven2 exclusively, we will at least need that quick-hack version. I believe that both the Maven1 and Maven2 scripts use $MAVEN_HOME, which is the biggest problem with just creating a mvn/ tag for Gump2. There are also problems with separating the local Maven repository between Gump1 and Gump2. As much as I hate to admit it, having a mvn/ tag in Gump2 looks like it will be a lot of work :(. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r330729 - /gump/metadata/project/struts.xml
Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sat, 5 Nov 2005, Bill Barker [EMAIL PROTECTED] wrote: Bill Barker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'm not sure, but I guess that some change in xdoclet now requires a newer version of dom4j than the one shipping with Maven. Yup. This is the problem. Just your garden variety NoClassDefFoundError. The version of dom4j that Maven 1.0.2 uses is quite old - some prerelase of 1.4. Maybe we could upgrade to Maven 1.1? I just tried with Maven 1.1b2, and Maven chokes on the Excalibur project.xml long before getting to Struts. It looks like there isn't enough backwards compatibility in Maven to make it possible to upgrade the version that Gump is using. And I can't seem to find a way around it. Not without help from the POM writers, they'd need to depend on dom4j explicitly. At this point, I'm just going to have to say that struts-taglib will never build ever again unless the struts-taglib developers want to get involved in Gump to fix it :(. We should probably add a packaged version of it, then. That way we don't harm upstream projects. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r330729 - /gump/metadata/project/struts.xml
Bill Barker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Fri, 04 Nov 2005, [EMAIL PROTECTED] wrote: Reverting the last few commits, since they don't help Modified: gump/metadata/project/struts.xml URL: http://svn.apache.org/viewcvs/gump/metadata/project/struts.xml?rev=330729r1=330728r2=330729view=diff depend project=commons-validator / -depend project=commons-jelly-tags-ant / -depend project=commons-jelly / -depend project=commons-jexl / -depend project=commons-collections / -depend project=dom4j / -depend project=packaged-jaxen / depend project=httpunit / -option project=jakarta-cactus-framework-12 / -option project=jakarta-cactus-integration-ant-12/ depend project=jakarta-oro / Bill, the problem is that even if the build needed those projects, Maven will ignore them unless the project descriptor mentions those dependencies as well. I'm not sure, but I guess that some change in xdoclet now requires a newer version of dom4j than the one shipping with Maven. Yup. This is the problem. Just your garden variety NoClassDefFoundError. And I can't seem to find a way around it. Just one more reason why I'll never allow Maven on any project I'm in charge of ;-). I even tried making maven-xdoclet-plugin a built project (truely hideous :), and it didn't change a thing. At this point, I'm just going to have to say that struts-taglib will never build ever again unless the struts-taglib developers want to get involved in Gump to fix it :(. This implies the Maven build of struts-taglibs actually works at all, I never tried it. It works with the older xdoclet fine. I haven't had a chance to try with xdoclet-HEAD yet. It shouldn't be too hard to patch Gump so that maven / works on Windows. Maybe even get verbose=true and debug=true to work as well. Then I can play with this locally and see if I can isolate what the problem is. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r330729 - /gump/metadata/project/struts.xml
Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Fri, 04 Nov 2005, [EMAIL PROTECTED] wrote: Reverting the last few commits, since they don't help Modified: gump/metadata/project/struts.xml URL: http://svn.apache.org/viewcvs/gump/metadata/project/struts.xml?rev=330729r1=330728r2=330729view=diff depend project=commons-validator / -depend project=commons-jelly-tags-ant / -depend project=commons-jelly / -depend project=commons-jexl / -depend project=commons-collections / -depend project=dom4j / -depend project=packaged-jaxen / depend project=httpunit / -option project=jakarta-cactus-framework-12 / -option project=jakarta-cactus-integration-ant-12/ depend project=jakarta-oro / Bill, the problem is that even if the build needed those projects, Maven will ignore them unless the project descriptor mentions those dependencies as well. I'm not sure, but I guess that some change in xdoclet now requires a newer version of dom4j than the one shipping with Maven. This implies the Maven build of struts-taglibs actually works at all, I never tried it. It works with the older xdoclet fine. I haven't had a chance to try with xdoclet-HEAD yet. It shouldn't be too hard to patch Gump so that maven / works on Windows. Maybe even get verbose=true and debug=true to work as well. Then I can play with this locally and see if I can isolate what the problem is. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (GUMP-157) Gump builds fail on Windows when projects include maven / tags
Gump builds fail on Windows when projects include maven / tags Key: GUMP-157 URL: http://issues.apache.org/jira/browse/GUMP-157 Project: Gump Type: Bug Components: Python-based Gump Environment: Windows Reporter: Bill Barker Priority: Minor Currently, any Gump project with a maven / tag fails when running on a Windows platform. The underlying reason is that Maven (or at least v1.0.2) is too brain-dead to parse 'project.properties' other than by using j.u.Properties. As a result, the standard Windows File.separator of \ is considered to be a quote character, and is dropped from the jarpath of the dependancies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (GUMP-157) Gump builds fail on Windows when projects include maven / tags
[ http://issues.apache.org/jira/browse/GUMP-157?page=all ] Bill Barker updated GUMP-157: - Attachment: maven.diff Patch to maven.py to fix the issue. Tomcat has run into problems with replacements as broad as this, but I can't see that it's really an issue for Gump. Gump builds fail on Windows when projects include maven / tags Key: GUMP-157 URL: http://issues.apache.org/jira/browse/GUMP-157 Project: Gump Type: Bug Components: Python-based Gump Environment: Windows Reporter: Bill Barker Priority: Minor Attachments: maven.diff Currently, any Gump project with a maven / tag fails when running on a Windows platform. The underlying reason is that Maven (or at least v1.0.2) is too brain-dead to parse 'project.properties' other than by using j.u.Properties. As a result, the standard Windows File.separator of \ is considered to be a quote character, and is dropped from the jarpath of the dependancies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
werken.xpath failure
It looks like this one is going to have to become a packaged-project (using http://www.ibiblio.org/maven/werken-xpath/jars/werken-xpath-0.9.4.jar). Assuming that vmgump can connect to ibiblio, the alternative would be to add something like: ant basedir=build buildfile=download.xml target=werken-xpath-download property name=jar.werken-xpath.version value=0.9.4 / property name=build.lib value=build/lib / property name=repo.url value=http://www.ibiblio.org/maven; / /ant to jakarta-velocity.xml (as well as changing the jar name :). But running ant to do nothing but a get / just seems like a waste of Gump's time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with configure tag in a project
Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sat, 15 Oct 2005, Bill Barker [EMAIL PROTECTED] wrote: As stated in http://gump.apache.org/metadata/builder.html#property%2Farg, you can't mix 'reference=' and 'path=' in an arg/ tag. You have to use one or the other. Yes, this probably is the problem - sorry I didn't spot this earlier. Our configure/make combo isn't tested that well. It seems to work reasonably for httpd's needs but our whole notion of dependencies and build artifacts is pretty much Java centric - wittness Bill's abuse of jar in the httpd/tomcat-connector situation. Abuse or not, it's working great now :). No longer is j-t-c dependent on how httpd wants to setup it's paths. In any case, I understand that Gump-3 will abstract this sort of thing properly. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cactus Failures
Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sun, 16 Oct 2005, Bill Barker [EMAIL PROTECTED] wrote: Sorry, htmlunit depends on jaxen (http://htmlunit.sourceforge.net/dependencies.html), so it will never build. Use packaged-jaxen, if needed. If htmlunit builds properly, I'd prefer to not use a packaged version. It's a little late for me to attack it now (PST). I'll give it a shot tomorrow with packaged-jaxen and see how it goes. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cactus Failures
It's actually looking like the jakarta-tomcat-5 project may be getting close to building once again :). At the moment, it's being held up by Cactus depending on htmlunit (http://htmlunit.sourceforge.net/). It's an ASF-style license, so I'm not sure if the best move is to include it as a packaged-library, or as a built project. Of course the advantage of a built project is that I can set it up all by myself. As a packaged-library, somebody with access to vmgump needs to be involved. Disadvantage of a built project is that nobody involved with that project seems to be currently involved with Gump, so it is harder to fix build failures. Opinions? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cactus Failures
Bill Barker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] It's actually looking like the jakarta-tomcat-5 project may be getting close to building once again :). At the moment, it's being held up by Cactus depending on htmlunit (http://htmlunit.sourceforge.net/). It's an ASF-style license, so I'm not sure if the best move is to include it as a packaged-library, or as a built project. Of course the advantage of a built project is that I can set it up all by myself. As a packaged-library, somebody with access to vmgump needs to be involved. Disadvantage of a built project is that nobody involved with that project seems to be currently involved with Gump, so it is harder to fix build failures. Opinions? Sorry, htmlunit depends on jaxen (http://htmlunit.sourceforge.net/dependencies.html), so it will never build. I'm not a big fan of packaged-libraries that can never be updated, so my (non-binding) vote is to continue to allow Cactus to fail until the Cactus group cares enough to fix it. Apologies for the spam :(. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with configure tag in a project
Graham Leggett [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi all, I am still having hassles with C/C++ projects and dependencies. I have a project that depends on other projects, and is configured like this: project name=hoops-feed-configure configure arg name=--prefix path=dest-@@DATE@@/ arg name=--with-hoops project=hoops-make-install reference=home path=dest-@@DATE@@/ arg name=--with-monacoxml project=monaco-xml-make-install reference=home path=dest-@@DATE@@/ /configure depend project=hoops-make-install/ depend project=monaco-xml-make-install/ license name=LICENSE.txt / /project As stated in http://gump.apache.org/metadata/builder.html#property%2Farg, you can't mix 'reference=' and 'path=' in an arg/ tag. You have to use one or the other. The usual way to set this up would be to define home nested=dest-@@DATE@@ / (see http://gump.apache.org/metadata/project.html#home) in the hoops-make-install project, and just reference=home in hoops-feed-configure. This frees hoops-feed-configure from knowing about how hoops-make-install is setup. Of course, I don't know how this affects the rest of your setup :). The resultant configure line from the above looks like this: configure --with-hoops=/udd001/hoops/gump/work/hoops --with-monacoxml=/udd001/hoops/gump/work/monaco-xml --prefix=/udd001/hoops/gump/work/hoops-feed/dest-13102005 The key difference is the missing path in --with-hoops and --with-monacoxml. In both cases, it picks the project source ddirectory up correctly, but as the path of dest-@@DATE@@ is ignored, the library is being searched for in the wrong place, and ./configure fails. Is there a different way I should configure the project tag? Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Final Tomcat SVN migration
Tomcat is now completely on SVN, so I should be able to stop bothering people about this :). The metadata for the move has been committed, and I need somebody to nuke the working directories on vmgump for the modules: jakarta-tomcat-jasper_tc5 jakarta-tomcat-jasper_tc4 jakarta-tomcat-connectors jakarta-tomcat-catalina jakarta-tomcat-5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (GUMP-155) Gump complains that the HiveMind build failed, when it does not
[ http://issues.apache.org/jira/browse/GUMP-155?page=comments#action_12331008 ] Bill Barker commented on GUMP-155: -- If you click on the link in the email, follow the red Failure link, and scroll down, you will see an error like: Testcase: testMockForClass(org.apache.hivemind.test.TestMockClass): Caused an ERROR [junit] org/objectweb/asm/CodeVisitor [junit] java.lang.NoClassDefFoundError: org/objectweb/asm/CodeVisitor .. Gump complains that the HiveMind build failed, when it does not --- Key: GUMP-155 URL: http://issues.apache.org/jira/browse/GUMP-155 Project: Gump Type: Bug Reporter: Howard M. Lewis Ship I get emails from Gump all the time that claim there's an error, but there's no indication of what the error is (notice that all the tests passed): 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 jakarta-hivemind has an issue affecting its community integration. This issue affects 3 projects, and has been outstanding for 61 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-hivemind : HiveMind is a services and configuration microkernel - jakarta-hivemind-library : HiveMind is a services and configuration microkernel - jakarta-tapestry : Component-based web application framework organized around i... Full details are available at: http://vmgump.apache.org/gump/public/jakarta-hivemind/jakarta-hivemind/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [hivemind-28092005.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://vmgump.apache.org/gump/public/jakarta-hivemind/jakarta-hivemind/gump_work/build_jakarta-hivemind_jakarta-hivemind.html Work Name: build_jakarta-hivemind_jakarta-hivemind (Type: Build) Work ended in a state of : Failed Elapsed: 42 secs Command Line: java -Djava.awt.headless=true -Dant.build.clonevm=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Djava.classes.dir=target/classes -Djunit-available=true -Djavacc.home=/usr/local/gump/packages/javacc-3.1 -Ddownload-warning-marker-displayed=true -Dtest.classes.dir=target/test-classes -Dproject.version=28092005 [Working Directory: /usr/local/gump/public/workspace/jakarta-hivemind/framework] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-hivemind/hivebuild/target/classes:/usr/local/gump/public/workspace/jakarta-hivemind/framework/target/classes:/usr/local/gump/public/workspace/jakarta-hivemind/framework/target/test-classes:/usr/local/gump/public/workspace/jakarta-hivemind/framework/src/descriptor:/usr/local/gump/public/workspace/jakarta-hivemind/framework/src/test:/usr/local/gump/public/workspace/jakarta-hivemind/framework/src/test-data:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-28092005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-28092005.jar:/usr/local/gump/packages/easymock1.2_Java1.3/easymock.jar:/usr/local/gump/packages/easymockclassextension1.2/easymockclassextension.jar:/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-28092005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/packages/javacc-3.1/bin/lib/javacc.jar:/usr/local/gump/public/workspace/javassist/javassist.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/logging-log4j/log4j-28092005.jar:/usr/local/gump/public/workspace/asm/output/dist/lib/asm-analysis-28092005.jar:/usr/local/gump/public/workspace/asm/output/dist/lib/asm-attrs-28092005.jar:/usr/local/gump/public/workspace/asm/output/dist/lib/asm-util-28092005.jar:/usr/local/gump/public
