Time for xpp to go to packaged project

[Bill Barker]

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

[Bill Barker]

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

[Bill Barker]

This should be in the next Gump run on vmgump that will start at about 12am 
GMT. This should fix the older Tomcat projects that want to copy jars from 
other projects with glob names in the target project.


I could try and fix other Builders, but except for Ant, they don't generally 
set properties on individual jar/output files that are globbed.


-Original Message- 
From: Stefan Bodewig

Sent: Wednesday, April 18, 2012 12:30 AM
To: general@gump.apache.org
Subject: Re: Resolving reference to commons-io-*[0-9T].jar file in a 
property


On 2012-04-18, Bill Barker wrote:


I forgot some of my python coding basics, but can recheckin the fix to
trunk, even if I haven't fully tested it


+1

adam and gump.zones are running on trunk.

I have seen your commits but also saw you reverted everything and feared
you had given up.  Thanks!


(setting up packaged projects is a PIB).


Have you tried the "testbed" workspace?  Also, all packages are
available in the Gump PMC area of the private repo.

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: Resolving reference to commons-io-*[0-9T].jar file in a property

[Bill Barker]

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
[[[
 
   
 
]]]

In Gump this is configured in project/jakarta-tomcat-catalina.xml as



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:

 

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

Re: Resolving reference to commons-io-*[0-9T].jar file in a property

[Bill Barker]

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
[[[
 
   
 
]]]

In Gump this is configured in project/jakarta-tomcat-catalina.xml as



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:

 

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: xml-commons RIP

[Bill Barker]

-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 :
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  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=revision&revision=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:




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  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 :

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  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

xml-commons RIP

[Bill Barker]

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  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

Some help with maven

[Bill Barker]

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 
 
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

[Bill Barker]

-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

[Bill Barker]

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=1303274&view=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=1303274&r1=1303273&r2=1303274&view=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.
-->

-
+
  Google Guava
  http://code.google.com/p/guava-libraries/

  http://code.google.com/p/guava-libraries/source/browse/trunk

-  http://guava-libraries.googlecode.com/svn/trunk/
+  https://code.google.com/p/guava-libraries/

  



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: xml-apis fails

[Bill Barker]

--
From: "Stefan Bodewig" 
Sent: Wednesday, December 08, 2010 9:33 PM
To: 
Subject: Re: xml-apis fails


On 2010-12-09, Ludmila Shikhvarg wrote:


Use windows 7 with cygwin environment to run gump,


I don't think anybody has ever tried to run Gump on Windows and I'm very
sure there are a few unixisms inside the code.  It's probably fair to
assume it simply won't work and Gump requires a Unix-like system with
Unix conventions for paths and filenames.  In particular java must use
Unix like conventions.



I've run Gump on Windows before, but not recently.  It would run just fine 
for Java builds.  But I wasn't using cygwin, so can't help much here.  I 
just used the gump.bat script.



 Command Line



c:/jdk1.6.0_21/bin/java
   
-Xbootclasspath/p:/home/dtftest/gump/packages/jaxp-1_3/jaxp-api.jar:/home/dtftest/gump/packages/jaxp-1_3/dom.jar:/home/dtftest/gump/packages/jaxp-1_3/sax.jar:/home/dtftest/gump/packages/jaxp-1_3/xercesImpl.jar:/home/dtftest/gump/packages/jaxp-1_3/xalan.jar
   org.apache.tools.ant.Main -Dgump.merge=/home/dtftest/gump/work/merge.xml


The bootclasspath is not a Windows path, this likely won't work at all.

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: ant-vss/trunk doesn't exist

[Bill Barker]

--
From: "Ludmila Shikhvarg" 
Sent: Wednesday, November 10, 2010 12:56 PM
To: 
Subject: ant-vss/trunk doesn't exist


Failed to run ant-antlibs projects below due to:
svn: URL 'http://svn.apache.org/repos/asf/ant/antlibs/ant-vss/trunk' 
doesn't exist


svn-antlib
antunit-test
dotnet-antlib-test
props-antlib-test
svn-antlib-test
vss-antlib
antunit
dotnet-antlib
compress-antlib-test
compress-antlib
props-antlib


Any suggestion to fix the problem on my site?



It's probably a change in the Ant svn layout.  Usually the fix for this is 
to nuke the cvs/ant-antlib directory on your system so that Gump will do a 
clean checkout on the next run.



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: compatibility issue

[Bill Barker]

--
From: "Ludmila Shikhvarg" 
Sent: Monday, November 08, 2010 5:47 PM
To: 
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

[Bill Barker]

--
From: "sebb" 
Sent: Sunday, September 12, 2010 5:00 AM
To: 
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: [GUMP@vmgump]: Project dist-xerces (in module xml-xerces2) failed

[Bill Barker]

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" 
Sent: Saturday, August 14, 2010 8:25 AM
To: 
Cc: 
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  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 sheet "sbk:/style/
stylesheets/any2project.xsl"

Re: expat-configure problem

[Bill Barker]

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" 
Sent: Thursday, August 12, 2010 7:19 PM
To: "Gump code and data" 
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" 
Sent: Tuesday, August 10, 2010 12:43 AM
To: "Gump code and data" 
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" 
Sent: Monday, August 09, 2010 8:14 AM
To: 
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

[Bill Barker]

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" 
Sent: Tuesday, August 10, 2010 12:43 AM
To: "Gump code and data" 
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" 
Sent: Monday, August 09, 2010 8:14 AM
To: 
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

[Bill Barker]

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" 
Sent: Monday, August 09, 2010 8:14 AM
To: 
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
?

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

[Bill Barker]

--
From: 
Sent: Friday, June 11, 2010 10:18 PM
To: 
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=953937&view=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

[Bill Barker]

--
From: 
Sent: Wednesday, May 05, 2010 12:05 AM
To: 
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=941172&view=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=941172&r1=941171&r2=941172&view=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 @@

  
-  
+  


-
+
  

  
@@ -41,8 +41,8 @@
  
  
-  
+  
  


Modified: gump/metadata/project/logging-log4cxx.xml
URL: 
http://svn.apache.org/viewvc/gump/metadata/project/logging-log4cxx.xml?rev=941172&r1=941171&r2=941172&view=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 @@
  
  
-  
+  
  


@@ -42,7 +42,7 @@



-
+


@@ -55,8 +55,8 @@
  
  
-  
+  
  


@@ -66,7 +66,7 @@



-
+


@@ -79,8 +79,8 @@
  
  
-  
+  
  
  

@@ -91,7 +91,7 @@



-
+


@@ -106,11 +106,11 @@

  
  
-  reference="home"/>
+  




-
+

  





-
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

[Bill Barker]

--
From: "Stefan Bodewig" 
Sent: Friday, March 19, 2010 6:39 AM
To: 
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml


On 2010-03-19, Antoine Levy Lambert  wrote:


On 2010-03-16, Bill Barker  wrote:



I was thinking of adding a localRepository="name" to the 
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

[Bill Barker]

--
From: "Stefan Bodewig" 
Sent: Monday, March 15, 2010 8:01 AM
To: 
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml


On 2010-03-15, Bill Barker  wrote:


--
From: "Stefan Bodewig" 
Sent: Sunday, March 14, 2010 10:20 PM
To: 
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml



On 2010-03-13, Bill Barker  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  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

[Bill Barker]

--
From: "Stefan Bodewig" 
Sent: Sunday, March 14, 2010 10:20 PM
To: 
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml


On 2010-03-13, Bill Barker  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

[Bill Barker]

--
From: "Stefan Bodewig" 
Sent: Thursday, March 11, 2010 5:38 AM
To: 
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml


On 2010-03-11, Bill Barker  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

[Bill Barker]

--
From: "Stefan Bodewig" 
Sent: Wednesday, March 10, 2010 12:27 AM
To: 
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  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  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 -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" 
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

[Bill Barker]

--
From: "Stefan Bodewig" 
Sent: Tuesday, March 09, 2010 12:53 AM
To: 
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml


On 2010-03-09, Bill Barker  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: svn commit: r920715 - /gump/metadata/project/excalibur.xml

[Bill Barker]

Don't think this is going to help.  It's complaining about the installed 
POM, not the artifact from the mvnrepo proxy.


--
From: 
Sent: Monday, March 08, 2010 10:58 PM
To: 
Subject: svn commit: r920715 - /gump/metadata/project/excalibur.xml


Author: bodewig
Date: Tue Mar  9 06:58:35 2010
New Revision: 920715

URL: http://svn.apache.org/viewvc?rev=920715&view=rev
Log:
Maven 2.2 has become more picky about plugin versions or so it seems. 
Stop publishing the fortress plugin.


Modified:
   gump/metadata/project/excalibur.xml

Modified: gump/metadata/project/excalibur.xml
URL: 
http://svn.apache.org/viewvc/gump/metadata/project/excalibur.xml?rev=920715&r1=920714&r2=920715&view=diff

==
--- gump/metadata/project/excalibur.xml (original)
+++ gump/metadata/project/excalibur.xml Tue Mar  9 06:58:35 2010
@@ -863,7 +863,7 @@



-
+







-
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

[Bill Barker]

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" 
Sent: Monday, February 22, 2010 10:56 PM
To: "Gump code and data" 
Subject: Re: Advise wanted on build issues




--
From: "Stefan Bodewig" 
Sent: Monday, February 22, 2010 9:22 PM
To: 
Subject: Re: Advise wanted on build issues


On 2010-02-21, Bill Barker  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 s
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

[Bill Barker]

--
From: "Stefan Bodewig" 
Sent: Monday, February 22, 2010 9:22 PM
To: 
Subject: Re: Advise wanted on build issues


On 2010-02-21, Bill Barker  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 s
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

Advise wanted on build issues

[Bill Barker]

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 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").  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.


The castor-reactor build wants Maven 2.1, which is probably a good idea to 
be running on Gump.  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.  However, I'm 
not holding out hope that this will fix castor.


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.





-
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

[Bill Barker]

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" 

To: 
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=revision&revision=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,   wrote:

Author: billbarker
Date: Sun Dec 6 00:47:23 2009
New Revision: 887621

URL: http://svn.apache.org/viewvc?rev=887621&view=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=887621&r1=887620&r2=887621&view=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 @@
org.apache.commons.jexl
Commons Jexl 1.x

- id="commons-jexl-1.1"/>

+ 








-
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

[Bill Barker]

- Original Message - 
From: "Niall Pemberton" 

To: 
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=revision&revision=886220

Any idea why?



If in the jexl 1.1 metadata you do:
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

[Bill Barker]

- Original Message - 
From: "Stefan Bodewig" 

To: 
Sent: Sunday, September 20, 2009 9:06 PM
Subject: Re: svn commit: r817123 - /gump/metadata/project/tomcat-tc6.xml



On 2009-09-21,  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?

[Bill Barker]

- Original Message - 
From: "sebb" 

To: 
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 .

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  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 /> 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]

[Bill Barker]

-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  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]

[Bill Barker]

- Original Message - 
From: "Bill Barker" 

To: "Gump code and data" 
Sent: Tuesday, September 08, 2009 7:11 PM
Subject: Re: Problem running Apache Gump [vmgump-public]




- Original Message - 
From: "Stefan Bodewig" 

To: 
Sent: Tuesday, September 08, 2009 2:00 AM
Subject: Re: Problem running Apache Gump [vmgump-public]



On 2009-09-08,  wrote:


Failed to build project #[(704, 704)] : [test-ant], state:Failed
SQL Warning::(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]

[Bill Barker]

- Original Message - 
From: "Stefan Bodewig" 

To: 
Sent: Tuesday, September 08, 2009 2:00 AM
Subject: Re: Problem running Apache Gump [vmgump-public]



On 2009-09-08,  wrote:


Failed to build project #[(704, 704)] : [test-ant], state:Failed
SQL Warning::(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.

 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

[Bill Barker]

- Original Message - 
From: "Stefan Bodewig" 

To: 
Sent: Sunday, August 30, 2009 7:56 PM
Subject: Re: svn commit: r809220 - /gump/metadata/project/commons-proper.xml



On 2009-08-30,  wrote:


Author: billbarker
Date: Sat Aug 29 23:05:13 2009
New Revision: 809220



URL: http://svn.apache.org/viewvc?rev=809220&view=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:



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: [GUMP@vmgump]: Project junit (in module junit) failed

[Bill Barker]

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

[Bill Barker]

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

[Bill Barker]

"Niall Pemberton"  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  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

[Bill Barker]

The build script is overly complicated, but the relevant part is:



  

  
  
  
  
  

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"  wrote in message 
news:y1uab9nq38t@v30161.1blu.de...
> On 2009-01-19,  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

[Bill Barker]

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  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 ™ 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

[Bill Barker]

"Henri Yandell"  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  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  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  
>> 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 fro

Re: ActiveMQ...?

[Bill Barker]

"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  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

[Bill Barker]

 

> -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=577287&view=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: svn commit: r563052 - /gump/metadata/project/ws-wsif.xml

[Bill Barker]

"Stefan Bodewig" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On Mon, 06 Aug 2007, <[EMAIL PROTECTED]> wrote:
>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=563052
>> Log:
>> Fix URL to be in archive.  Does that make sense at all?
>>
>> Modified:
>> gump/metadata/project/ws-wsif.xml
>
> The ws-wsif project in Gump builds exactly the same classes as the
> ws-soap project but doesn't publish a jar at all.
>
> This just doesn't seem right - or if it is correct then the project
> could be removed from Gump because it is redundant.
>

+1 to remove it.  Of the few non-building projects, is looks like several 
are dead.  Hopefully Jetty will build some day, but it is an M2 project, so 
not much that we can do on the Gump side.  Ditto Jline.  The nlog4j project 
just seems abandoned (since it won't even come close to compile with the 
re-structured slf4j).  The asn1-codec project would be have to changed to be 
an M2 project, but since the projects it is blocking are also M2, there 
isn't much point.  Village is waiting on finding a home again. 
Hivemind-compile might be worth making an M2, but it only has a few 
dependants.  I've been trying to clean up ws-commons, but so far with little 
success.

On the plus side, I tried checking out Maven 2.1 over the weekend.  It 
wouldn't even come close to building, but the structure looks a lot more 
Gump-friendly.  There may be hope to support M2 builds yet :).

> Stefan 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant-contrib seems to be building with stale snapshot

[Bill Barker]

I've wiped the checkout for ant-contrib on vmgump, so Gump will have to do a 
fresh co on the next cycle.  There was a problem that the ~gump/.ivy 
directory wasn't owned by 'gump', which was causing ivy failures.

"Stefan Bodewig" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On Thu, 2 Aug 2007, Curt Arnold <[EMAIL PROTECTED]> wrote:
>
>> The output for ant-contrib's Gump doesn't seem consistent with the
>> current build.xml file.
>
> Seems to be OK now.
>
>> A few days ago, I moved some things around in the ant-contrib
>> repository and updated the gump descriptors for ant-contrib and
>> cpptasks.
>
> This may as well be a case of anon svn access to sf.net lagging
> behind.  Woudn't be the first time ...
>
>> Unfortunately, it looks like Gump is not updating from the new
>> location.  Could someone blow away the ant- contrib and cpptasks
>> checkouts?
>
> I haven't changed anything, but it seems to be fine now.  Or isn't it?
>
> Stefan 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: [GUMP@vmgump]: Project dotnet-antlib-test (in module ant-antlibs) failed]

[Bill Barker]

"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:


$ 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.


You could try putting debug="true" on the  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/pu>blic/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.

Re: size of java cache dirs - .ivy is huge!

[Bill Barker]

"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?

[Bill Barker]

"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: mono broken on new vmgump?

[Bill Barker]

"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: [EMAIL PROTECTED]: Project lucene-java (in module lucene-java) failed

[Bill Barker]

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  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
> : 
> /jakarta-regexp/build/jakarta-regexp-03062007.jar:/usr/local/gump/packages/javacc-3.1/bin/lib/javacc.jar:/usr/local/gump/public/workspace/jline/target/jline-0.9.92-SNAPSHOT.jar:/usr/local/gump/packages/jtidy-04aug2000r7-dev/build/Tidy.jar:/usr/local/gump/public/workspace/junit/dist/junit-03

Re: [EMAIL PROTECTED]: Project logging-log4j-component (in module logging-log4j-component) failed

[Bill Barker]

"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:
>
>   
>

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:
>
>   
>
> 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-co

RE: Projects failing because there is no "cocoon"

[Bill Barker]

 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, March 15, 2007 10:18 PM
> To: general@gump.apache.org
> Subject: Projects failing because there is no "cocoon"
> 
> There are some projects
> - forrest
> - forrest-test
> - lenya
> which have dependency on cocoon.
> 
> Message
>   "Bad Dependency. Project: cocoon unknown to *this* workspace"
> 
> 
> Cocoons Gump-metadata is in project/cocoon/module.xml instead of
> project/cocoon.xml.
> Could that be a reason?
> 

No, it is because cocoon requires M2, so having it in Gump just generates a
lot of failed build noise.

> 
> 
> 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: Project ant-contrib (inmodule ant-contrib) failed

[Bill Barker]

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
> ---8-<---8-<---8-<---8-<---8-<---8-<--
> -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
> ---8-<---8-<---8-<---8-<---8-<---8-<--
> -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 

Re: mina

[Bill Barker]

"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  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: Cannot find problem: [Fwd: [EMAIL PROTECTED]: Project fulcrum-cache (in module jakarta-turbine-fulcrum) failed]

[Bill Barker]

Actually, the dependancy on concurrent is commented out in the project.xml 
file.  This is probably what is causing Maven to not find it (or find it in 
the wrong CL).

"Thomas Vandahl" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hi folks,
>
> could you please help me to pinpoint a problem with the configuration of
> the gump-build of the  fulcrum-cache module? The gump logs show that the
> concurrent library cannot be found. It is however referenced as
> dependency in the project descriptor. I tried to add the runtime="true"
> attribute to the dependency to no avail. What else can I do? I cannot
> reproduce the problem here.
>
> Thanks in advance,
> Thomas Vandahl
>
>  Original Message 
> Subject: [EMAIL PROTECTED]: Project fulcrum-cache (in module
> jakarta-turbine-fulcrum) failed
> Date: Sat, 30 Dec 2006 05:46:04 PST
> From: fulcrum-cache development 
> Reply-To: Turbine Developers List 
> To: turbine-dev@jakarta.apache.org
>
> 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 fulcrum-cache has an issue affecting its community integration.
> This issue affects 1 projects,
> and has been outstanding for 8 runs.
> The current state of this project is 'Failed', with reason 'Build Failed'.
> For reference only, the following projects are affected by this:
>- fulcrum-cache :  Services Framework
>
>
> Full details are available at:
>
> http://vmgump.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-cache/index.html
>
> That said, some information snippets are provided here.
>
> The following annotations (debug/informational/warning/error messages)
> were provided:
> -DEBUG- Sole output [fulcrum-cache-30122006.jar] identifier set to
> project name
> -DEBUG- Dependency on excalibur-framework-api exists, no need to add
> for property maven.jar.avalon-framework-api.
> -DEBUG- Dependency on excalibur-framework-impl exists, no need to add
> for property maven.jar.avalon-framework-impl.
> -DEBUG- (Gump generated) Maven Properties in:
> /usr/local/gump/public/workspace/jakarta-turbine-fulcrum/cache/build.properties
> -INFO- Failed with reason build failed
> -DEBUG- Maven POM in:
> /usr/local/gump/public/workspace/jakarta-turbine-fulcrum/cache/project.xml
> -DEBUG- Maven project properties in:
> /usr/local/gump/public/workspace/jakarta-turbine-fulcrum/cache/project.properties
> -INFO- Failed to extract fallback artifacts from Gump Repository
>
>
>
> The following work was performed:
> http://vmgump.apache.org/gump/public/jakarta-turbine-fulcrum/fulcrum-cache/gump_work/build_jakarta-turbine-fulcrum_fulcrum-cache.html
> Work Name: build_jakarta-turbine-fulcrum_fulcrum-cache (Type: Build)
> Work ended in a state of : Failed
> Elapsed: 46 secs
> Command Line: maven --offline jar
> [Working Directory:
> /usr/local/gump/public/workspace/jakarta-turbine-fulcrum/cache]
> CLASSPATH:
> /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-turbine-fulcrum/cache/target/classes:/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/ehcache-1.0/ehcache-1.0.jar:/usr/local/gump/packages/dougLea/concurrent.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-30122006.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-30122006.jar:/usr/l
> ocal/gump/public/workspace/jakarta-turbine-fulcrum/yaafi/target/fulcrum-yaafi-30122006.jar
> :/usr/local/gump/public/workspace/jakarta-turbine-fulcrum/testcontainer/target/fulcrum-testcontainer-30122006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-30122006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-30122006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-30122006.jar:/usr/local/gump/public/workspace/jakarta-turbine-jcs/target/jcs-30122006.jar
> -
>[junit] Could not initialize the container
>[junit] java.lang.RuntimeException: Could not initialize the container
>[junit] at
> org.apache.fulcrum.testcontainer.YAAFIContainer.startup(YAAFIContainer.java:90)
>[junit] at
> org.apache.fulcrum.testcontainer.BaseUnitTest.lookup(BaseUnitTest.java:134)
>[junit] at
> org.apache.fulcrum.cache.JCSCacheTest.setUp(JCSCacheTest.java:60)
>[junit]
>[junit]
>[junit] Testcase:
> testRefresh

Re: dependency on commons VFS sandbox

[Bill Barker]

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

[Bill Barker]

"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: Maven2 builds

[Bill Barker]

"Brett Porter" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On 14/11/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> As long as we don't build Maven from scratch, I'd say we give it the
>> plugins it needs to run from the repo as well.  This could be done by
>> building bcel without --offline once manually.
>
> But that will pull down non-Maven things - like dependencies of bcel
> (if there are any).
>
> It's still a short term solution until someone has time to implement
> the proposals I've put up here before.
>

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 have a question about local Maven 2 caches?  Can I have mutliple of
>> them in different locations?
>
> Yes. Run mvn --settings /path/to/settings.xml and put the local
> repository in there.
>
> - Brett 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Installing a fresh gump2 yields lots of issues

[Bill Barker]

"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

[Bill Barker]

"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
>> 
>
> 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: bcel failure

[Bill Barker]

 

> -Original Message-
> From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, November 09, 2006 9:53 PM
> To: Gump code and data
> Subject: Re: bcel failure
> 
> 
> > We don't support Maven2 at all ATM.
> >
> > Stefan
> >
> >   
> So we need a snake tamer to play with the Python and add the 
> Maven2 support.
> 

Actually, we already have the Python part (at least in trunk).  What we need
is a M2 repository management that allows us to override the jar version in
the pom.

> Regards,
> Antoine
> 
> 
> -
> 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: AW: Guidance on the Pluto Portal Gump build

[Bill Barker]

"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  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

[Bill Barker]

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

[Bill Barker]

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

[Bill Barker]

 

> -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: JUnit test failure on MacOSX

[Bill Barker]

"Sander Temme" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> See: http://clarus.apache.org/junit/junit/gump_work/ 
> build_junit_junit.html
>
> And, this appears to be on MacOSX only, since both vmgump and  gump.zones 
> show the junit entry as green in the logs.
>
> It seems that a single test is failing because it expects a different 
> return value from a subprocess. No idea what would be different, no  time 
> to investigate and I fear I lack applicable knowledge in the  Java space.
>
> Anyone know what could be happening and why?
>

Well, from the JUnit code, the subprocess is basically:
  $JAVA_HOME/bin/java -cp . org.junit.runner.JUnitCore 
org.junit.tests.JUnitCoreTest$Fail

That *should* end up calling System.exit(1), which in turn *should* cause 
'java' to return a status code of 1 to the caller.  I don't know OS/X enough 
to have a guess as to which of these isn't happening.

> I'll be happy to give any committer who wants to give this a gander  an 
> account on Clarus.
>
> 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: How are gump_stats and gump_xref generated?

[Bill Barker]

"Sander Temme" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> See:
>
> http://clarus.apache.org/gump_stats/index.html
> http://clarus.apache.org/gump_xref/index.html
>
> Both give 404s, but are available on other Gump installations like 
> vmgump. I want them, too! How are these pages generated?
>

They are only generated for "Official" runs.  Last I was aware, Clarus 
doesn't have any "Official" runs.

> 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: Cargo jars

[Bill Barker]

I've uploaded the jars to vmgump (as usual, Helios and Clarus will need to 
rsync :).

For packaged projects, about all you can do is to drop a note to 
[EMAIL PROTECTED] and hope somebody picks it up.  There isn't currently a way 
to 
have Gump do the dirty work itself.


Of course, it would be nice if somebody could figure out why cargo doesn't 
build, so we could do away with packaged-cargo-* ;-).


"Felipe Leme" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Hi all,

I've updated Gump's cargo dependencies to 0.8 and I'm almost sure it
will break Cactus and Jetspeed builds (well, Cargo was already broke,
that's the reason I've changed it :-), so I'm giving you a heads up.

So, what I did was to update release from 0.6 to 0.8 and break the
cargo-package 
(https://svn.apache.org/repos/asf/gump/metadata/project/packaged-cargo.xml)
into cargo-package-core and cargo-package-ant (Cargo has been split in
many different jars), change the cargo-0.6.jar to
cargo-core-uberjar-0.8.jar and update cactus and jetspeed xml files to
reflect the change. What I didn't do though was to change something in
order to inform where to get those new jars - what should have I done?
Should I have uploaded then somewhere?

[]s,

-- Felipe 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jakarta-velocity-test problem

[Bill Barker]

"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
> /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

[Bill Barker]

 

> -Original Message-
> From: Cameron McCormack [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 24, 2006 3:41 PM
> To: batik-dev@xmlgraphics.apache.org
> Cc: 'Gump code and data'
> Subject: Re: [EMAIL PROTECTED]: Project xml-batik (in module 
> xml-batik) failed
> 
> Hi Bill.
> 
> Bill Barker:
> > You would just have to change the Gump descriptor 
> xml-batik.xml and replace
> >   
> > with
> >   
> 
> Are there some instructions on how I can change this?  Is it 
> accessible
> from SVN somewhere?
> 

$ svn co https://svn.apache.org/repos/asf/gump/metadata
$ cd metadata/project
$ vi xml-batik.xml
$ svn ci

> > Of course, this will mean that you won't get notified if 
> Rhino makes an
> > incompatible change that would break Batik :).
> 
> That's ok, I'm going to have to track Rhino myself until they 
> accept my
> patches. :-)
> 
> Thanks,
> 
> Cameron
> 
> -- 
>  Cameron McCormackICQ: 26955922
>  cam (at) mcc.id.au   MSN: cam (at) mcc.id.au
>  http://mcc.id.au/JBR: heycam (at) jabber.org
> 
> -
> 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 xml-batik (in module xml-batik) failed

[Bill Barker]

 

> -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
  
with
  

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: on java1.5

[Bill Barker]

"Steve Loughran" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>
>
> Now that Gump has switched to java1.5, its showing up some problems in 
> javac.
>
> Specifically, it appears to be defaulting to source=1.5
>
> This breaks junit addons
>

This isn't as big of an issue as it looks from the "Issues" page.  It mostly 
affects Cocoon, which won't build anyway since it requires Maven2.

While it would be nice to have a System.property for this, just to clear out 
the dead projects that don't care about Java5 (since they are dead :).  The 
truth is that it won't really raise the numbers much.  Gump's real losses 
right now are to M2, not to Java5.

> http://vmgump.apache.org/gump/public/junit-addons/junit-addons/gump_work/build_junit-addons_junit-addons.html
>
> I checked out the source in CVS; they are not saying source="1.5"; they 
> are not saying anything about the source version. Yet javac has switched 
> to java1.5. This is breaking backwards compatibility for builds.
>
>
>
> Also,  shouldnt warn people about source=1.2 on every compile:
>
> http://vmgump.apache.org/gump/public/emma/emma/gump_work/build_emma_emma.html
>
>
>  Once per build should suffice. Maybe we could set an internal property 
> _internal.warned.user.about.target that only triggers a warn when it aint 
> set. 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Junit nagging and CVS timeouts

[Bill Barker]

 

> -Original Message-
> From: Curt Arnold [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 15, 2006 10:34 AM
> To: Gump code and data
> Subject: Junit nagging and CVS timeouts
> 
> Backstory: I've been on the junit mailing list for a few 
> hours trying  
> to track down a problem that has recently surfaced in the log4j unit  
> tests on Gump that I believe is due to a change in junit.  To  
> complicate issues, the junit anonymous CVS server has been  
> unresponsive, so I haven't been able to see the code in question or  
> reproduce it the problem locally.  So I've been driving blind with a  
> little help from Gump.
> 

>From your commit messages, I believe that it's the same Ant bug that was
killing commons-collections last week.  The short version is that when Ant
auto-detects JUnit-4, it doesn't look for the static suite() method, and
just assumes that you've defined all of your tests with Annotations.

> David Saff mentioned that he had not gotten any automated failure  
> messages from Gump for junit, though I would have suspected some on  
> 09-Mar-2006.  So I dived into looking at the project gump 
> descriptor,  
> not realizing that he had been added as the nagee on the 12- 
> Mar-2006.  Before I realized it was a brand new entry, I did notice  
> that the "to" address in the junit nag contained < and > and  
> that no "to" address in nag elements in other projects contained  
> those characters.   They were common  in "from" addresses.  Maybe it  
> isn't wrong, just different.
> 
> Anyway, it seemed undesirable to nag him personally instead of the  
> development list.  Thought it may be good to use him as the 
> sender to  
> get through the non-subscriber blocking and to avoid replies and  
> bounces to [EMAIL PROTECTED]  Any comments on changing the  
> junit nag as described below?
> 

Well, David Saff agreed to be nagged personally (check the [EMAIL PROTECTED]
archives), not the entire junit project.  There are a number of other
projects that nag an individual instead of the development list.  Since the
nags are usually once a day, it looks ok to change it to the junit-devel
list.

> 
> 
> Begin forwarded message:
> 
> > From: David Saff <[EMAIL PROTECTED]>
> > Date: March 15, 2006 11:55:13 AM CST
> > To: Curt Arnold <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [Junit-devel] SourceForge CVS
> >
> > Curt Arnold wrote:
> >> The current project descriptor contains:
> >>
> >>  >>  to="David Saff <[EMAIL PROTECTED]>" />
> >>
> >> I could change it to:
> >>
> >>  >>   to="[EMAIL PROTECTED]" />
> >>
> >> or post a request to the Gump mailing list to review your project  
> >> descriptor.
> >
> > I have no knowledge of Gump nag descriptor formatting, so 
> I'll have  
> > to ask your help on this.  How often are the nag messages 
> sent?  If  
> > it's daily or less, then sending it to junit-devel should 
> be fine.   
> > Otherwise, please have it sent straight to me.  Thanks,
> >
> >David Saff
> 
> Also, the anonymous CVS server for junit has been unresponsive as  
> seen in the "All dressed up" message on 09-Mar-2006 (http:// 
> marc.theaimsgroup.com/?l=gump&m=114190474119176&w=2).
> 
> 
> The following annotations (debug/informational/warning/error  
> messages) were provided:
>   -ERROR- *** Failed to update from source control. Stale contents ***
> 
> I thought that I saw a similar error in the log for the 14-Mar-2006  
> Gump run, though the 15-Mar-2006 run completed successfully.  Should  
> a nag message had been sent if the same problem occurred yesterday?   
> Any documentation of CVS failures may be helpful to the SourceForge  
> staff in identifying the problem with the JUnit CVS or at 
> least gives  
> JUnit documentation when to back up their complaints.
> 
> If source control failure does not result in a Nag message, maybe it  
> should be configurable to do so.
> 

The SF CVS repos is notorious for failing.  As a result, the 'live' branch
(which is what runs on vmgump) just continues on with the stale checkout.
The clarus and helos runs are using 'trunk', which would presumably nag if
they were configured to do so.

> I've told David that I would raise the issues here and take 
> no action  
> myself without feedback.  I think it would be desirable to 
> change the  
> nagee to [EMAIL PROTECTED] instead of [EMAIL PROTECTED]  
> and believe he consents since the messages should be at most daily.   
> I'll defer to more experienced hands on the proper from address.
> 
> 
> -
> 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 attach

Re: hibernate3 + EJB stuff?

[Bill Barker]

"Steve Loughran" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>
>
> I have a  (low priority) need for hibernate3 and the EJB plugin. Has 
> anyone approached the hibernate people about joining gump?

Joining Gump is better than not (since there is some hope of support from 
the developers then, as well as a  :), but it's not a prerequisite. 
As long as they provide a public check-out, it's simply Ok to go ahead and 
add it to Gump.  We already have several OS projects (e.g. htmlunit) that 
we've simply gone ahead and added without asking.  If you don't ask, just 
make sure that you don't  back to their list.

Gump's current policy is to not re-distribute any jars from the Gump build, 
so Geir's licensing concerns are a non-issue for Gump.  Of course, it may be 
an issue for your projects, but that's [OT] ;-).




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: BATCH: All dressed up, with nowhere to go...

[Bill Barker]

-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  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: svn commit: r383419 - /gump/metadata/project/smartfrog.xml

[Bill Barker]

-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=383419&view=rev
>Log:
>junit are trying very hard to make people stop using them

;-)

Another option would be to  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: svn commit: r382451 - /gump/metadata/project/args4j.xml

[Bill Barker]

-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=382451&view=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: Problem while adding a new project to gump

[Bill Barker]

 

> -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 ge"nderte 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: r381566 - /gump/metadata/project/xstream.xml

[Bill Barker]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Mon 2/27/2006 9:30 PM
To: commits@gump.apache.org
Subject: svn commit: r381566 - /gump/metadata/project/xstream.xml
 
>Author: bodewig
>Date: Mon Feb 27 21:30:33 2006
>New Revision: 381566
>
>URL: http://svn.apache.org/viewcvs?rev=381566&view=rev
>Log:
>xstream has downgraded joda-time (???)

No, vmgump needed to have the cvs/xstream cleared out (which I've already 
done).  Just take a look at clarus.




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 builds and library tasks

[Bill Barker]

 

> -Original Message-
> From: Steve Loughran [mailto:[EMAIL PROTECTED] 
> Sent: Monday, February 27, 2006 9:20 AM
> To: Gump code and data
> Subject: Re: Maven builds and library tasks
> 
> Bill Barker wrote:
> > "Steve Loughran" <[EMAIL PROTECTED]> wrote in message 
> > news:[EMAIL PROTECTED]
> >>
> >> A couple of maven-repository related questions. as that is 
> the main cause 
> >> of the new projects I've added not building.
> >>
> >>
> >> 1. how do I get the local repository into enough shape 
> that maven1 works? 
> >> This is a prerequisite to getting either ws-commons or 
> ws-axis2 to work?
> >>
> > 
> > IMHO, there is already way too much in the local repository 
> already.  But as 
> > Brett has already said, this is a limitation of how Gump 
> and Maven interact.
> 
> I actually quite like the fact that gump at least sanity checks the 
> validity of the M1/M2 dependency graph,
> because if it doesnt, well, that can get you into trouble in many 
> different ways. so while doing any
> in-build dependency fetching of classpaths is futile, it does 
> at least 
> check that that part of your code works to the level of "all the 
> declared dependencies are retrievable".
> 
> 
> > 
> >> 2. I'm thinking of skipping classpath setup using the 
> m2-tasks when on 
> >> gump. Is there a well known properly like "gump.run" that 
> is set when ant 
> >> is running under gump, or should I make one up.
> > 
> > Try build.sysclasspath=only.  This, more generally tells 
> you that Ant is 
> > going to ignore any classpath setup you do.
> 
> yes. I was also thinking of having a proper switch to say "dont run 
> functional tests here"; inferring that from build.sysclasspath is 
> probably bad form.
> 

For Maven projects, you can simply use maven.test.skip=true.

For Ant projects, people either use a special gump-run target, or (less
commonly) a special gump.run property.  However, you'd have to set it
explicitly in the project file:  Gump won't do it for you.

> -
> 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: Maven builds and library tasks

[Bill Barker]

"Steve Loughran" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>
>
> A couple of maven-repository related questions. as that is the main cause 
> of the new projects I've added not building.
>
>
> 1. how do I get the local repository into enough shape that maven1 works? 
> This is a prerequisite to getting either ws-commons or ws-axis2 to work?
>

IMHO, there is already way too much in the local repository already.  But as 
Brett has already said, this is a limitation of how Gump and Maven interact.

> 2. I'm thinking of skipping classpath setup using the m2-tasks when on 
> gump. Is there a well known properly like "gump.run" that is set when ant 
> is running under gump, or should I make one up.

Try build.sysclasspath=only.  This, more generally tells you that Ant is 
going to ignore any classpath setup you do.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven question: bcel

[Bill Barker]

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: tracking down an m2-libraries related problem

[Bill Barker]

"Bill Barker" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Setting debug="true" in the  tag should turn on verbose logging by
> Ant.  I've no idea if that will trigger more logging by the  task 
> :).
>

Ok, that's what I get from going off of the documentation instead of the 
code :).

It shouldn't be that hard to patch (it's just missing checking the attribute 
during the xml parsing), but I'm unlikely to get around to it at least 
before the weekend sometime.
 :).

>> -Original Message-
>> From: Steve Loughran [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, February 21, 2006 9:15 AM
>> To: Gump code and data
>> Subject: tracking down an m2-libraries related problem
>>
>>
>> from the trace of smartfrog-xml
>>
>> m2:
>> [m2-libraries] Resolving dependencies...
>> unspecified:unspecified:jar:0.0 (selected)
>>xerces:xmlParserAPIs:jar:2.6.2 (selected)
>>xom:xom:jar:1.1 (selected)
>>  xom:xom:jar:1.0b3 (removed - causes a cycle in the graph)
>>  jaxen:jaxen:jar:1.1-beta-8 (selected)
>>jaxen:jaxen:jar:1.0-FCS (removed - causes a cycle in the graph)
>>jdom:jdom:jar:1.0 (selected)
>>  xalan:xalan:jar:2.5.0 (selected)
>>  xerces:xmlParserAPIs:jar:2.6.2 (removed - nearer found: 2.6.2)
>>  xerces:xercesImpl:jar:2.6.2 (selected)
>>  xalan:xalan:jar:2.7.0 (selected)
>>
>> BUILD FAILED
>> /x1/gump/public/workspace/smartfrog/components/xml/build.xml:5
>> 4: Unable
>> to resolve artifact
>>
>>
>> Its pretty hard to determine failures here, primarily because the m2
>> tasks dont print enough out at the normal level of verbosity.It looks
>> like its built a graph of xom1.1, jaxen1.1-beta-8 and
>> xerces/xalan, but
>> is failing to find one of these.
>>
>> Is there any way to turn on extra verbosity to get more detailed
>> diagnostics?
>>
>> -
>> 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: handling svn branches

[Bill Barker]

 

> -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 , 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 ).  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 
>  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: what version of the maven2 ant tasks are installed?

[Bill Barker]

"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  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 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: what version of the maven2 ant tasks are installed?

[Bill Barker]

"Steve Loughran" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>
> I'm getting a build failing because the  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: tracking down an m2-libraries related problem

[Bill Barker]

Setting debug="true" in the  tag should turn on verbose logging by
Ant.  I've no idea if that will trigger more logging by the  task :). 

> -Original Message-
> From: Steve Loughran [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, February 21, 2006 9:15 AM
> To: Gump code and data
> Subject: tracking down an m2-libraries related problem
> 
> 
> from the trace of smartfrog-xml
> 
> m2:
> [m2-libraries] Resolving dependencies...
> unspecified:unspecified:jar:0.0 (selected)
>xerces:xmlParserAPIs:jar:2.6.2 (selected)
>xom:xom:jar:1.1 (selected)
>  xom:xom:jar:1.0b3 (removed - causes a cycle in the graph)
>  jaxen:jaxen:jar:1.1-beta-8 (selected)
>jaxen:jaxen:jar:1.0-FCS (removed - causes a cycle in the graph)
>jdom:jdom:jar:1.0 (selected)
>  xalan:xalan:jar:2.5.0 (selected)
>  xerces:xmlParserAPIs:jar:2.6.2 (removed - nearer found: 2.6.2)
>  xerces:xercesImpl:jar:2.6.2 (selected)
>  xalan:xalan:jar:2.7.0 (selected)
> 
> BUILD FAILED
> /x1/gump/public/workspace/smartfrog/components/xml/build.xml:5
> 4: Unable 
> to resolve artifact
> 
> 
> Its pretty hard to determine failures here, primarily because the m2 
> tasks dont print enough out at the normal level of verbosity.It looks 
> like its built a graph of xom1.1, jaxen1.1-beta-8 and 
> xerces/xalan, but 
> is failing to find one of these.
> 
> Is there any way to turn on extra verbosity to get more detailed 
> diagnostics?
> 
> -
> 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

[Bill Barker]

-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=379266&view=rev
>Log:
>Fix location of xmlrpc metadata
>
>Modified:
>gump/metadata/profile/gump.xml

The file name changed (along with the  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

[Bill Barker]

"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 List 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?

[Bill Barker]

"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]

[VOTE] Resolving JUnit failures

[Bill Barker]

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
http://vmgump.apache.org/gump/public/junit/junit/gump_work/build_junit_junit.html
>CLASSPATH :/opt/jdk1.4/lib/tools.jar ...
>[javac] Compiling 139 source files to /x1/gump/public/workspace/junit
>[javac] 
> /x1/gump/public/workspace/junit/junit/extensions/ActiveTestSuite.java:20: 
>  > expected
>[javac] public ActiveTestSuite(Class theClass) {
>
>
>It seems that JUnit needs Java5, but got only a 1.4...

Yup.  It seems like our options are:
1) Change vmgump to run with Java 5, and hope that the ~50% coverage we got 
last time has been fixed by their respective projects (it's been awhile, so 
who knows :).
2) Change the 196 projects that  on JUnit to used packaged-junit 
(ugh).
3) Change JUnit to build from a branch (not as bad as 2, but still not what 
Gump is about)
4) Just hope that the JUnit project comes to their senses, and restores JVM 
1.4 compatibility (not likely, given how extensive the change seems to be).

If it wasn't for the fact that most projects that adopt Java 5 also seem to 
soon after move to exclusively requiring Maven2, I'd vote 1) (e.g. mina). 
If JUnit plans to do that as well, we might as well do 2) or 3), since Gump 
support for Maven2 seems a long way off :(.

And, actually, the inclusion of the [VOTE] is more in the hopes of getting 
people to actually read this.  So, if anybody has any better ideas to 
resolve this, just add them to the list, and they will be counted.  Also, 
since this is mostly metadata, I'm considering all votes from ASF committers 
binding (although, as always, the Gump PMC could choose to override this :). 
And, needless to be said, I'm volunteering for any grunt-work that needs to 
be done to implement it (please vote 1 or 4 :).

>Jan




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Failure in derby-split-1

[Bill Barker]

 

> -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

[Bill Barker]

 

> -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  instead of a
 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;
> > [

Re: Gump on MacOSX

[Bill Barker]

"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: . 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  tag in clarus.local.xml to:
  

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

[Bill Barker]

"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, S&N 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

[Bill Barker]

"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, S&N 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: SourceForge CVS failure

[Bill Barker]

"Paul Smith" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hi All,
>
> I recently added the JmDNS project to Gump (see jmdns.xml), which I
> based on the Quartz definition, however it's having trouble checking
> out the project from CVS by the looks of it.
>
> http://vmgump.apache.org/gump/public/jmdns/gump_work/update_jmdns.html
>
> Command Line
>
> cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:/cvsroot/jmdns
> checkout -P
> jmdns
>
> Output
>
> cvs [checkout aborted]: reading from server: Connection reset by peer
>
> I notice that the Quartz gump run is having a similar, but not
> exactly the same, problem with getting the update from SF's CVS repo.
>
> Anything I can do to fix this, or is getting code from SF a bit of a
> hit and miss affair?
>

Getting code from SF is a bit of a hit and miss affair.  It's one of the 
reasons that it's not uncommon for Helios (http://gump.zones.apache.org) to 
have a success rate well under 40%.



> cheers,
>
> Paul Smith
>
>
> 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]