[Cargo] Missing some dep in Gump's local Maven Repository

[Vincent Massol]

Hi,

The cargo build (http://tinyurl.com/bg2h2) is missing the following file:
commons-jelly-tags-util-20030211.141939.jar

This file is present on ibiblio:
http://www.ibiblio.org/maven/commons-jelly/jars/

Does it mean the local Maven install has no remote repo set up to prevent
downloads? If so, could someone manually drop this file in there?

Thanks
-Vincent




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

FW: [GUMP@brutus]: jakarta-cactus/jakarta-cactus-integration-ant-13 prerequisite failed

[Vincent Massol]

Hi,

How should I understand this email? It says the project has *no longer*
an issue. So why do I get an email? Also it says that there is a
Prerequisite failed. Then it says the optional dependency on checkstyle
was not available. But it's optional so it shouldn't fail the build.

Now, if I look on the web page, it says that bootstrap-ant failed. So
that may be the reason.

So 2 questions:
1/ why do I get an email on a prereq failure? Is it normal?
2/ why does the email below not include the reason of the prereq failure
(i.e. bootstrap-ant)?

Thanks
-Vincent

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 25 May 2004 01:13
> To: [EMAIL PROTECTED]
> Subject: [EMAIL PROTECTED]:
jakarta-cactus/jakarta-cactus-integration-ant-13
> prerequisite failed
> 
> To whom it may satisfy...
> 
> This is an automated request, but not an unsolicited one. For
> more information please visit http://gump.apache.org/nagged.html,
> and/or contact folk at [EMAIL PROTECTED]
> 
> Project jakarta-cactus-integration-ant-13 *no longer* has an issue.
> Project State : 'Prerequisite Failed', Reason 'Build Failed'
> 
> Full details are available at:
> 
> http://brutus.apache.org:8080/gump/jakarta-cactus/jakarta-cactus-
> integration-ant-13/index.html
> 
> That said, some snippets follow:
> 
> 
> The following annotations were provided:
>  -INFO- Sole jar [cactus-ant-20040524.jar] identifier set to project
name
>  -INFO- Dependency on jakarta-servletapi-4 exists, no need to add for
> property servlet.jar.
>  -INFO- Dependency on xml-xerces exists, no need to add for property
> xerces.jar.
>  -INFO- Dependency on xml-xerces exists, no need to add for property
> xmlapis.jar.
>  -INFO- Optional dependency checkstyle prerequisite failed with reason
> build failed
>  -INFO- Prerequisite failed with reason build failed
> 
> 
> 
> To subscribe to this information via syndicated feeds:
>  RSS:
http://brutus.apache.org:8080/gump/jakarta-cactus/jakarta-cactus-
> integration-ant-13/rss.xml
>  Atom:
http://brutus.apache.org:8080/gump/jakarta-cactus/jakarta-cactus-
> integration-ant-13/atom.xml
> 
> 
> --
> Produced by Gump 2.0.3-alpha-0002.
> [Run (20040524 15:00:12, brutus:brutus-public:20040524 15:00:12)]
> http://brutus.apache.org:8080/gump/index.html
> http://brutus.apache.org:8080/gump/options.html
> 
> --
> Apache Gump
> http://gump.apache.org/ [Instance: brutus]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]




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

FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-sample-servlet-13 failed

[Vincent Massol]

Hello,

Why is Gumpy considering this below as a build failure? 

The reason of the error is that the jstl jar cannot be found. This jar
is defined as a dependent jar in the GOM descriptor. Shouldn't Gumpy
verify if the dependent jars can be found?

It may have to do with the fact that I moved yesterday the  that
was inside the  tag. It is now outside the  tag. That was to
work around another Gumpy bug
(http://nagoya.apache.org/jira/browse/GUMP-46).

Any idea?

Thanks
-Vincent

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 03 April 2004 07:00
> To: [EMAIL PROTECTED]
> Subject: [EMAIL PROTECTED]: jakarta-cactus/jakarta-cactus-sample-servlet-13
> failed
> 
> To whom it may engage...
> 
> This is an automated request, but not an unsolicited one. For help
> understanding the request please visit
> http://gump.apache.org/nagged.html,
> and/or contact [EMAIL PROTECTED]
> 
> Project jakarta-cactus-sample-servlet-13 has an issue affecting its
> community integration. This issue affects 2 projects, and has been
> outstanding for 3 runs. The current state is 'Failed', for reason
'Build
> Failed'
> 
> Full details are available at:
http://lsd.student.utwente.nl/gump/jakarta-
> cactus/jakarta-cactus-sample-servlet-13.html, however some snippets
> follow:
> 
> -  -  -  -  - -- --  G U M P
> 
> Gump provided these annotations:
> 
>  - Info - Sole jar [bin] identifier set to project name
>  - Info - Dependency on commons-httpclient-2.0-branch exists, no need
to
> add for property commons.httpclient.jar.
>  - Info - Dependency on aspectj exists, no need to add for property
> aspectjrt.jar.
>  - Info - Dependency on jakarta-cactus-integration-ant-13 exists, no
need
> to add for property cactus.ant.jar.
>  - Info - Dependency on jstl-jsp-12 exists, no need to add for
property
> jstl.jar.
>  - Info - Dependency on jstl-jsp-12 exists, no need to add for
property
> standard.jar.
>  - Info - Dependency on jakarta-tomcat-4.0 exists, no need to add for
> property cactus.home.tomcat4x.
>  - Info - Made directory [/data3/gump/jakarta-
> cactus/samples/servlet/target-13/test/classes/java]
>  - Info - Made directory [/data3/gump/jakarta-
> cactus/samples/servlet/target-13/test/classes/cactus]
>  - Info - Enable "verbose" output, due to 2 previous error(s).
>  - Info - Failed with reason build failed
>  - Info - Enable "debug" output, due to build failure.
> 
> 
> -  -  -  -  - -- --  G U M P
> Gump performed this work:
> 
>
http://lsd.student.utwente.nl/gump/jakarta-cactus/gump_work/build_jakart
a-
> cactus_jakarta-cactus-sample-servlet-13.html
> Work Name: build_jakarta-cactus_jakarta-cactus-sample-servlet-13
(Type:
> Build)
> State: Failed
> Elapsed: 0 hours, 0 minutes, 4 seconds
> Command Line: java -Xbootclasspath/p:/data3/gump/xml-
>
xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xml
-
> apis.jar org.apache.tools.ant.Main -verbose
-Dgump.merge=/data3/gump/gump-
> install/work/merge.xml -Dbuild.sysclasspath=only -
> Dlog4j.jar=/data3/gump/logging-log4j/log4j-20040403.jar -
> Djunit.jar=/data3/gump/dist/junit/junit.jar -
> Dhttpunit.jar=/data3/gump/httpunit/lib/httpunit.jar -
> Djstl.jar=standard/standard/lib/jstl.jar -
> Dcommons.logging.jar=/data3/gump/jakarta-commons/logging/dist/commons-
> logging.jar -Dnekohtml.jar=/data3/gump/opt/nekohtml-0.9.2/nekohtml.jar
-
> Dcommons.httpclient.jar=/data3/gump/commons-httpclient-20-
> branch/dist/commons-httpclient-2.0-20040403.jar -Dcactus.port=8082 -
> Dstandard.jar=standard/standard/lib/standard.jar -
> Dcactus.home.tomcat4x=/data3/gump/jakarta-tomcat-4.0/dist -
> Dcactus.ant.jar=/data3/gump/jakarta-cactus/integration/ant/dist-
> 13/lib/cactus-ant-20040403.jar -Dservlet.jar=/data3/gump/jakarta-
> servletapi-4/lib/servlet.jar -Dproject.version=20040403 -
> Daspectjrt.jar=/data3/gump/opt/aspectj1.1/lib/aspectjrt.jar -
> Dcactus.jar=/data3/gump/jakarta-cactus/framework/dist-13/lib/cactus-
> 20040403.jar -f samples/servlet/build.xml dist
> [Working Directory: /data3/gump/jakarta-cactus]
> -
>  [echo]   commons.httpclient.jar =
[/data3/gump/commons-httpclient-20-
> branch/dist/commons-httpclient-2.0-20040403.jar]
>  [echo]   commons.logging.jar = [/data3/gump/jakarta-
> commons/logging/dist/commons-logging.jar]
>  [echo]   httpunit.jar = [/data3/gump/httpunit/lib/httpunit.jar]
>  [echo]   servlet.jar = [/data3/gump/jakarta-servletapi-
> 4/lib/servlet.jar]
>  [echo]   junit.jar = [/data3/gump/dist/junit/junit.jar]
>  [echo]   log4j.jar =
[/data3/gump/logging-log4j/log4j-20040

RE: FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-sample-servlet-13 failed

[Vincent Massol]

> -Original Message-
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
> Sent: 02 April 2004 16:29
> To: Gump code and data
> Subject: Re: FW: [EMAIL PROTECTED]:
jakarta-cactus/jakarta-cactus-sample-servlet-
> 13 failed
> 
> > > I've used the build log:
> > >
> > >  > >
cactus/gump_work/build_jakarta-cactus_jakarta-cactus-sample-servlet-
> > > 13.html>
> >
> > arg. Yes, it's very clear in there. I wonder why the link in the
Gump
> > email does not point to this file instead of the general one which
does
> > not provide the information...
> 
> Good question. It can, it will.

Cool!

> BTW: The general one does show it, but in amongst a lot of other
stuff.

Yeah, but you have to click on some links. The information is not
directly in the page (it wasn't for the problem I had on Cactus).

Thanks
-Vincent


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

RE: FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-sample-servlet-13 failed

[Vincent Massol]

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 02 April 2004 10:56
> To: [EMAIL PROTECTED]
> Subject: Re: FW: [EMAIL PROTECTED]:
jakarta-cactus/jakarta-cactus-sample-servlet-
> 13 failed
> 
> On Fri, 2 Apr 2004, Vincent Massol <[EMAIL PROTECTED]> wrote:
> 
> > I had looked at the web site but I could not find this
> > information. I looked at
> >
http://lsd.student.utwente.nl/gump/jakarta-cactus/jakarta-cactus-sample-
> > servlet-13.html. Is there another place to look at?
> 
> I've used the build log:
> 
> <http://lsd.student.utwente.nl/gump/jakarta-
> cactus/gump_work/build_jakarta-cactus_jakarta-cactus-sample-servlet-
> 13.html>

arg. Yes, it's very clear in there. I wonder why the link in the Gump
email does not point to this file instead of the general one which does
not provide the information...

> 
> and it contains the value of the CLASSPATH env variable.
> 
> >> > It seems like an Ant bug to me but I'm not sure.
> >>
> >> Why Ant?
> >
> > Hehe... I needed a culprit... :-)
> 
> And you probably catch my attention more easily if you blame Ant ;-)

:-)

> 
> > Ok done.
> 
> I think you need reference="jar" in the  elements as well.

Ok added. Thanks for spotting this (I didn't know about it).

> 
> > Any idea if/when Gumpy will be fixed to support this? Should I open
> > a JIRA bug for Gumpy on this?
> 
> JIRA would be a good idea.

http://nagoya.apache.org/jira/browse/GUMP-46

Thanks
-Vincent


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

RE: FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-sample-servlet-13 failed

[Vincent Massol]

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 02 April 2004 09:09
> To: [EMAIL PROTECTED]
> Subject: Re: FW: [EMAIL PROTECTED]:
jakarta-cactus/jakarta-cactus-sample-servlet-
> 13 failed
> 
> On Thu, 1 Apr 2004, Vincent Massol <[EMAIL PROTECTED]> wrote:
> 
> > Does anyone have an idea what the error below is about?
> 
> Yes, look at the website.  Several of the JSTL tag implementation
> classes haven't been found and in fact they are not inside jstl.jar
> which is on the CLASSPATH.  They are in standard.jar which is not on
> the CLASSPATH.

I had looked at the web site but I could not find this information. I
looked at
http://lsd.student.utwente.nl/gump/jakarta-cactus/jakarta-cactus-sample-
servlet-13.html. Is there another place to look at? Or what should I be
looking for on that page?

> 
> > It seems like an Ant bug to me but I'm not sure.
> 
> Why Ant?  

Hehe... I needed a culprit... :-) More seriously, I was led to this
(wrong) conclusion by the stack trace:

build.xml:180: Compile failed; see the compiler error output for
details.
at
org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHe
lper.java:536)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:383)
[...]

> Looks more like either the descriptor or Gump.  Let's see
> 
> 
>   ...
>   
>id="standard"/>
>   ...
> 
> 
> looks OK in order to have both jars on the CLASSPATH, so there may be
> a problem with the logic that adds the dependencies (it sees that
> there already is a dependency but doesn't recognize that you are
> asking for a different id this time).
> 
> I suggest that you replace the //ant/depend tags here with plain
> property tags and add an explicit  tag outside of .

Ok done. Any idea if/when Gumpy will be fixed to support this? Should I
open a JIRA bug for Gumpy on this?

Thanks Stefan
-Vincent


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

[repost] FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-sample-servlet-13 failed

[Vincent Massol]

Hi,

Does anyone have an idea what the error below is about? It seems like an
Ant bug to me but I'm not sure. In any case it works fine on my local
build on 2 different machines.

Thanks
-Vincent

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 01 April 2004 06:54
> To: [EMAIL PROTECTED]
> Subject: [EMAIL PROTECTED]: jakarta-cactus/jakarta-cactus-sample-servlet-13
> failed
> 

[snip]

> Work Name: build_jakarta-cactus_jakarta-cactus-sample-servlet-13
(Type:
> Build)
> State: Failed
> Elapsed: 0 hours, 0 minutes, 45 seconds
> Command Line: java -Xbootclasspath/p:/data3/gump/xml-
>
xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xml
-
> apis.jar org.apache.tools.ant.Main -verbose
-Dgump.merge=/data3/gump/gump-
> install/work/merge.xml -Dbuild.sysclasspath=only -
> Dlog4j.jar=/data3/gump/logging-log4j/log4j-20040401.jar -
> Djunit.jar=/data3/gump/dist/junit/junit.jar -
> Dhttpunit.jar=/data3/gump/httpunit/lib/httpunit.jar -
> Djstl.jar=/data3/gump/jstl-jsp-12/standard/standard/lib/jstl.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/commons-httpclient-20-
> branch/dist/commons-httpclient-2.0-20040401.jar -Dcactus.port=8082 -
>
Dstandard.jar=/data3/gump/jstl-jsp-12/standard/standard/lib/standard.jar
-
> Dcactus.home.tomcat4x=/data3/gump/jakarta-tomcat-4.0/dist -
> Dcactus.ant.jar=/data3/gump/jakarta-cactus/integration/ant/dist-
> 13/lib/cactus-ant-20040401.jar -Dservlet.jar=/data3/gump/jakarta-
> servletapi-4/lib/servlet.jar -Dproject.version=20040401 -
> Daspectjrt.jar=/data3/gump/opt/aspectj1.1/lib/aspectjrt.jar -
> Dcactus.jar=/data3/gump/jakarta-cactus/framework/dist-13/lib/cactus-
> 20040401.jar -f samples/servlet/build.xml dist
> [Working Directory: /data3/gump/jakarta-cactus]
> -
> [javac] 51 errors
>   [ant] Exiting /data3/gump/jakarta-cactus/samples/servlet/target-
> 13/sample/build.xml.
> 
> BUILD FAILED
> /data3/gump/jakarta-cactus/samples/servlet/build.xml:330: The
following
> error occurred while executing this line:
>
/data3/gump/jakarta-cactus/samples/servlet/target-13/sample/build.xml:18
0:
> Compile failed; see the compiler error output for details.
>   at
>
org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHe
lp
> er.java:536)
>   at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:383)
>   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268)
>   at org.apache.tools.ant.Task.perform(Task.java:363)
>   at org.apache.tools.ant.Target.execute(Target.java:301)
>   at org.apache.tools.ant.Target.performTasks(Target.java:328)
>   at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
>   at
org.apache.tools.ant.Project.executeTargets(Project.java:1062)
>   at org.apache.tools.ant.Main.runBuild(Main.java:667)
>   at org.apache.tools.ant.Main.startAnt(Main.java:187)
>   at org.apache.tools.ant.Main.start(Main.java:151)
>   at org.apache.tools.ant.Main.main(Main.java:234)
> Caused by: /data3/gump/jakarta-cactus/samples/servlet/target-
> 13/sample/build.xml:180: Compile failed; see the compiler error output
for
> details.
>   at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:938)
>   at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758)
>   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268)
>   at org.apache.tools.ant.Task.perform(Task.java:363)
>   at org.apache.tools.ant.Target.execute(Target.java:301)
>   at org.apache.tools.ant.Target.performTasks(Target.java:328)
>   at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
>   at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:381)
>   ... 10 more
> --- Nested Exception ---
>
/data3/gump/jakarta-cactus/samples/servlet/target-13/sample/build.xml:18
0:
> Compile failed; see the compiler error output for details.
>   at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:938)
>   at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758)
>   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268)
>   at org.apache.tools.ant.Task.perform(Task.java:363)
>   at org.apache.tools.ant.Target.execute(Target.java:301)
>   at org.apache.tools.ant.Target.performTasks(Target.java:328)
>   at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
>   at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:381)
>   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268)
>   at org.a

FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-sample-servlet-13 failed

[Vincent Massol]

Hi,

Does anyone have an idea what the error below is about? It seems like an
Ant bug to me but I'm not sure.

Thanks
-Vincent

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 01 April 2004 06:54
> To: [EMAIL PROTECTED]
> Subject: [EMAIL PROTECTED]: jakarta-cactus/jakarta-cactus-sample-servlet-13
> failed
> 

[snip]

> Work Name: build_jakarta-cactus_jakarta-cactus-sample-servlet-13
(Type:
> Build)
> State: Failed
> Elapsed: 0 hours, 0 minutes, 45 seconds
> Command Line: java -Xbootclasspath/p:/data3/gump/xml-
>
xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xml
-
> apis.jar org.apache.tools.ant.Main -verbose
-Dgump.merge=/data3/gump/gump-
> install/work/merge.xml -Dbuild.sysclasspath=only -
> Dlog4j.jar=/data3/gump/logging-log4j/log4j-20040401.jar -
> Djunit.jar=/data3/gump/dist/junit/junit.jar -
> Dhttpunit.jar=/data3/gump/httpunit/lib/httpunit.jar -
> Djstl.jar=/data3/gump/jstl-jsp-12/standard/standard/lib/jstl.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/commons-httpclient-20-
> branch/dist/commons-httpclient-2.0-20040401.jar -Dcactus.port=8082 -
>
Dstandard.jar=/data3/gump/jstl-jsp-12/standard/standard/lib/standard.jar
-
> Dcactus.home.tomcat4x=/data3/gump/jakarta-tomcat-4.0/dist -
> Dcactus.ant.jar=/data3/gump/jakarta-cactus/integration/ant/dist-
> 13/lib/cactus-ant-20040401.jar -Dservlet.jar=/data3/gump/jakarta-
> servletapi-4/lib/servlet.jar -Dproject.version=20040401 -
> Daspectjrt.jar=/data3/gump/opt/aspectj1.1/lib/aspectjrt.jar -
> Dcactus.jar=/data3/gump/jakarta-cactus/framework/dist-13/lib/cactus-
> 20040401.jar -f samples/servlet/build.xml dist
> [Working Directory: /data3/gump/jakarta-cactus]
> -
> [javac] 51 errors
>   [ant] Exiting /data3/gump/jakarta-cactus/samples/servlet/target-
> 13/sample/build.xml.
> 
> BUILD FAILED
> /data3/gump/jakarta-cactus/samples/servlet/build.xml:330: The
following
> error occurred while executing this line:
>
/data3/gump/jakarta-cactus/samples/servlet/target-13/sample/build.xml:18
0:
> Compile failed; see the compiler error output for details.
>   at
>
org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHe
lp
> er.java:536)
>   at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:383)
>   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268)
>   at org.apache.tools.ant.Task.perform(Task.java:363)
>   at org.apache.tools.ant.Target.execute(Target.java:301)
>   at org.apache.tools.ant.Target.performTasks(Target.java:328)
>   at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
>   at
org.apache.tools.ant.Project.executeTargets(Project.java:1062)
>   at org.apache.tools.ant.Main.runBuild(Main.java:667)
>   at org.apache.tools.ant.Main.startAnt(Main.java:187)
>   at org.apache.tools.ant.Main.start(Main.java:151)
>   at org.apache.tools.ant.Main.main(Main.java:234)
> Caused by: /data3/gump/jakarta-cactus/samples/servlet/target-
> 13/sample/build.xml:180: Compile failed; see the compiler error output
for
> details.
>   at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:938)
>   at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758)
>   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268)
>   at org.apache.tools.ant.Task.perform(Task.java:363)
>   at org.apache.tools.ant.Target.execute(Target.java:301)
>   at org.apache.tools.ant.Target.performTasks(Target.java:328)
>   at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
>   at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:381)
>   ... 10 more
> --- Nested Exception ---
>
/data3/gump/jakarta-cactus/samples/servlet/target-13/sample/build.xml:18
0:
> Compile failed; see the compiler error output for details.
>   at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:938)
>   at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758)
>   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268)
>   at org.apache.tools.ant.Task.perform(Task.java:363)
>   at org.apache.tools.ant.Target.execute(Target.java:301)
>   at org.apache.tools.ant.Target.performTasks(Target.java:328)
>   at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
>   at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:381)
>   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268)
>   at org.apache.tools.ant.Task.perform(Task.java:363)
>   at org.

RE: Something wrong today with Gumpy?

[Vincent Massol]

Or is it because of the change to Gumpy (inherit_none)?

Thanks
-Vincent

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 19 March 2004 08:26
> To: [EMAIL PROTECTED]
> Subject: Something wrong today with Gumpy?
> 
> Anything wrong? It seems the servletapi jar is either
corrupted/invalid
> or not found.
> 
> Thanks
> -Vincent


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

RE: FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-framework-12 failed

[Vincent Massol]

Hi Adam,

The problem is the the following declaration:



should only include in the CP the jars declared by the  tag in the
httpunit project. However it seems it is importing all jars in the CP.

For example, with :

  
com.meterware









  

it should only add lib/httpunit.jar in the CP. It seems it is adding
jakarta-servletapi-4 and the others, which is wrong.

Thanks
-Vincent


> -Original Message-
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
> Sent: 18 March 2004 17:30
> To: [EMAIL PROTECTED]
> Subject: Re: FW: [EMAIL PROTECTED]:
jakarta-cactus/jakarta-cactus-framework-12
> failed
> 
> Stefan,
> 
> Could you try to explain what it is doing wrong (in simple terms ;-)
and
> what it ought do & I'll try to find time to fix it. I am away
(training)
> next week, and only online some evenings, and I want to get Gumpy
stable
> for
> while I go. The documentation publication & this seem the key things.
I
> have
> family coming over the pond tonight, to stay, so can't even say I'll
get
> much time between now and when I go away.
> 
> regards,
> 
> Adam
> - Original Message -
> From: "Stefan Bodewig" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, March 18, 2004 1:30 AM
> Subject: Re: FW: [EMAIL PROTECTED]:
jakarta-cactus/jakarta-cactus-framework-12
> failed
> 
> 
> > On Thu, 18 Mar 2004, Vincent Massol <[EMAIL PROTECTED]> wrote:
> >
> > > I don't understand why it would inherit all dependencies defines
in
> > > httpunit.
> >
> > It shouldn't.  It looks like a problem in Gumpy
> > <http://gump.covalent.net/log/jakarta-cactus-framework-12.html>.
> >
> > Stefan
> >
> >
-
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



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

RE: [RT] Source difference report between 2 gump build states

[Vincent Massol]

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 18 March 2004 09:10
> To: [EMAIL PROTECTED]
> Subject: RE: [RT] Source difference report between 2 gump build states
> 
> 
> 
> > -Original Message-
> > From: Vincent Massol [mailto:[EMAIL PROTECTED]
> > Sent: 15 March 2004 00:19
> > To: '[EMAIL PROTECTED]'
> > Subject: [RT] Source difference report between 2 gump build states
> >
> > Hi,
> >
> > I have posted this idea under the thread "[Cactus] Gump build
failure:
> > Culprit found!" but I'm reposting it here as I'm not sure everyone
> will
> > read the cactus stuff and I think this is an "interesting idea"...
:-)
> >
> > Idea: It would be nice if Gump would be able to do a source diff of
a
> > project dependencies, and this between a successful run and a failed
> one.
> > That would be s nice! A report page showing all the differences.
> There
> > can't be that much in 1 day, right?
> 
> In this report, I think we should also include the diffs from the Gump
> project files (project/*.xml) too as they are often a cause of build
> failure.
> 

[snip]

Note: The reason I'm saying this is because it has just happened today
for the cactus build: A change in the project definition of httpunit has
broken the cactus build.

-Vincent


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

FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-framework-12 failed

[Vincent Massol]

Hi,

Ok. I've debugged the problem. It comes from the addition, yesterday of
the servletapi-4 to the httpunit project...

Cactus tries to guess with J2EE API version is being used by checking if
there is a Filter class in the j2ee.jar or servlet.jar jars:


  

  
  

  


The problem is that as Gump runs in classpath ignore mode the whole CP
is considered for this Filter search. And as httpunit has added
servletapi-4 to its CP, Cactus somehow inherits it...

Here's Cactus definition:



  

  
  
  
  
  
  
  


  





I don't understand why it would inherit all dependencies defines in
httpunit. There's no inherit="true", and the httpunit project only
declares a single jar:



Any idea?

Thanks
-Vincent

> -----Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 18 March 2004 06:52
> To: [EMAIL PROTECTED]
> Subject: [EMAIL PROTECTED]: jakarta-cactus/jakarta-cactus-framework-12 failed
> 
> To whom it may engage...
> 
> This is an automated request, but not an unsolicited one. For help
> understanding the request please visit
> http://gump.apache.org/nagged.html,
> and/or contact [EMAIL PROTECTED]
> 
> Project jakarta-cactus-framework-12 has an issue affecting its
community
> integration. This issue affects 1 projects. The current state is
'Failed',
> for reason 'Build Failed'
> 
> Full details are available at:
http://lsd.student.utwente.nl/gump/jakarta-
> cactus/jakarta-cactus-framework-12.html, however some snippets follow:
> 
> -  -  -  -  - -- --  G U M P
> 
> Gump provided these annotations:
> 
>  - Info - Sole jar [/data3/gump/jakarta-cactus/framework/dist-
> 12/lib/cactus-20040318.jar] identifier set to project name
>  - Info - Dependency on aspectj exists, no need to add for property
> aspectjrt.jar.
>  - Error - Failed with reason build failed
> 
> 
> -  -  -  -  - -- --  G U M P
> Gump performed this work:
> 
> Work Name: build_jakarta-cactus_jakarta-cactus-framework-12 (Type:
Build)
> State: Failed
> Elapsed: 0 hours, 0 minutes, 18 seconds
> Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -
> Xbootclasspath/p:/data3/gump/xml-
> xerces2/java/build/xercesImpl.jar:/data3/gump/xml-
> xerces2/java/build/xmlParserAPIs.jar org.apache.tools.ant.Main -
> Dgump.merge=/data3/gump/gump-install/work/merge.xml -
> Dbuild.sysclasspath=only -Dlog4j.jar=/data3/gump/logging-log4j/log4j-
> 20040318.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 -Dproject.version=20040318 -
> Dcommons.httpclient.jar=/data3/gump/commons-httpclient-20-
> branch/dist/commons-httpclient-2.0-20040318.jar -
> Dj2ee.jar=/data3/gump/jakarta-servletapi/dist/lib/servlet.jar -
> Daspectjrt.jar=/data3/gump/opt/aspectj1.1/lib/aspectjrt.jar -f
> framework/build.xml dist
> [Working Directory: /data3/gump/jakarta-cactus]
> -
>  [iajc] 
>  [iajc] /data3/gump/jakarta-
>
cactus/framework/src/java/j2ee13/org/apache/cactus/server/FilterConfigWr
ap
> per.java:42 FilterConfig cannot be resolved (or is not a valid type)
for
> the field FilterConfigWrapper.originalConfig
>  [iajc] private FilterConfig originalConfig;
>  [iajc] 
>  [iajc] /data3/gump/jakarta-
>
cactus/framework/src/java/j2ee13/org/apache/cactus/server/FilterConfigWr
ap
> per.java:57 FilterConfig cannot be resolved (or is not a valid type)
for
> the argument theOriginalConfig of the method FilterConfigWrapper
>  [iajc] public FilterConfigWrapper(FilterConfig theOriginalConfig)
>  [iajc]
>  [iajc] /data3/gump/jakarta-
>
cactus/framework/src/java/j2ee13/org/apache/cactus/server/FilterConfigWr
ap
> per.java:59 originalConfig cannot be resolved or is not a field
>  [iajc] this.originalConfig = theOriginalConfig;
>  [iajc] ^^^
>  [iajc] /data3/gump/jakarta-
>
cactus/framework/src/java/j2ee13/org/apache/cactus/server/FilterConfigWr
ap
> per.java:98 originalConfig cannot be resolved or is not a field
>  [iajc] return this.originalConfig.getFilterName();
>  [iajc]^^^
>  [iajc] /data3/gump/jakarta-
>
cactus/framework/src/java/j2ee13/org/apache/cactus/server/FilterConfigWr
ap
> per.java:107 originalConfig cannot be resolved or is not a field
>  [iajc] this.originalConfig.getServletContext());

RE: [RT] Source difference report between 2 gump build states

[Vincent Massol]

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 15 March 2004 00:19
> To: '[EMAIL PROTECTED]'
> Subject: [RT] Source difference report between 2 gump build states
> 
> Hi,
> 
> I have posted this idea under the thread "[Cactus] Gump build failure:
> Culprit found!" but I'm reposting it here as I'm not sure everyone
will
> read the cactus stuff and I think this is an "interesting idea"... :-)
> 
> Idea: It would be nice if Gump would be able to do a source diff of a
> project dependencies, and this between a successful run and a failed
one.
> That would be s nice! A report page showing all the differences.
There
> can't be that much in 1 day, right?

In this report, I think we should also include the diffs from the Gump
project files (project/*.xml) too as they are often a cause of build
failure.

-Vincent

> 
> Having this should save countless hours of debugging trying to figure
out
> what is wrong.
> 
> Thoughts?
> 
> Thanks
> -Vincent


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

RE: [Cactus] Gump build failure: Culprit found!

[Vincent Massol]

> -Original Message-
> From: Nick Chalko [mailto:[EMAIL PROTECTED]
> Sent: 15 March 2004 23:03
> To: Gump code and data
> Subject: Re: [Cactus] Gump build failure: Culprit found!
> 
> Updates made
> Vincent Massol wrote:
> 
> >>-Original Message-
> >>From: Nick Chalko [mailto:[EMAIL PROTECTED]
> >>Sent: 15 March 2004 22:24
> >>To: Gump code and data
> >>Subject: Re: [Cactus] Gump build failure: Culprit found!
> >>
> >>I am preparing to blog this at
> >>http://gump.chalko.com/gb/blog/Issues/?smm=y&permalink=Cactus-
> >>CommonsHttpclient.txt&preview=true
> >>
> >>Please take moment and read to make sure I am staying friendly to
both
> >>projects.
> >>
> >>
> >>
> >
> >2/ httpclient HEAD (i.e. v3.x) is not going to be backward compatible
> >with v2.x and thus several APIs will be broken. The question has been
> >asked on Cactus dev mailing list as to whether we stay on the 2.x
branch
> >or follow 3.x.
> >
> >
> Do you have a link to the actual email thread.  I don't see it in the
> archive?

Just sent it about 1 hour ago. You should be able to see it in a few
hours on
http://www.mail-archive.com/cactus-dev%40jakarta.apache.org/maillist.htm
l

Thread name is: "[VOTE] Following HttpClient 3.x or staying with
HttpClient 2.x?"

Thanks
-Vincent


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

RE: [Cactus] Gump build failure: Culprit found!

[Vincent Massol]

> -Original Message-
> From: Nick Chalko [mailto:[EMAIL PROTECTED]
> Sent: 15 March 2004 22:24
> To: Gump code and data
> Subject: Re: [Cactus] Gump build failure: Culprit found!
> 
> I am preparing to blog this at
> http://gump.chalko.com/gb/blog/Issues/?smm=y&permalink=Cactus-
> CommonsHttpclient.txt&preview=true
> 
> Please take moment and read to make sure I am staying friendly to both
> projects.
> 

Looks ok to me. Here's some more information. After talking to Oleg from
HttpClient it appears that:

1/ a regression bug has been recently introduced and Oleg is going to
fix it. Without this error the Cactus build should work fine. Thus a new
victory for Gump for pointing this out.

2/ httpclient HEAD (i.e. v3.x) is not going to be backward compatible
with v2.x and thus several APIs will be broken. The question has been
asked on Cactus dev mailing list as to whether we stay on the 2.x branch
or follow 3.x.

> I don't see this failure right now,  can some one point me to the
build
> failure.

http://lsd.student.utwente.nl/gump/jakarta-cactus/jakarta-cactus-sample-
servlet-12.html

Thanks
-Vincent


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

RE: [Request] Make gump build directories browsable

[Vincent Massol]

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 15 March 2004 10:58
> To: [EMAIL PROTECTED]
> Subject: Re: [Request] Make gump build directories browsable
> 
> On Mon, 15 Mar 2004, Vincent Massol <[EMAIL PROTECTED]> wrote:
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> >>
> >> On Sun, 14 Mar 2004, Vincent Massol <[EMAIL PROTECTED]> wrote:
> >>
> >> > Would it be possible to make the gump build directories
> >> > browsable.
> >>
> >> Hard to do without "distributing" the build results at the same
> >> time.
> >
> > I don't understand. What I am suggesting was to make the /data3/gump
> > directory visible under some htdocs (readonly).
> 
> Which would imply that I could download the created jars from there,
> even if they are not legal to distribute at all.  Or just not
> redistributable from Apache infrastructure due to local policies.

Is that really called "redistributing"? Also, what about this page:
http://gump.covalent.net/jars/latest/? It does the same thing, no?

In any case, Gump could simply not build non-redistributable jars (it
could simply have them installed as packages).

It seems to me that if Apache has some local policies preventing
distributing some jars then these jars should not be built *at all* on
Apache infrastructure.

Thanks
-Vincent


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

RE: [Request] Make gump build directories browsable

[Vincent Massol]

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 15 March 2004 10:20
> To: [EMAIL PROTECTED]
> Subject: Re: [Request] Make gump build directories browsable
> 
> On Sun, 14 Mar 2004, Vincent Massol <[EMAIL PROTECTED]> wrote:
> 
> > Would it be possible to make the gump build directories
> > browsable.
> 
> Hard to do without "distributing" the build results at the same time.

I don't understand. What I am suggesting was to make the /data3/gump
directory visible under some htdocs (readonly).

Thanks
-Vincent

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



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

FW: [Cactus] Gump build failures for the past 2 weeks

[Vincent Massol]

Hi gumpmeisters,

How do we handle this?

Do we force Gumpy to use the 2.0 branch from httpclient?

Thanks
-Vincent

> -Original Message-
> From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
> Sent: 15 March 2004 08:59
> To: Commons HttpClient Project
> Subject: RE: [Cactus] Gump build failures for the past 2 weeks
> 
> Vincent,
> As Roland pointed out, your code does not use HttpClient's native
> authentication mechanism. As a result the custom-built authentication
> header appears to have been overwritten. This is not an intended
> behaviour for which I'll provide a fix. This said, I do recommend that
> you use HttpClient authentication mechanism in the future.
> 
> As to 2.0 API compatibility, I have already earned myself a few
> 'non-friends' by my stance on this issue: next release (which was
> recently upgraded from 2.1 to 3.0) will not be fully 2.0 API
compatible.
> Too many things are too badly broken in 2.0 to make any sort of
backward
> compatibility meaningful.
> 
> I strongly urge all the projects that require 2.0 compatibility to
stick
> to the 2.0 branch until 3.0 makes a first beta. Once we have the new
API
> agreed, we can think of a migration path which may involve a (1)
> compatibility layer, (2) manual code conversion, (3) automatic code
> conversion, (4) some combination of 1, 2, and 3.
> 
> Oleg
> 
> 
> On Mon, 2004-03-15 at 08:09, Vincent Massol wrote:
> > Hi Oleg,
> >
> > Thanks very much for your help. Here's the code that adds basic
> > authentication (by adding authorization HTTP header):
> >
> > public void configure(WebRequest theRequest,
> > Configuration theConfiguration)
> > {
> > // According to HTTP 1.0 Spec:
> > // basic-credentials = "Basic" SP basic-cookie
> > // basic-cookie  =  > // except not limited to 76 char/line>
> > // userid-password   = [ token ] ":" *TEXT
> > //
> > // see setName and setPassword for details of token and TEXT
> > String basicCookie = getName() + ":" + getPassword();
> > String basicCredentials = "Basic "
> > + new String(base64Encode(basicCookie.getBytes()));
> >
> > theRequest.addHeader("Authorization", basicCredentials);
> > }
> >
> > Then, we use HttpClient to send the request:
> >
> > [...]
> > // Add the cookies
> > HttpState state = CookieUtil.createHttpState(theRequest,
url);
> >
> > // Open the connection and get the result
> > HttpClient client = new HttpClient();
> > HostConfiguration hostConfiguration = new
HostConfiguration();
> > hostConfiguration.setHost(url.getHost(), url.getPort(),
> > Protocol.getProtocol(url.getProtocol()));
> > client.setState(state);
> > client.executeMethod(hostConfiguration, this.method);
> >
> > // Wrap the HttpClient method in a
java.net.HttpURLConnection
> > object
> > return new
org.apache.commons.httpclient.util.HttpURLConnection(
> > this.method, url);
> >
> >
> > Let me know if you need more details to understand it.
> >
> > Do I have to assume that these changes in httpclient are not
> > backward-compatible and there's no compatibility layer, right? Thus
if
> > Cactus moves to 2.1-dev, we'll need to deliver cactus with
httpclient
> > 2.1-dev bundled. Thus there is a risk that httpclient 2.1-dev is not
> > stable at that point (we'll be releasing a new version of Cactus
next
> > week). Of course, we could build a compatibility layer in Cactus
itself
> > to support both httpclient 2.0 and 2.1-dev. Frankly, I think it
makes
> > more sense for httpclient to do this. It could get dropped once 2.1
> > final is out. It would really be good if 2.1 was backward compatible
(it
> > could of course introduce new APIs). Lots of persons are using
> > httpclient and breaking an API is not a very good migration path...
:-)
> >
> > What do you suggest?
> >
> > Thanks
> > -Vincent
> >
> > > -Original Message-
> > > From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
> > > Sent: 15 March 2004 00:52
> > > To: Commons HttpClient Project
> > > Subject: RE: [Cactus] Gump build failures for the past 2 weeks
> > >
> > > Vincent,
> > > >From the cursory examination the problem appears to have been
caused
> > by
> > > HttpClient not findin

[Cactus] Gump build failures for the past 2 weeks

[Vincent Massol]

Hi guys,

I've finally tracked down the Cactus gump build problem we've been
having for the past 2 weeks. It appears to be caused by some change in
commons-httpclient.

The build is working fine with version 2.0 and failing on some
authentication code with a commons-httpclient built from CVS HEAD.

I'm attaching the cactus log file (which contains httpclient logs) in
case it helps.

Any idea what can have changed?

Thanks
-Vincent

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

[RT] Source difference report between 2 gump build states

[Vincent Massol]

Hi,

I have posted this idea under the thread "[Cactus] Gump build failure:
Culprit found!" but I'm reposting it here as I'm not sure everyone will
read the cactus stuff and I think this is an "interesting idea"... :-)

Idea: It would be nice if Gump would be able to do a source diff of a
project dependencies, and this between a successful run and a failed
one. That would be s nice! A report page showing all the
differences. There can't be that much in 1 day, right?

Having this should save countless hours of debugging trying to figure
out what is wrong.

Thoughts?

Thanks
-Vincent


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

[Cactus] Gump build failure: Culprit found!

[Vincent Massol]

Hi guys,

I should have known better... After a few hours of debugging and thanks
to Leo for giving me access to LSD, I have found the culprit. The hunt
is over!

The culprit is: commons-httpclient

It works fine with version 2.0 of commons-httpclient but not with the
latest version from HEAD. Now, the hard part, is trying to understand
why httpclient has changed some API. Then the Cactus project will need
to decide whether it has to use the new way (thus forcing users to use
httpclient from HEAD) or ask nicely some Gump admin to install
commons-httpclient 2.0 and have the Cactus build depend on that.


You know what would be nice? That Gump would be able to do a source diff
of a project dependencies, and this between a successful run and a
failed one. That would be s nice. A report page showing all the
differences. There can't be that much in 1 day, right?

Having this would have probably saved me about 3-4 hours.


What do you think?

Thanks
-Vincent


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

RE: Gump Ant command line available?

[Vincent Massol]

> -Original Message-
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
> Sent: 14 March 2004 22:29
> To: Gump code and data
> Subject: Re: Gump Ant command line available?
> 
> 
> > Hey, that's very cool! I didn't know it existed...
> 
> Yup, we are working to make Gumpy more transparent, but as you've
noted,
> remote debugging is still too hard.

One suggestion to improve the command line page: Do you think you could
make the classpath a text area zone. It's very difficult to copy-paste
it as it is.

> 
> BTW: The "build.clonevm" worries me, Stefan added it to Ant to allow
> forked
> VMs to look like the VM that forked them. I wonder if somehow this
could
> be
> troubling tomcat. Sadly this is hard coded into Gumpy right now.

I'll try with and without

Thanks
-Vincent

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



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

RE: Gump Ant command line available?

[Vincent Massol]

Hey, that's very cool! I didn't know it existed... 

Thanks
-Vincent

> -Original Message-
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
> Sent: 14 March 2004 22:12
> To: Gump code and data
> Subject: Re: Gump Ant command line available?
> 
> > I'm still trying to debug the Cactus gump build. I'd like to build
my
> > project locally using the Ant command line has run on the failed
> > project.
> >
> > Is that information available somewhere (i.e. is there a place I can
> > copy-paste it from)? That would be quite useful.
> 
>
http://lsd.student.utwente.nl/gump/jakarta-cactus/gump_work/build_jakart
a-
> cactus_jakarta-cactus-sample-servlet-12.html#Command+Line
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



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

Gump Ant command line available?

[Vincent Massol]

Hi,

I'm still trying to debug the Cactus gump build. I'd like to build my
project locally using the Ant command line has run on the failed
project.

Is that information available somewhere (i.e. is there a place I can
copy-paste it from)? That would be quite useful.

I cannot find it on
http://lsd.student.utwente.nl/gump/jakarta-cactus/jakarta-cactus-sample-
servlet-12.html

Thanks
-Vincent


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

RE: [Help] Help required to debug a cactus gump build!

[Vincent Massol]

Hi Adam,

> -Original Message-
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
> Sent: 14 March 2004 21:24
> To: Gump code and data
> Subject: Re: [Help] Help required to debug a cactus gump build!
> 
> > Could someone make available the jakarta-tomcat/ gumpy build
directory
> > somewhere (i.e. the /data3/gump/jakarta-tomcat/build/tomcat/ dir)?
> >
> > I need this to continue debugging
> >
http://lsd.student.utwente.nl/gump/jakarta-cactus/jakarta-cactus-sample-
> > servlet-12.html
> 
> Mind explaining why you need to see it? The only things passed to
cactus
> from tomcat ought be listed here:
> 
> 
> http://lsd.student.utwente.nl/gump/jakarta-tomcat/jakarta-
> tomcat.html#Outputs
> 
> Are you looking to poke inside the jars, or 
> 
> Just curious.

I'm trying to reduce the possible differences between my local run and
gump's one. I can see 3 differences:
- unix vs windows (I'm building on windows)
- tomcat set up
- ant command line

So far, I've eliminated the unix difference. Thanks to Leo I've also
just eliminated the tomcat one. The last part is to reproduce Ant's
command line so that I can run it manually. I'll be working on this now.

[snip]

Thanks
-Vincent


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

RE: [Request] Make gump build directories browsable

[Vincent Massol]

Thanks Stefano. I have been one of the first adopter of Gump (I have
even used it on a big project at work! :-)). I do not wish to depart.
However, in the past I had enough energy to keep fixing things even it
wasn't easy (like I had to install Gump on my machine, etc).
Unfortunately I have shifted my interest to some other areas and I don't
have much time to invest in learning Gump itself.

I do understand that the Gump community is working towards addressing
these issues so I'll be patient! :-)

Leo has kindly offered to create an account for me on his machine. I
think I'll take the offer so that I can try debugging the Cactus gump
build.

Thanks
-Vincent

> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
> Sent: 14 March 2004 18:01
> To: Gump code and data
> Subject: Re: [Request] Make gump build directories browsable
> 
> Vincent Massol wrote:
> 
> > Hi,
> >
> > Would it be possible to make the gump build directories browsable.
It's
> > just a pain to debug gump and find where the problem is. Making
these
> > directories visible will help a lot.
> >
> > 
> > I've been trying to debug a cactus gump build problem for a week now
> > with no success. Every time I have to rely on the good will on one
of
> > the gumpmeister to send me some files... I don't think this is how
it
> > should work. Also, my time is not indefinitely flexible. During the
week
> > and week end, I have some free time but it's not linear across the
days.
> > That is, if I get a slot of a few hours on Saturday, I'd like to use
it.
> > But I can't as I'm relying on others! As an example, I've asked for
> > files for the past 4 days and I still haven't received them...
> >
> > If it's happening I guess it's happening for other projects too.
> >
> > Honestly I'm failing to see the point of Gump now. I used to like it
but
> > it's too energy-consuming to fix something. I used to like it when
it
> > was publishing the Cactus web site automatically (Stefano seems to
be
> > saying it's impossible because of security issues but it *WAS* doing
it
> > in the past - Ask Sam). As a consequence, I've had to set up my own
> > continuous build at home... and thus I don't really need Gump
anymore as
> > my own build satisfies my needs and those of our community (yeah it
> > doesn't build against CVS HEAD of dependencies but it's ok. Whenever
> > there's a new release of a dependency I update it).
> > 
> >
> > Thoughts?
> 
> Vincent, before you depart please understand that gump is
transitioning
> and that we are very concerned in making it as simple as posible for
> people like you to keep your metadata in synch.
> 
> Now, is gump perfect? no! and by far!
> 
> It's not even running on ASF machines! so we can't give access to
> everybody to Leo's machine!
> 
> We are waiting for those machines to arrive and in the meanwhile we
are
> working on using moof.
> 
> as for gump publishing web site, if it did in the past, it was a big
> mistake and we are lucky we weren't hacked (probably because gump was
> not so visible).
> 
> As for not seeing the point in gump, well, we can't force people to
see
> the point, but we do care in making it as painless as possible.
> 
> If this is too painful for you, we can turn nagging off until we are
> ready, but I would prefer to help you out in solving the problem.
> 
> I just don't understand what the problem is so I can't help you.
> 
> --
> Stefano.



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

[Request] Make gump build directories browsable

[Vincent Massol]

Hi,

Would it be possible to make the gump build directories browsable. It's
just a pain to debug gump and find where the problem is. Making these
directories visible will help a lot.


I've been trying to debug a cactus gump build problem for a week now
with no success. Every time I have to rely on the good will on one of
the gumpmeister to send me some files... I don't think this is how it
should work. Also, my time is not indefinitely flexible. During the week
and week end, I have some free time but it's not linear across the days.
That is, if I get a slot of a few hours on Saturday, I'd like to use it.
But I can't as I'm relying on others! As an example, I've asked for
files for the past 4 days and I still haven't received them...

If it's happening I guess it's happening for other projects too. 

Honestly I'm failing to see the point of Gump now. I used to like it but
it's too energy-consuming to fix something. I used to like it when it
was publishing the Cactus web site automatically (Stefano seems to be
saying it's impossible because of security issues but it *WAS* doing it
in the past - Ask Sam). As a consequence, I've had to set up my own
continuous build at home... and thus I don't really need Gump anymore as
my own build satisfies my needs and those of our community (yeah it
doesn't build against CVS HEAD of dependencies but it's ok. Whenever
there's a new release of a dependency I update it).


Thoughts?

Thanks
-Vincent


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

[Help] Help required to debug a cactus gump build!

[Vincent Massol]

Hi,

Could someone make available the jakarta-tomcat/ gumpy build directory
somewhere (i.e. the /data3/gump/jakarta-tomcat/build/tomcat/ dir)?

I need this to continue debugging
http://lsd.student.utwente.nl/gump/jakarta-cactus/jakarta-cactus-sample-
servlet-12.html

Thanks!
-Vincent

Note1: that would be cool if the gump build directories were
automatically available under some htdocs.

Note2: I've been trying to debug this Cactus gump build issue for about
a week now. This is why Gump is not user-friendly: it's just too long
and too complex to fix something...


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

[Cactus] continuing the debugging

[Vincent Massol]

Hi,

Could someone make available the jakarta-tomcat/ gumpy build directory
somewhere (i.e. the /data3/gump/jakarta-tomcat/build/tomcat/ dir)?

I need this to continue debugging
http://lsd.student.utwente.nl/gump/jakarta-cactus/jakarta-cactus-sample-
servlet-12.html

Thanks!
-Vincent

Note: that would be cool if the gump build results were available under
some htdocs.


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

RE: [Cactus] commons-codec added to dependency jars?

[Vincent Massol]

> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
> Sent: 12 March 2004 21:09
> To: Gump code and data
> Subject: Re: [Cactus] commons-codec added to dependency jars?
> 
> Vincent Massol wrote:
> 
> 
> > The way I code is as follows:
> > 1/ make a change on my local machine
> > 2/ verify it works by running some kind of tests
> >
> > If I don't do 2/ then there is a high chance it will break something
and
> > I'll only know the following day.
> >
> > To do 2, there are 2 solutions I can see:
> > 1/ install gumpy locally but that's not very easy to do
> > 2/ have a kind of "self-service gumpy" that you can start on demand
> >
> > What do you think?
> 
> Interesting.
> 
> I never though that people would have a problem modifying the metadata
> files for fear of breaking gump.
> 
> But, I wonder, if your build is already broken, why are you afraid of
> breaking it?

In this specific case, it's not broken. It's a refactoring (replacing
the dependency on commons-code with some inherit on httpclient). The
problem is that I'm not a gumpy expert and I don't know if this change
is the correct one. Stefan, on the other hand, has had much more
experience and I'm sure he's more confident in the changes he's making
(even though, I'm sure he tries them on his machine from time to time
before or after committing the changes) :-)

More generally, if the build is broken and I make a change to fix it,
I'd like to be sure it fixes the build. Otherwise I'll have to wait till
the following morning, try something else, wait again, try something
else. I remember doing this in the past and it took me about 1 week or
more to get Gump working for Cactus (the Cactus build does quite a lot).


-Vincent


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

RE: [Cactus] commons-codec added to dependency jars?

[Vincent Massol]

Hi Stefano,

> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
> Sent: 12 March 2004 15:31
> To: Gump code and data
> Subject: Re: [Cactus] commons-codec added to dependency jars?

[snip]

> > 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...
> >
> > I think if you want to make Gump more popular (in the line of
thought of
> > the [RT] thread), this is one area to improve. A self-service Gump
or
> > something similar so that people can help modify descriptors and
verify
> > they still work. Otherwise the Gump committers will end up doing all
the
> > work...
> 
> Vincent, I'm actually very curious and insterested in your comment:
what
> are you afraid of breaking?

The way I code is as follows:
1/ make a change on my local machine
2/ verify it works by running some kind of tests

If I don't do 2/ then there is a high chance it will break something and
I'll only know the following day.

To do 2, there are 2 solutions I can see:
1/ install gumpy locally but that's not very easy to do
2/ have a kind of "self-service gumpy" that you can start on demand

What do you think?

Thanks
-Vincent


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

RE: How to debug a Gump build problem?

[Vincent Massol]

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
jakarta-tomcat/ build directory somewhere (i.e. the
/data3/gump/jakarta-tomcat/build/tomcat/ dir)?

I'd like to try to run the samples by pointing to this Tomcat install
and see what happens.

Thanks
-Vincent

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 11 March 2004 15:08
> To: 'Gump code and data'
> Subject: RE: How to debug a Gump build problem?
> 
> 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 13:14
> > To: [EMAIL PROTECTED]
> > Subject: Re: How to debug a Gump build problem?
> >
> > 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 /cactus-sample-servlet-
> >
>
cactified/ServletRedirectorSecure?Cactus_TestMethod=testBasicAuthenticat
> io
> >
>
n&Cactus_TestClass=org.apache.cactus.sample.servlet.unit.TestBasicAuthen
> ti
> > cation&Cactus_AutomaticSession=true&Cactus_Service=CALL_TEST
> > <- 401 Unauthorized\r\nWWW-Authenticate: Basic realm="myrealm"
> > -> GET /cactus-sample-servlet-
> > cactified/ServletRedirectorSecure?Cactus_Service=GET_RESULTS
> > <- 401 Unauthorized\r\nWWW-Authenticate: Basic realm="myrealm"
> > -> GET /cactus-sample-servlet-
> > cactified/ServletRedirector?Cactus_Service=RUN_TEST
> > <- 200 OK
> > -> GET /cactus-sample-servlet-
> > cactified/ServletRedirector?Cactus_Service=RUN_TEST
> > <- 200 OK
> >
> > To me it looks as if cactus never successfully authenticates and
fails
> > when it tries to collect the test results.
> >
> > So I've manually started Tomcat to see whether I could log in.  I
get
> > the login dialog box, use testuser/testpassword, accept a session-id
> > cookie and then I'm in.  If I then invoke GET_RESULTS I get
> >
> > 
> >
> > So manually things seem to work fine, but I don't see cactus even
> > trying to authenticate.
> >
> > Let me know if I can do more tests.
> >
> > Stefan
> >
> >
-
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



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

RE: How to debug a Gump build problem?

[Vincent Massol]

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 13:14
> To: [EMAIL PROTECTED]
> Subject: Re: How to debug a Gump build problem?
> 
> 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 /cactus-sample-servlet-
>
cactified/ServletRedirectorSecure?Cactus_TestMethod=testBasicAuthenticat
io
>
n&Cactus_TestClass=org.apache.cactus.sample.servlet.unit.TestBasicAuthen
ti
> cation&Cactus_AutomaticSession=true&Cactus_Service=CALL_TEST
> <- 401 Unauthorized\r\nWWW-Authenticate: Basic realm="myrealm"
> -> GET /cactus-sample-servlet-
> cactified/ServletRedirectorSecure?Cactus_Service=GET_RESULTS
> <- 401 Unauthorized\r\nWWW-Authenticate: Basic realm="myrealm"
> -> GET /cactus-sample-servlet-
> cactified/ServletRedirector?Cactus_Service=RUN_TEST
> <- 200 OK
> -> GET /cactus-sample-servlet-
> cactified/ServletRedirector?Cactus_Service=RUN_TEST
> <- 200 OK
> 
> To me it looks as if cactus never successfully authenticates and fails
> when it tries to collect the test results.
> 
> So I've manually started Tomcat to see whether I could log in.  I get
> the login dialog box, use testuser/testpassword, accept a session-id
> cookie and then I'm in.  If I then invoke GET_RESULTS I get
> 
> 
> 
> So manually things seem to work fine, but I don't see cactus even
> trying to authenticate.
> 
> Let me know if I can do more tests.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



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

RE: How to debug a Gump build problem?

[Vincent Massol]

Thanks Stefan. I've had a look but there's nothing wrong I can see
unfortunately... The Tomcat users file is there (it could have been the
cause).

Might be an OS thingie. I'll need to find some time to try it on a unix
system (which I don't have at home).

Thanks
-Vincent

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 11 March 2004 11:21
> To: [EMAIL PROTECTED]
> Subject: Re: How to debug a Gump build problem?
> 
> 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 additional commands, e-mail: [EMAIL PROTECTED]



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

[RT] Gumpy deploying websites?

[Vincent Massol]

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 night - for Apache projects who
configure this in their deployment descriptors). 

Note: I think related security issues can be solved without too much
problem (for example by allowing only to deploy to cvs.apache.org).

Thoughts?

Thanks
-Vincent
Wanna see JUnit in Action?
(http://manning.com/massol) 


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

RE: How to debug a Gump build problem?

[Vincent Massol]

> -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
> >
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 3.3.x).
> 
> Fails on my machine as well.
> 
> I wonder why jstl-jsp-12 builds for me but not on LSD, wait, it also
> fails on "traditional" Gump but the jar is created before the build
> fails and thus the depending projects can use it.  Does Gumpy discard
> the generated jars of a failed build?
> 
> > 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.
> 
> If this really turns out to be the problem, than it indicates that one
> of the components you depend on has broken its contracts.

Or that there is a configuration issue (coming either from Cactus or
from Tomcat)...
 
> 
> > Maybe an alternative would be for Gump to try to run the project
> > using sysclasspatonly first and then if it fails, it will run
> > "normally". The reports would show both outcomes. That would provide
> > useful feedback.
> 
> Sure.  This is part of the idea set on how to determine who is
> responsible for a failing build.

cool

> 
> But "ParsingException: Not a valid response [401 Unauthorized]" looks
> strange, I'll try to debug this a little further.

No this is normal. This comes from Cactus itself and indicates the
Cactus client side parts has not successfully authorized itself against
the server side (running inside Tomcat 3.3.x). As part of the its test
Cactus provides a tomcat users file for authorizations.

What would be very useful is to check the /tmp directory. There should a
cactus/ directory containing useful information to know what happened.
This is where cactus installs a temporary Tomcat instance.

Thanks
-Vincent


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

RE: [Cactus] commons-codec added to dependency jars?

[Vincent Massol]

> -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 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 and then use an "inherit=runtime" or something similar for
> > Cactus?
> 
> +1

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

I think if you want to make Gump more popular (in the line of thought of
the [RT] thread), this is one area to improve. A self-service Gump or
something similar so that people can help modify descriptors and verify
they still work. Otherwise the Gump committers will end up doing all the
work...

Thanks
-Vincent


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



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

RE: How to debug a Gump build problem?

[Vincent Massol]

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 containers are already installed (in our
case at hand, Tomcat 3.3.x). When I run the build locally I have the
cactus.home.tomcat3x point to where Tomcat 3.3.x is installed. Whereas
in the gump build I'm not sure it's pointing to a real install
directory. I think it's point to the directory where Tomcat 3.3.x was
built and it may happen that Tomcat build does not have all
configuration files set up correctly? I'm really shooting in the dark.

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
3.3.x).

The other possible reason for failure is because it's running on unix
whereas I'm running on windows. I'd need to set up my shell account on
cvs.apache.org to try running it there. That'll take me a while to
setup.

The only issue with all this is that it's quite difficult to do so you
have to be really motivated :-) What I mean by this is that most of the
time there's a problem with the Cactus build on Gump it's not a problem
of Cactus, it's a problem of the Gump build setup itself (at least this
is my experience from the past few years Cactus has been building with
Gump). Thus I know Cactus is building fine. I just need to make it build
with Gump...

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. Thus lots of Gump build
failures are due to this different setup. While I can see the benefit of
it, I still also value the simple fact that the build is working.

Maybe an alternative would be for Gump to try to run the project using
sysclasspatonly first and then if it fails, it will run "normally". The
reports would show both outcomes. That would provide useful feedback.

Thanks
-Vincent

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 11 March 2004 10:06
> To: [EMAIL PROTECTED]
> Subject: Re: How to debug a Gump build problem?
> 
> 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 and it fails on Linux as well as Solaris.
> 
> Ooops, I just realized that it hasn't built on the covalent machine.
> I think this was due to the fact that the configuration was stalled.
> Should build in a few minutes.
> 
> > More specifically: Do we have a shell account with read access to
> > the directory where Gump built the project?
> 
> Currently Gump doesn't run on any ASF machine, unless Stefano's
> efforts on moof have come further along than I thought.
> 
> Once we have such a beast, things should become fairly easy.
> 
> I'm not in the position to give you access to any of the machines
> currently running Gump, not even my private installation, sorry.
> 
> I'm willing to lend a hand and execute whatever you need in my
> installation,
> <http://cvs.apache.org/~bodewig/gump/jakarta-cactus-sample-servlet-
> 12.html>
> is the result from last night's run on my machine and in my home dir
> on minotaur is a zipped up version of
> jakarta-cactus/samples/servlet/target-12.
> 
> Let me know if you need anything else.
> 
> Cheers
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



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

[Cactus] commons-codec added to dependency jars?

[Vincent Massol]

Hi,

It seems that the following line was added to the Cactus descriptor:



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 directly using it and
then use an "inherit=runtime" or something similar for Cactus?

Thanks

-Vincent
Wanna see JUnit in Action?
(http://manning.com/massol)


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

RE: [RT] Moving gump forward

[Vincent Massol]

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 11 March 2004 09:28
> To: [EMAIL PROTECTED]
> Subject: Re: [RT] Moving gump forward
> 
> 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 build.sysclasspath on the command line, would the
> property be available for the Ant tasks wrapped by Maven?   for
> example would adhere to it, no matter what kind of classloader
> hierarchy Maven has built to load the task.

Hmmm... I don't see why not. However, as Maven uses forehead to start,
you'll still need to have all maven jars available to maven when it
starts. However once Maven is started I guess the Maven "java" plugin
(which uses the Ant  task should work in the same way as in a
pure Ant project).

> 
> 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. It looks like
tweaking a bit too much the product which is not built for that. Maven
as it is now is unfortunately not embeddable (as Ant is). I'd love it to
become this way in the future though.

Note that I am not an expert in the Ant-Maven bridge part in which I was
not involved...

Thanks
-Vincent


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

How to debug a Gump build problem? (was FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-sample-servlet-12 failed)

[Vincent Massol]

Hi,

Below is a Gump build failure that has been going on for too long... I'd
like to solve it. However, I can't reproduce the test error it gives.
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.

My question is: What are the facilities given to projects to debug Gump
builds? 

More specifically: Do we have a shell account with read access to the
directory where Gump built the project?

Also, is there a ASP-like GUMP installation on an ASF machine where we
could have a shell account and execute Gump build on demand. Say for
example that I notice a problem. I need to turn debug on. I'd like to be
able to rerun Gump on that project immediately and not wait for the next
day. OTOH I do not want to have to install Gump on my machine as it is
quite difficult...

Thanks
-Vincent

> -Original Message-----
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 11 March 2004 06:04
> To: [EMAIL PROTECTED]
> Subject: [EMAIL PROTECTED]: jakarta-cactus/jakarta-cactus-sample-servlet-12
> failed
> 
> To whom it may engage...
> 
> This is an automated request, but not an unsolicited one. For help
> understanding the request please visit
> http://gump.apache.org/nagged.html,
> and/or contact [EMAIL PROTECTED]
> 
> Project jakarta-cactus-sample-servlet-12 has an issue affecting it's
> community integration, and has been outstanding for 8 runs. The
current
> state is 'Failed', for reason 'Build Failed'
> 
> Full details are available at:
http://lsd.student.utwente.nl/gump/jakarta-
> cactus/jakarta-cactus-sample-servlet-12.html, however some snippets
> follow:
> 
> -  -  -  -  - -- --  G U M P
> 
> Gump provided these annotations:
> 
>  - Info - Sole jar [/data3/gump/jakarta-cactus/samples/servlet/dist-
> 12/bin] identifier set to project name
>  - Info - Dependency on aspectj exists, no need to add for property
> aspectjrt.jar.
>  - Info - Dependency on jakarta-cactus-integration-ant-12 exists, no
need
> to add for property cactus.ant.jar.
>  - Info - Dependency on jakarta-tomcat exists, no need to add for
property
> cactus.home.tomcat3x.
>  - Info - Made directory [/data3/gump/jakarta-
> cactus/samples/servlet/target-12/test/classes/java]
>  - Info - Made directory [/data3/gump/jakarta-
> cactus/samples/servlet/target-12/test/classes/cactus]
>  - Error - Failed with reason build failed
> 
> 
> -  -  -  -  - -- --  G U M P
> Gump performed this work:
> 
> Work Name: build_jakarta-cactus_jakarta-cactus-sample-servlet-12
(Type:
> Build)
> State: Failed
> Elapsed: 0 hours, 0 minutes, 28 seconds
> Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -
> Xbootclasspath/p:/data3/gump/xml-
> xerces2/java/build/xercesImpl.jar:/data3/gump/xml-
> xerces2/java/build/xmlParserAPIs.jar org.apache.tools.ant.Main -debug
-
> Dgump.merge=/data3/gump/gump-install/work/merge.xml -
> Dbuild.sysclasspath=only -Dlog4j.jar=/data3/gump/logging-log4j/log4j-
> 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/jakarta-
> commons/httpclient/dist/commons-httpclient.jar -Dcactus.port=8082 -
> Dcactus.home.tomcat3x=/data3/gump/jakarta-tomcat/build/tomcat -
> Dcactus.ant.jar=/data3/gump/jakarta-cactus/integration/ant/dist-
> 12/lib/cactus-ant-20040311.jar -Dservlet.jar=/data3/gump/jakarta-
> servletapi/dist/lib/servlet.jar -Dproject.version=20040311 -
> Daspectjrt.jar=/data3/gump/opt/aspectj1.1/lib/aspectjrt.jar -
> Dcactus.jar=/data3/gump/jakarta-cactus/framework/dist-12/lib/cactus-
> 20040311.jar -f samples/servlet/build.xml dist
> [Working Directory: /data3/gump/jakarta-cactus]
> -
> 
> BUILD FAILED
> /data3/gump/jakarta-cactus/samples/servlet/build.xml:330: The
following
> error occurred while executing this line:
>
/data3/gump/jakarta-cactus/samples/servlet/target-12/sample/build.xml:32
0:
> Test org.apache.cactus.sample.servlet.unit.TestBasicAuthentication
failed
>   at
>
org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHe
lp
> er.java:536)
>   at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:383)
>   at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268)
>   at org.apache.tools.ant.Task.perform(Task.java:363)
>   at org.apache.tools.ant.Target.execute(Target.java:300)
>   at org.apache.tools.ant.Target.performTasks(Targ

RE: [RT] Moving gump forward

[Vincent Massol]

> -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 whether Maven would support this [the build.compiler
> >> property], though.
> >
> > It does as it purely calls Ant's  task (for example, we're
> > using jikes with Maven on some project at work). Thus setting the
> > build.compiler property is all that is required.
> 
> Gump could set it on the command line of Maven and it would become a
> property inside an Ant Project instance associated with the task?  Or
> does it have to be a system property?

What do you mean by "command line of Maven"? Do you mean passing it as a
system property like this:

maven -Dbuild.property=... [...]

?

If so, this is fine. It can also be located in any of the Maven
properties files (build.properties, project.properties).

Thanks
-Vincent


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

RE: [RT] Moving gump forward

[Vincent Massol]

> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 09 March 2004 11:01
> To: [EMAIL PROTECTED]
> Subject: Re: [RT] Moving gump forward
> 

[snip]

> > or, eventually, how can gump execute ant forcing the  task to
> > be our own?
> 
> Easy, write an adapter and set the build.compiler property before
> invoking Ant.
> 
> I have no idea whether Maven would support this, though.

It does as it purely calls Ant's  task (for example, we're using
jikes with Maven on some project at work). Thus setting the
build.compiler property is all that is required.

-Vincent


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

FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-sample-servlet-12 failed

[Vincent Massol]

Hi,

I need your help to solve this one below...

1/ Is there a URL from where I can see the build output (i.e. the
target-* dirs created by the build)?

2/ Is the line:

[cactus] configurationOptionStr=null

generated by Gump? I don't recally this coming from Cactus.

Thanks!
-Vincent

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 29 February 2004 06:50
> To: [EMAIL PROTECTED]
> Subject: [EMAIL PROTECTED]: jakarta-cactus/jakarta-cactus-sample-servlet-12
> failed
> 
> To whom it may engage...
> 
> This is an automated request, but not an unsolicited one. For help
> understanding the request please visit
> http://jakarta.apache.org/gump/nagged.html,
> and/or contact [EMAIL PROTECTED]
> 
> Project jakarta-cactus-sample-servlet-12 has an issue affecting it's
> community integration, and has been outstanding for 3 runs. The
current
> state is 'Failed', for reason 'Build Failed'
> 
> Full details are available at:
http://lsd.student.utwente.nl/gump/jakarta-
> cactus/jakarta-cactus-sample-servlet-12.html, however some snippets
> follow:
> 
> -  -  -  -  - -- --  G U M P
> 
> Gump provided these annotations:
> 
>  - Info - Sole jar [/data3/gump/jakarta-cactus/samples/servlet/dist-
> 12/bin] identifier set to project name
>  - Info - Dependency on aspectj exists, no need to add for property
> aspectjrt.jar.
>  - Info - Dependency on jakarta-cactus-integration-ant-12 exists, no
need
> to add for property cactus.ant.jar.
>  - Info - Dependency on jakarta-tomcat exists, no need to add for
property
> cactus.home.tomcat3x.
>  - Info - Made directory [/data3/gump/jakarta-
> cactus/samples/servlet/target-12/test/classes/java]
>  - Info - Made directory [/data3/gump/jakarta-
> cactus/samples/servlet/target-12/test/classes/cactus]
>  - Error - Failed with reason build failed
> 
> 
> -  -  -  -  - -- --  G U M P
> Gump performed this work:
> 
> Work Name: build_jakarta-cactus_jakarta-cactus-sample-servlet-12
(Type:
> Build)
> State: Failed
> Elapsed: 0 hours, 0 minutes, 29 seconds
> Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -
> Xbootclasspath/p:/data3/gump/xml-
> xerces2/java/build/xercesImpl.jar:/data3/gump/xml-
> xerces2/java/build/xmlParserAPIs.jar org.apache.tools.ant.Main -
> Dgump.merge=/data3/gump/gump/work/merge.xml -Dbuild.sysclasspath=only
-
> Dlog4j.jar=/data3/gump/logging-log4j/log4j-20040229.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.8.2/nekohtml.jar
-
> Dcommons.httpclient.jar=/data3/gump/jakarta-
> commons/httpclient/dist/commons-httpclient.jar -Dcactus.port=8082 -
> Dcactus.home.tomcat3x=/data3/gump/jakarta-tomcat/build/tomcat -
> Dcactus.ant.jar=/data3/gump/jakarta-cactus/integration/ant/dist-
> 12/lib/cactus-ant-20040229.jar -Dservlet.jar=/data3/gump/jakarta-
> servletapi/dist/lib/servlet.jar -Dproject.version=20040229 -
> Daspectjrt.jar=/data3/gump/opt/aspectj1.1/lib/aspectjrt.jar -
> Dcactus.jar=/data3/gump/jakarta-cactus/framework/dist-12/lib/cactus-
> 20040229.jar -f samples/servlet/build.xml dist
> [Working Directory: /data3/gump/jakarta-cactus]
> -
>[cactus] Running tests against Tomcat 3.x
>[cactus]
--
> ---
>[cactus] Deleting 52 files from /tmp/cactus/tomcat3x
>[cactus] Deleted 17 directories from /tmp/cactus/tomcat3x
>[cactus] log4j:WARN No appenders could be found for logger
> (org.apache.cactus.internal.server.ServerTestCaseCaller).
>[cactus] log4j:WARN Please initialize the log4j system properly.
>[cactus] configurationOptionStr=null
>[cactus] Testsuite:
> org.apache.cactus.sample.servlet.unit.TestBasicAuthentication
>[cactus] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.037
sec
> 
>[cactus] Testcase:
>
testBasicAuthentication(org.apache.cactus.sample.servlet.unit.TestBasicA
ut
> hentication): Caused an ERROR
>[cactus] Failed to get the test results at
> [http://localhost:8082/cactus-sample-servlet-
> cactified/ServletRedirectorSecure]
>[cactus] org.apache.cactus.util.ChainedRuntimeException: Failed to
get
> the test results at [http://localhost:8082/cactus-sample-servlet-
> cactified/ServletRedirectorSecure]
>[cactus]   at
>
org.apache.cactus.client.connector.http.DefaultHttpClient.doTest_aroundB
od
> y0(DefaultHttpClient.java:95)
>[cactus]   at
>
org.apache.cactus.client.connector.h