cvs commit: gump/project jakarta-jmeter.xml
sebb2004/03/10 05:41:03 Modified:project jakarta-jmeter.xml Log: Remove inherited classpath Revision ChangesPath 1.79 +8 -6 gump/project/jakarta-jmeter.xml Index: jakarta-jmeter.xml === RCS file: /home/cvs/gump/project/jakarta-jmeter.xml,v retrieving revision 1.78 retrieving revision 1.79 diff -u -r1.78 -r1.79 --- jakarta-jmeter.xml9 Mar 2004 23:57:25 - 1.78 +++ jakarta-jmeter.xml10 Mar 2004 13:41:03 - 1.79 @@ -173,7 +173,9 @@ depend project=ant / -depend project=jakarta-jmeter-cvs inherit=none ids=none/ +depend project=jakarta-jmeter-cvs + noclasspath/ +/depend !-- are these needed ? -- work nested=lib/avalon-excalibur-4.1.jar/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website
On Tue, 09 Mar 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: With this, I think that we have all necessary content together to make gump.apache.org our official home page, done. Updated the site, changed links on Jakarta and www.apache.org and added a redirect on Jakarta. I've not removed the gump directory from the Jakarta site (yet), if you want to pick up anything from there, hurry up ;-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/python/gump/model depend.py
ajack 2004/03/10 06:20:06 Modified:python/gump/model depend.py Log: I'd over optimized full dependency determination, hence full == direct depends, hence these numbers are too low: http://lsd.student.utwente.nl/gump/project_todos.html Revision ChangesPath 1.15 +8 -6 gump/python/gump/model/depend.py Index: depend.py === RCS file: /home/cvs/gump/python/gump/model/depend.py,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- depend.py 9 Mar 2004 21:19:09 - 1.14 +++ depend.py 10 Mar 2004 14:20:04 - 1.15 @@ -295,7 +295,6 @@ self.fullDependencies=DependSet() for depend in self.directDependencies.getDepends(): if not self.fullDependencies.containsDepend(depend): -self.fullDependencies.addDepend(depend) dependProject=depend.getProject() if not self.fullDependencies.containsProject(dependProject): @@ -303,6 +302,8 @@ for subdepend in dependProject.getFullDependencies(): if not self.fullDependencies.containsDepend(subdepend): self.fullDependencies.addDepend(depend) + +self.fullDependencies.addDepend(depend) return self.fullDependencies.getDepends() @@ -331,8 +332,7 @@ self.fullDependees=DependSet(1) for depend in self.directDependees.getDepends(): -if not self.fullDependees.containsDepend(depend): -self.fullDependees.addDepend(depend) +if not self.fullDependees.containsDepend(depend): dependProject=depend.getOwnerProject() if not self.fullDependees.containsProject(dependProject): @@ -340,6 +340,8 @@ for subdepend in dependProject.getFullDependees(): if not self.fullDependees.containsDepend(subdepend): self.fullDependees.addDepend(depend) + +self.fullDependees.addDepend(depend) return self.fullDependees.getDepends() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: gump/project jakarta-jmeter.xml
Thanks, I'll try that. I'm trying to fix errors of the form: Buildfile: build.xml [description] java.util.zip.ZipException: error in opening zip file [description] at java.util.zip.ZipFile.open(Native Method) that started appearing in the jmeter-test project recently. It looked like it might be trying to pick up some of the zips from the jakarta-jmeter-cvs project, when in fact it does not need to. The dependency on jmeter-cvs is needed to ensure that the test is run after the compile and build, so that it can use the output it generates (which certainly used to get left behind after a build). There are probably better ways of doing this, but removing zips from the classpath seemed a possible fix. Let's see what the noclasspath does. S. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 10 March 2004 07:52 To: [EMAIL PROTECTED] Subject: Re: cvs commit: gump/project jakarta-jmeter.xml On 9 Mar 2004, [EMAIL PROTECTED] wrote: Try to suppress inherit of output jars Hmm, I'm not sure what you are trying to do, but I think depend project=jakarta-jmeter-cvsnoclasspath//depend is what you want (at least in traditional Gump). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website
Lets finish the cleanup of the blog entry an release that also see http://gump.chalko.com/gb/blog/News/?permalink=TLP.txtpreview=truesmm=y Stefan Bodewig wrote: On Tue, 09 Mar 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: With this, I think that we have all necessary content together to make gump.apache.org our official home page, done. Updated the site, changed links on Jakarta and www.apache.org and added a redirect on Jakarta. I've not removed the gump directory from the Jakarta site (yet), if you want to pick up anything from there, hurry up ;-) 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: [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]
Moving Gump Forward (Feedback)
From this thread: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=667384 .. here are my thoughts, (for what they are worth). Stefano has convinced me that pure numbers are not the most erudite form of communication, are equivocable (folks will hate the algorythms) and could be contentious have negative impacts. I would like to find a replacement, perhaps visual, form. I don't want to promote numbers for number sake, nor be involved in undermining people's efforts via some crude raw value. That said, until we have a better solution I'm game to keep putting out numbers, but leave the interpretation to individuals. Further, numbers don't give sufficient insights into the issues affecting a branch (or a deeply product). This is huge, I agree. I don't think we truely know the chances of getting a clean Gump build. We know what stopped this one, but we don't really know what allignment of the planets will get us to a full build. We need to (somehow) analyze the branches (as sub-trees) and express information for them. I am not convinced that we *need* to get inside build results to determine exactly what caused what, but I like the idea (acadaemically) and am willing to work with folks to attempt it. Stefan has convinced me that folks builds need to be complex, and deserve community scrutiny also, so I'm all for keeping ant as the primary build tool. [I keep thinking that some projects really ought be just a simple, compile/jar/test, but I'm not convinced that it is enough to try it any time soon.] That said, I do think we need to make our metadata slightly more of a project descriptor, and not an 'ant' descriptor (describing only inputs/outputs.) I think that if we knew that the data (source code) for project X is in directory Y, we'd be in a better prosition for extensions. Leo has convinced me that the workflow is too difficult and a nice (web-based) UI is important. With that I don't see the need for relational metadata, and I personally prefer to avoid it (for now) to allow for easier extensibility. If we hide the XML I'd prefer to keep it, but I could as easily work with SQL, so am ambivalent. Basically, I like the input so far, it is refreshing. If folks have time for more I'd love to hear more about how Gump can mine it's metadata to generate new information (such as inter-relationships between projects, 'distance' between groups, trends, etc.) but maybe that is a little too far out there. regards, Adam
cvs commit: gump/blog/News TLP.txt
nickchalko2004/03/10 14:35:43 Modified:blog/News TLP.txt Log: Cleanup. PR: Obtained from: Submitted by: Reviewed by: CVS: -- CVS: PR: CVS: If this change addresses a PR in the problem report tracking CVS: database, then enter the PR number(s) here. CVS: Obtained from: CVS: If this change has been taken from another system, such as NCSA, CVS: then name the system in this line, otherwise delete it. CVS: Submitted by: CVS: If this code has been contributed to Apache by someone else; i.e., CVS: they sent us a patch or a new module, then include their name/email CVS: address here. If this is your work then delete this line. CVS: Reviewed by: CVS: If we are doing pre-commit code reviews and someone else has CVS: reviewed your changes, include their name(s) here. CVS: If you have not had it reviewed then delete this line. Revision ChangesPath 1.10 +3 -11 gump/blog/News/TLP.txt Index: TLP.txt === RCS file: /home/cvs/gump/blog/News/TLP.txt,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- TLP.txt 4 Mar 2004 01:52:34 - 1.9 +++ TLP.txt 10 Mar 2004 22:35:43 - 1.10 @@ -1,24 +1,16 @@ PREVIEW Gump is now an Apache Top Level Project - -Preparing the blog annoucnement of Gump as a TLPbr/ -Please expand and edit br/ -view at -http://gump.chalko.com/gb/blog/News/?permalink=TLP.txtpreview=truesmm=y -br/ -We will release when the gump website is ready. -hr/ pApache -a href=http://gump.apache.org;gump/a is now a top level Apache project. +a href=http://gump.apache.org;Gump/a is now a top level Apache project. Our a href=http://gump.apache.org/#What+is+Gump%3F;mission/a is still the same strongget diverse projects to communicate early and often about integration, dependencies, and versioning management/strong. However since gump is now primarily written in python and serves a community large than Jakarta we haved moved out on our own. -All Apache commiters still have write access to the entire gump CVS, and our encoured to +All Apache commiters still have write access to the entire gump CVS, and aare encoured to edit their modules cvs data to keep the builds fresh. /p pTo make all this official, on a href=http://apache.org/foundation/records/minutes/2004/board_minutes_2004_02_18.txt; -18 Feb 2004/a The Board voted to create the Gump PMC. +18 Feb 2004/a The Board voted to create the Gump PMC. /p more/ blockquote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TLP blog announcemt
Is http://gump.chalko.com/gb/blog/News/?permalink=TLP.txtpreview=truesmm=y ready for release. R, Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLP blog announcemt
Is http://gump.chalko.com/gb/blog/News/?permalink=TLP.txtpreview=truesmm=y ready for release. Thanks for doing this. We need to get into a habit of doing such when the topic is fresh in our minds, 'cos doing it after the fact trying to think back, is much harder. This one was worth it though, so thanks. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BATCH: All dressed up, with nowhere to go...
Dear Gumpmeisters, The following 15 nags should have been sent G U M P [EMAIL PROTECTED]: webwork/webwork failed [EMAIL PROTECTED]: freemarker/freemarker failed [EMAIL PROTECTED]: jakarta-tapestry/ognl failed [EMAIL PROTECTED]: jakarta-gump-test failed [EMAIL PROTECTED]: cocoon-2.1/xreporter-expression failed [EMAIL PROTECTED]: gump/gump-test failed [EMAIL PROTECTED]: xml-forrest failed [EMAIL PROTECTED]: javasrc/javasrc failed [EMAIL PROTECTED]: directory-naming failed [EMAIL PROTECTED]: jetty/jetty failed [EMAIL PROTECTED]: xml-xerces/xml-xerces1 failed [EMAIL PROTECTED]: eyebrowse/eyebrowse failed [EMAIL PROTECTED]: depot failed [EMAIL PROTECTED]: jrefactory/jrefactory failed [EMAIL PROTECTED]: jgen/jgen failed G U M P [EMAIL PROTECTED]: webwork/webwork 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 webwork has an issue affecting it's community integration. This issue affects 1 projects, 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/webwork/webwork.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Error - Failed with reason build failed - - - - - -- -- G U M P Gump performed this work: Work Name: build_webwork_webwork (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 13 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:/data3/gump/xml-xalan/java/build/xalan-unbundled.jar:/data3/gump/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -debug -Dgump.merge=/data3/gump/gump-install/work/merge.xml -Dbuild.sysclasspath=only [Working Directory: /data3/gump/webwork] - [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:69: cannot resolve symbol [javac] symbol : class MultipartListener [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartListener listener = new MultipartListener() [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:69: cannot resolve symbol [javac] symbol : class MultipartListener [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartListener listener = new MultipartListener() [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:92: cannot resolve symbol [javac] symbol : class MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] multi = new MultipartRequest(req.getContentType(), [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:96: cannot resolve symbol [javac] symbol : variable MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartRequest.IGNORE_FILES_IF_MAX_BYES_EXCEEDED, [javac]^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:102: cannot resolve symbol [javac] symbol : class MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] multi = new MultipartRequest(req.getContentType(), [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:107: cannot resolve symbol [javac] symbol : variable MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartRequest.IGNORE_FILES_IF_MAX_BYES_EXCEEDED, [javac]^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 15 errors BUILD FAILED /data3/gump/webwork/build.xml:167: 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:300) at
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? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
