-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: 11 March 2004 08:37
To: [EMAIL PROTECTED]
Subject: Re: [RT] Moving gump forward
On Wed, 10 Mar 2004, Vincent Massol [EMAIL PROTECTED] wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
I have no idea
On Thu, 11 Mar 2004, Vincent Massol [EMAIL PROTECTED] wrote:
What do you mean by command line of Maven? Do you mean passing it
as a system property like this:
maven -Dbuild.property=... [...]
?
Yes.
If so, this is fine.
Does it also work for other properties?
I mean, if we set
bodewig 2004/03/11 00:50:36
Modified:src/documentation/content/xdocs/metadata workspace.xml
Log:
Gumpy requires name attribute
Revision ChangesPath
1.3 +7 -1 gump/src/documentation/content/xdocs/metadata/workspace.xml
Index: workspace.xml
On Thu, 11 Mar 2004, Vincent Massol [EMAIL PROTECTED] wrote:
Everything runs fine here. Thus I think it can be caused either by a
different configuration or by the fact that it runs on a different
OS.
It fails on lsd as well as gump.covalent.net, so it fails using Gumpy
or traditional Gump
On Thu, 11 Mar 2004, Vincent Massol [EMAIL PROTECTED] wrote:
For the most important part (compiling), Gump would be independent
of Maven's jar override feature that way.
Yeah but I'm not sure this is the right way with Maven.
Probably not.
It looks like tweaking a bit too much the product
Hi,
I thought I'd start small and used
$ python2 ./gump/integrate.py -w ../bodewig.xml bootstrap-ant
ERROR:gump:Failed to find environment variable [MAVEN_HOME]
WARN:gump:Command failed. [javac -help ]. ExitCode: 2
ERROR:gump:Failed to detect [javac]
WARN:gump:Command failed. [java
Hi,
I've seen that lsd's workspace has a nag=true attribute, I assume
this is a boolean switch to enable/disable nagging.
Traditional used a nag element in the workspace with the
additional benefit that you could force all nag mails to go to a
specific address. I very much like this feature
niclas 2004/03/11 01:24:44
Modified:project avalon-excalibur.xml
Log:
To get the excalibur-logger working. One more step in the right direction.
Revision ChangesPath
1.100 +5 -8 gump/project/avalon-excalibur.xml
Index: avalon-excalibur.xml
On Thu, 11 Mar 2004, Stefan Bodewig [EMAIL PROTECTED] wrote:
and here it is sitting since more than 16 CPU minutes. Any ideas?
update, it finished about ten minutes later - all in all taking more
than half an hour. Is this to be expected? The build of
bootstrap-ant took 58 seconds according
On Thu, 11 Mar 2004, Vincent Massol [EMAIL PROTECTED] wrote:
Cactus does not use directly commons-code. It may be used by a
cactus dependency like Tomcat, Commons HttpClient or
others.
I think it is httpclient.
Wouldn't it be better to add this dependency to the project directly
using it
Hi Stefan,
Thanks for your help. However, I don't see how I can debug this without
having access to a gump install. There's nothing wrong in the build
itself. It just fails on one test.
I believe the error might be due to the fact that Cactus is supposed to
be executed on a machine where
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: 11 March 2004 10:31
To: [EMAIL PROTECTED]
Subject: Re: [Cactus] commons-codec added to dependency jars?
On Thu, 11 Mar 2004, Vincent Massol [EMAIL PROTECTED] wrote:
Cactus does not use directly
On Thu, 11 Mar 2004, Vincent Massol [EMAIL PROTECTED] wrote:
It's a pity that
http://lsd.student.utwente.nl/gump/jakarta-cactus/jakarta-cactus-sample-
servlet-13.html has a pre-req failure as we would have been able to
see if it passed the tests fine (it's using Tomcat 4.x and not
Tomcat
On Thu, 11 Mar 2004, Vincent Massol [EMAIL PROTECTED] wrote:
Again the problem is the same. I don't have access to a gump machine
and I don't want to make a CVS change if I can verify it still
works...
and I don't have access to the cactus descriptors ;-)
I think if you want to make Gump
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: 11 March 2004 10:45
To: [EMAIL PROTECTED]
Subject: Re: How to debug a Gump build problem?
On Thu, 11 Mar 2004, Vincent Massol [EMAIL PROTECTED] wrote:
It's a pity that
On Thu, 11 Mar 2004, Stefan Bodewig [EMAIL PROTECTED] wrote:
and I don't have access to the cactus descriptors ;-)
Ooops, in fact I have, sorry.
I'll make the change.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
On Thu, 11 Mar 2004, Vincent Massol [EMAIL PROTECTED] wrote:
What would be very useful is to check the /tmp directory.
tomcat3x.zip in my home dir.
Cheers
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
bodewig 2004/03/11 02:24:22
Modified:project jakarta-cactus.xml
Log:
cactus doesn't depend on codec, it inherits the dependency via httpclient
Revision ChangesPath
1.36 +2 -4 gump/project/jakarta-cactus.xml
Index: jakarta-cactus.xml
On 11 Mar 2004, [EMAIL PROTECTED] wrote:
To get the excalibur-logger working. One more step in the right
direction.
great.
Compilation fails with
[javac]
/javastuff/gump/avalon-excalibur/logger/src/java/org/apache/avalon/excalibur/logger/factory/PriorityFilterTargetFactory.java:26:
On Thursday 11 March 2004 19:39, you wrote:
PriorityFilter
SIts in avalon-logkit, and I thought the line,
depend property=logkit.jar project=avalon-logkit runtime=true/
would bring that in.
Strange.
Niclas
--
+-//---+
| http://www.bali.ac |
|
On Thursday 11 March 2004 19:39, Stefan Bodewig wrote:
there is no class named PriorityFilter in any of the avalon modules,
but there seem to be API docs in avalon-site, strange.
Oops, you are right...
It is not in the source directories, but in the target/ directory of
avalon-logkit.
Hold
Vincent,
I've rerun the build with tcpdump running to get an idea of what is
actually happening:
- GET /cactus-sample-servlet-cactified/ServletRedirector?Cactus_Service=RUN_TEST
- 200 OK
- GET /cactus-sample-servlet-cactified/ServletRedirector?Cactus_Service=RUN_TEST
- 200 OK
- GET
On Thursday 11 March 2004 19:39, Stefan Bodewig wrote:
PriorityFilterTargetFactory.java
I think I have located the problem.
There is a copy of source files prior to compilation, and the file that fails
is a old file, no longer in the CVS repository.
Makes sense? Does Gump clean the build
On Thu, 11 Mar 2004, Niclas Hedhman [EMAIL PROTECTED] wrote:
It is not in the source directories, but in the target/ directory of
avalon-logkit.
Probably a stale copy.
I guess the file has been removed, let me see
On Thu, 11 Mar 2004, Niclas Hedhman [EMAIL PROTECTED] wrote:
Does Gump clean the build output directories?
Yes, each night's run is performed against clean checked out trees
(unless rsync is playing funny games).
Stefan
-
To
Vincent Massol wrote:
My question is: What are the facilities given to projects to debug Gump
builds?
not that much, at the moment. The main gumpy runs on a machine in our
flat's living room.
More specifically: Do we have a shell account with read access to the
directory where Gump built the
Wow. Good debugging! Thanks Stefan for your help.
I'm trying to run the cactus build on cvs.apache.org to see if I can
reproduce the problem. I'll let you know as I make progress.
Thanks
-Vincent
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: 11 March 2004
-
20040311.jar -Djunit.jar=/data3/gump/dist/junit/junit.jar -
Dhttpunit.jar=/data3/gump/httpunit/lib/httpunit.jar -
Dcommons.logging.jar=/data3/gump/jakarta-commons/logging/dist/commons-
logging.jar -Dnekohtml.jar=/data3/gump/opt/nekohtml-0.9.1/nekohtml.jar
-
Dcommons.httpclient.jar=/data3/gump
Hi,
It seems that the following line was added to the Cactus descriptor:
depend project=commons-codec/
However, Cactus does not use directly commons-code. It may be used by a
cactus dependency like Tomcat, Commons HttpClient or others. Wouldn't it
be better to add this dependency to the project
Hi,
In the past, Sam had provided some configuration so that Gump would
upload every day the Cactus website (built as part of the Cactus build)
to jakarta.apache.org/cactus. That was quite nice.
I'd love to see Gump(y) add even more value to projects (such as
deploying their web sites every
:
- - - - - -- -- G U M P
Gump provided these annotations:
- Info - Sole jar
[/data3/gump/jakarta-velocity-tools/velocity-tools-20040311.jar]
identifier set to project name
- Error - Failed with reason build failed
and here it is sitting since more than 16 CPU minutes. Any ideas?
I'll let it run a little longer, I can still work on my machine even
though python is using up 99% of the CPU.
Basically the forrest documentation generation is somewhat exhaustive then
the forrest run itself is intensive.
Ok. First update: I've successfully run the servlet sample build on a
unix machine (cvs.apache.apache) using Tomcat 3.3.2.
Thus I now suspect the gump command line (i.e. the way it points to a
possibly unfinished Tomcat install).
Stefan, do you think you could make available the content of the
On Mar 9, 2004, at 2:27 AM, Stefan Bodewig wrote:
BTW: I suspect that gump could implemented by writting the ant
script on the fly w/o us having to reinvent the wheel.
See the antgump proposal in Alexandria - maybe Scott can chime in
here?
My latest try was vindico, an ant-based gump. I got far
nickchalko2004/03/11 11:22:33
Modified:blog/Issues Struts-Velocity.txt
Log:
Fixed link
PR:
Obtained from:
Submitted by:
Reviewed by:
CVS: --
CVS: PR:
CVS: If this change addresses a PR in
Is it premature to talk about this?
http://gump.chalko.com/gb/blog/Issues/?smm=ypermalink=Struts-Velocity.txtpreview=true
I like to keep the visibility up. but is the risk of stepping on toes to
large?
R,
Nick
-
To unsubscribe,
nickchalko2004/03/11 11:41:04
Modified:blog/Issues Struts-Velocity.txt
Log:
Fixed the preview note.
PR:
Obtained from:
Submitted by:
Reviewed by:
CVS: --
CVS: PR:
CVS: If this change
nickchalko2004/03/11 11:54:20
Modified:blog/Issues Struts-Velocity.txt
Log:
Added AL2.0.
Is this overkill or required.
PR:
Obtained from:
Submitted by:
Reviewed by:
CVS: --
CVS: PR:
CVS:
On Thu, 11 Mar 2004, Stefan Bodewig [EMAIL PROTECTED] wrote:
and here it is sitting since more than 16 CPU minutes. Any ideas?
update, it finished about ten minutes later - all in all taking more
than half an hour. Is this to be expected? The build of
bootstrap-ant took 58 seconds
ajack 2004/03/11 12:52:06
Modified:python/gump/utils sync.py
Log:
Skip .svn and CVS directories.
Revision ChangesPath
1.5 +7 -4 gump/python/gump/utils/sync.py
Index: sync.py
===
RCS
I have read this on the jdom list, and I thought that someone on the
gump list might know about that.
Original Message
Subject:Re: [jdom-interest] XPath problem using org.jdom.xpath
Date: Thu, 11 Mar 2004 08:48:30 -0600
From: Bradley S. Huffman [EMAIL PROTECTED]
To:
Some random thoughts,
lately I have not been able to contribute much, my employer makes me
work too. ;-)
I have the impression that we are progressing.
For instance, I like very much that Niclas is trying to fix the avalon
builds. Also with jakarta-slide,
Unico Hommes is working to solve an
Stefan Bodewig wrote:
On Thu, 11 Mar 2004, Vincent Massol [EMAIL PROTECTED] wrote:
The biggest problem is that Gump doesn't run the build in the same
than projects are running their builds! It's using sysclasspathonly
feature and that's not the way it's run by project.
[snip]
Maybe an
ajack 2004/03/11 18:48:31
gump/template/forrest/src/documentation/content/images - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ajack 2004/03/11 18:50:53
Modified:python/gump/document forrest.py resolver.py xdoc.py
python/gump/utils launcher.py __init__.py
python/gump/test pyunit.py
template/forrest/src/documentation skinconf.xml
Added:
45 matches
Mail list logo
