[Cargo] Missing some dep in Gump's local Maven Repository
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
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
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 depend that
was inside the ant tag. It is now outside the ant 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-20040403.jar]
[echo] nekohtml.jar =
[/data3/gump/opt/nekohtml-0.9.2/nekohtml.jar]
[echo] jstl.jar (for J2EE 1.3 only) =
[standard/standard/lib/jstl.jar]
[echo] standard.jar (for J2EE 1.3 only) =
[standard/standard/lib/standard.jar]
Property ${xerces.jar} has not been set
[echo] xerces.jar (optional) = [${xerces.jar}]
Property ${xmlapis.jar} has not been set
[echo
RE: FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-sample-servlet-13 failed
-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: 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... 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]
FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-sample-servlet-13 failed
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.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
RE: [RT] Source difference report between 2 gump build states
-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]
RE: FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-framework-12 failed
Hi Adam, The problem is the the following declaration: depend property=httpunit.jar project=httpunit/ should only include in the CP the jars declared by the jar tag in the httpunit project. However it seems it is importing all jars in the CP. For example, with : project name=httpunit packagecom.meterware/package ant/ depend project=ant inherit=runtime/ depend project=xml-xerces/ depend project=jtidy/ depend project=junit/ depend project=nekohtml/ depend project=jakarta-servletapi-4/ jar id=httpunit name=lib/httpunit.jar/ /project 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: [Request] Make gump build directories browsable
-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: [Cactus] Gump build failure: Culprit found!
-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=ypermalink=Cactus- CommonsHttpclient.txtpreview=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]
[Help] Help required to debug a cactus gump build!
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]
RE: [Request] Make gump build directories browsable
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. rant 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). /rant 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]
[Cactus] Gump build failures for the past 2 weeks
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]
RE: [Cactus] commons-codec added to dependency jars?
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: [RT] Moving gump forward
-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 javac 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: How to debug a Gump build problem?
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]
RE: [Cactus] commons-codec added to dependency jars?
-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?
-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: 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 nCactus_TestClass=org.apache.cactus.sample.servlet.unit.TestBasicAuthen ti cationCactus_AutomaticSession=trueCactus_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 webresult/ 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]
How to debug a Gump build problem? (was FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-sample-servlet-12 failed)
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(Target.java:327) at org.apache.tools.ant.Project.executeTarget(Project.java:1213) at org.apache.tools.ant.Project.executeTargets(Project.java:1061) 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
[Cactus] commons-codec added to dependency jars?
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 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]
[RT] Gumpy deploying websites?
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?
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 nCactus_TestClass=org.apache.cactus.sample.servlet.unit.TestBasicAuthen ti cationCactus_AutomaticSession=trueCactus_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 webresult/ 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: [RT] Moving gump forward
-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 javac 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 javac 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]
