Re: Processing based off statistics
On Thu, 26 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: It occurs to me that folks (like the Avalon team) are possibly frustrated by the nags they are getting, but (despite Leo's request for volunteers) are not finding time to fix them. I hope (like some folks on the forrest list) they aren't getting annoyed at the nags, but I could understand it if the are. As such, some thoughts occur... In the specific Avalon situation I beg to differ. If we all had commit access to the descriptors, I'm almost certain the avalon project wouldn't fail any longer. There are other failures in avalon due to properties not being set correctly or wrong paths. If Leo can't find help inside the Avalon team we may be better of with moving the descriptors under Gump control. In Gump's module the Avalon committers can still manage them, there are just more hands available to fix them, not less. 1) What are your thoughts to these two above? Any objects to backing off nags if ignored or (like w/ jUDDI, just deferred?) If the nags are annoying, committers for the project can simply turn them off. Same for deferred nags. After all all committers are able to remove the nag elements. This doesn't apply to externally hosted projects, see mockobjects. In this case we should disable nagging completely - on request. 2) Any other ideas for things we wish to make dependent upon last state? I'm not sure I follow you here. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are the javadocs?
On Thu, 26 Feb 2004, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: Where do I find them? Take a look into the docs: [1]: , | This option only has any meaning if the javadoc element is present | in the workspace definition. ` which is not true on the covalent.net box (which uses the gump.xml workspace from CVS). , | Python Gump does NOT (currently) support this feature. ` Does this answer your question? 8-) Stefan Footnotes: [1] http://jakarta.apache.org/gump/metadata/project.html#javadoc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Avalon's Gump build failures
Hi, I think the avalon build failure will go away if you add mkdir dir=framework/target/classes/ to your project descriptor. If you look at http://gump.covalent.net/log/avalon.html you'll not only see that avalon can be built successfully there, but also that there is no line [property] dropping /data3/gump/avalon/framework/target/classes from path as it doesn't exist like in http://lsd.student.utwente.nl/gump/avalon/gump_work/build_avalon_avalon.html I've not yet found out why the directory exists when running traditional Gump, probably because it gets created by another project and the build order is different from Gumpy's. Please patch your Gump descriptor so that you are ready to receive the next batch of nag mails ;-) Cheers Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sysproperty in Gumpy (was Re: [GUMP@lsd]: xml-xerces2/dist-xerces failed)
On Fri, 20 Feb 2004, Michael Glavassevich [EMAIL PROTECTED] wrote: The gump build for Xerces was fixed for us last week by Stefan Bodewig. By setting the build.clonevm system property. It seems as if the nested sysproperty is currently not working properly in Gumpy. The cactus-integration-ant failures in Gumpy don't occur in in the traditional Gump systems either and shouldn't happen if the system property is set. Cheers Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sysproperty in Gumpy
On Thu, 26 Feb 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: It seems as if the nested sysproperty is currently not working properly in Gumpy. http://lsd.student.utwente.nl/gump/xml-xerces2/gump_work/build_xml-xerces2_dist-xerces.html#Command+Line -Dbuild.clonevm=true comes after Ant's main class, so it is an Ant property and not a Java system property (that it needs to be in order to work). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jcifs
On Sun, 22 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: http://lsd.student.utwente.nl/gump/jcifs/jcifs.html says 0.7.12, but I can't seem to find on available here: http://users.erols.com/mballen/jcifs/ Ought we move up? Yes, I think so. We should periodically check all installed packages for newer versions. Ought we make [for the time being] LSD a master, and cascade (via rsync) to Covalent/DOTNOT, etc? Which would require us to install some kind of automatism on the other boxes. On top of that we can't use a public rsync server since some of the jars mustn't be distributed - the Sun jars for example. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gumpy.py -- cron wrapper.
On Mon, 23 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: Do you think I ought parse the workspace XML file [not using Gumpy classes], and extract all info from there? If all information you need is in there anyway, I'd say yes. Otherwise the two sets of configurations would soon run out of sync. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump project infrastructure needs
Dear Infrastructure folks, I could have made several requests in bugzilla, but since things are coupled to each other I thought I'd use a single mail. Please shout if this is not the appropriate form. As you know the former Apache Jakarta Gump has now become Apache Gump and this is a list of things that need to be done. It most probably is incomplete, we'll come back and ask for more later ;-) Unix group == First of all, we need a Unix group for the Gump project (and we suggest gump as the name). The initial members should be the initial PMC members: * Adam Jack [EMAIL PROTECTED] * Davanum Srinivas [EMAIL PROTECTED] * Leo Simons [EMAIL PROTECTED] * Martin van den Bemt [EMAIL PROTECTED] * Nick Chalko [EMAIL PROTECTED] * Nicola Ken Barozzi [EMAIL PROTECTED] * Scott Sanders [EMAIL PROTECTED] * Stefan Bodewig [EMAIL PROTECTED] * Stefano Mazzocchi [EMAIL PROTECTED] gump.apache.org === Please create a virtual host on minotaur for it, the website directory should be writable by the gump group. We'll most likely want to ProxyPass in build results from moof or one of the new boxes later. Can we do that in .htaccess? If so, is that the preferred way or should we ask here so infrastructure is completele aware of what we are doing? Mailing Lists = Please create [EMAIL PROTECTED], subscription moderated, initial moderators should be [EMAIL PROTECTED] and [EMAIL PROTECTED] The role of [EMAIL PROTECTED] should be taken over by [EMAIL PROTECTED] All mailing list settings, including the moderators and subscriber lists should remain the same. We'd like to see the eyebrowse archives of [EMAIL PROTECTED] to contain everything that has been sent to [EMAIL PROTECTED] It would be nice if mails sent to [EMAIL PROTECTED] could be forwarded to [EMAIL PROTECTED] for a while. Source Control == We'll stick with CVS for now and keep our open for all committers policy. Please rename jakarta-gump to gump and keep the group ownership and avail file info as they are so that everybody can commit. commit mails should go to [EMAIL PROTECTED] for now. Please note that there is a symlink inside the jakarta-alexandria module (proposal/gump) that needs to be adapted. Many Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build of avalon on gump
On Fri, 20 Feb 2004, Antoine Lévy-Lambert [EMAIL PROTECTED] wrote: the build of avalon fails on gump, but I have the impression that it is failing for the wrong reason : attempting to compile source files which *should not be there in the first place* rsync sometimes doesn't work as expected, I've come accross situations where I had to manually clean out the workspace Gump uses myself more than once. All the excalibur builds failed on my installation last night since the build files now contain the license in comments before the XML declaration which is not valid according to Xerces. Can whoever has access to lsd clean this directory : /data3/gump/avalon/framework/api/src/test/org/apache/avalon/framework/test/ I wouldn't want to do that while Gumpy is running. Hmm, there are six files in that directory and according to WebCVS they are supposed to be there as well. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/profile gump.xml
On 20 Feb 2004, [EMAIL PROTECTED] wrote: Add repo definition for the W3C Some background info. I've been asked (some months ago, actually) by Curt Arnold whether we could add running the DOM testsuite[1] of the W3C to Gump. This would run conformance tests which in effect would test Xerces, Xalan and Ant's xmlvalidate task. We have a working Gump descriptor already and juts need to figure out where it should live. For the time being it will become part of my own nightly Gump installation only. Stefan Footnotes: [1] http://www.w3.org/DOM/Test - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/project smartfrog.xml
On 20 Feb 2004, [EMAIL PROTECTED] wrote: +ant basedir=. target=gump-dist / this is the default value, you can as well omit the basedir attribute completely. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@lsd]: jakarta-gump/gump failed
On Fri, 20 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: I suspect it was me that put this into the gump profile, from workspaces. Does anybody mind if I remove it, and ask that it be installed in traditional workspaces? No problem. I'll take care of covalent's. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@lsd]: jakarta-struts/jakarta-struts failed
On Fri, 20 Feb 2004, Ted Husted [EMAIL PROTECTED] wrote: we are currently using LICENSE.txt rather than LICENSE. Is that a problem? No, it's just that Struts' Gump descriptor didn't know that. It's already fixed in CVS. Cheers Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Infrastructure for the Gump project
My own votes. On Thu, 19 Feb 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: We can stick with CVS or switch over to SVN If we switch to svn, all committers who want to contribute to the metadata have to create SVN accounts first. So I'm leaning towards going with CVS until more CVS committers have become SVN committers as well, just to keep the entry barrier low. Re: splitting metadata from code, I think we should split them. And maybe restrict commit access to code. We need some way to identify future PMC members 8-). Access to metadat should be kept open to all ASF committers. We should ask for a virtual host on minotaur for the site IMHO. Well, my original mail wasn#t as neutral as intended. move [EMAIL PROTECTED] to [EMAIL PROTECTED] or is there a better name? It has been [EMAIL PROTECTED] not gump-dev. I'm totally on the fence about the name, think [EMAIL PROTECTED] would be fine. do we want a Wiki for Gump? We haven't used the Wiki much, but I don't see any reason to not have one. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Infrastructure for the Gump project
On Thu, 19 Feb 2004, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: jakarta-gump CVS is still linked to jakarta-alexandria. The other way around. jakarta-gump is a real CVS module and the proposal/gump dir in jakarta-alexandria links to it. So we'd have to change the link for as long as Alexandria stays alive. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LSD problems.
On Wed, 18 Feb 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: I have root access to moof.apache.org which is sitting there doing nothing and waiting for a nice soul of ours to do the job of installing gump overthere :-) I assume you'd want to run Gumpy there. Otherwise, I do have an (unprivileged) account on moof as well and could help setting up a traditional Gump. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/blog/SuccessStories velocity-jdom.txt
On Thu, 19 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: I never noticed the other postings though, but maybe they were prior to PC being added to Planet Apache, and hence not eligible or something. It is there, you just have to scroll way down to February 17th 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gump on moof
On Thu, 19 Feb 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: I have updated the box to the latest software patches, including the OS 10.3.2 and JVM 1.4.2 [kinda scary to reboot the machine from here, but hey, it worked fine! :-)] You'll also need a subversion client on moof. ISTR there were some people on the infrastructure list with prebuilt svn clients for OS X. ProxyPass/ http://moof.apache.org:16080/gump/ ProxyPassReverse / http://moof.apache.org:16080/gump/ I'm not sure whether we'll want to ProxyPass the complete site or maybe keep the static content on minotair and just proxy in the nightly builds, like ProxyPass/builds/ http://moof.apache.org:16080/gump/ ProxyPassReverse /builds/ http://moof.apache.org:16080/gump/ or /logs/ or something. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LSD problems.
On Thu, 19 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: Maybe it is time to get you comfortable with Gumpy, Stefan. You bet 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
More JDOM changes
Hi, it seems as if the JDOM saga continues, XMLOutputter#setEncoding has been removed leading to build failures in Velocity and Slide. The method has been deprecated in beta10rc1 (maybe even beta9) and people are now expected to use the Format instead. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More JDOM changes
On Wed, 18 Feb 2004, Antoine Lévy-Lambert [EMAIL PROTECTED] wrote: I have just had a look at the lsd html pages, and I see that jakarta-velocity is reported failed due jakarta-regexp. I checked my own nightly build - still a traditional Gump. See also http://gump.covalent.net/log/jakarta-velocity.html. jakarta-regexp says it failed because of a missing license file. Yes, Gumpy has become more strict. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump TLP established
Hi, those of you who are subscribed to the infrastructure list will have seen it already, the official board meeting summary from Greg will come a bit later. Our resolution has been approved by the board, Gump is now a top level project. The first things we'll need to do now are hashing out the infrastructure details and after that work out the project's bylaws. I'll start a separate thread for the infrastructure stuff soon. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Infrastructure for the Gump project
So what do we have: * Source Control We can stick with CVS or switch over to SVN now that the 1.0 release of SVN seems near (rumors say next week). If we switch to SVN it may become more difficult for other Apache committers to contribute, I'm not sure. If we stick with CVS, we simply should as infrastructure to mv jakarta-gump gump IMHO. Do we want to keep our current policy of every ASF committer can commit to Gump? * Website = Somebody will have to come up with a forrest skin for gump.apache.org and maybe tweak our current site to make it stand alone. I don't feel forrest savvy enough to even think about doing so. 8-) I'd have karma for jakarta-site to make the changes there once our new site is up. We should ask for a virtual host on minotaur for the site IMHO. Once we have gump builds on a different ASF machine, we can always ProxyPass the results into the gump.apache.org URI space if we want to. * mailing list(s) = move [EMAIL PROTECTED] to [EMAIL PROTECTED] or is there a better name? This also involves adapting eyebrowse and JIRA. Adam, can you change the JIRA configuration as admin or do we need infrastructure help? Any other lists we'd initially want? Split commit messages from the rest? * JIRA == Apart from changing the mailing list, is there anything else we'd need to do? * Wiki == The old Wiki has been used for the Newsletter reports IIRC, do we want a Wiki for Gump? * Things I've forgotten === Please fill the gaps 8-) Cheers Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Resources
On Tue, 17 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: Ought we make a request to folks in fund raising for partners? Ought we be approaching mirror sites for this? I'd try [EMAIL PROTECTED] instead. [Separately, do anyone think that covalent could spare their Gump box for one traditional and one Python?] The machine is not really fast, I pretty much doubt that we'll get both Gump's completed within 24 hours, well, maybe if they share the cvs updates. Ought this all wait for TLP status? You mean another day? 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New nag mail intro text
Hi, I really like the new header, just a minor(?) enhancement request: could we please word wrap the text so that lines don't exceed about 72 columns? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/project jakarta-slide.xml
On Fri, 13 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: It seems that even commit messages need to be moderated. This is generally true. I'm also moderating [EMAIL PROTECTED] and I - we - usually allow the first post so subsequent commits don't have to get moderated in. Stefan, have you been getting moderation messages? Have you responded? When I've been online, yes. 8-) Do you get any notification of my moderations? No. I'm curious about whether we are both responding, and I wonder if I ought copy you so you know what's been done. No, this is not necessary. If our decisions are the same, nothing happens. If we disagree, the first one wins and the second one gets notified. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JRE 1.4 endorsed mechanism
On Sun, 15 Feb 2004, Berin Lautenbach [EMAIL PROTECTED] wrote: The xml-security library requires that xalan be installed in JDK_HOME/jre/lib/endorsed to override the old version that comes with JDK 1.4. With Xerces-J we are going even further, we put the CVS HEAD jar onto the bootclasspath so it gets used instead of Crimson. This should be possible with Xalan as well, and to me it even looks as if we'd use the same mechanism (type=boot on the jar element). Looking at the output from the last gump run for security, it would appear that the old library that comes with 1.4 is being used : Seems build.clonevm is becoming a FAQ 8-) The bootclasspath trick is not working since xml-security's junit task runs in a different Java VM by using fork=true. Ant's CVS HEAD uses a new Java system property to ensure that the forked VM uses the same bootclasspath as the one running Ant. I'll enable that property for xml-security in a few minutes. Cheers Stefan -- http://stefanbodewig.blogger.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Gump (again)
On Fri, 13 Feb 2004, Brett Porter [EMAIL PROTECTED] wrote: This is exactly what I'm saying - by rebuilding the plugins with the new JARs, when Maven is run for other projects, the newly built plugin will be used. So if we move to bootstrapping Maven as part of the gump process, this should come naturally. We agree completely. 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XOM nag e-mails
On Sun, 15 Feb 2004, Elliotte Harold [EMAIL PROTECTED] wrote: I noticed that XOM is now being buil in Gump: http://gump.covalent.net/log/xom.html We added it because it was needed by Jaxen IIRC - and easy to setup 8-) Could you put me on the list for the nag e-mails from this project? Sure. Asking whether you wanted nag mails was on my TODO list anyway since XOM's build has been broken once or twice in the past. Done using your address as the recipicient. Maybe you'd prefer [EMAIL PROTECTED] or [EMAIL PROTECTED] or even [EMAIL PROTECTED] instead? Cheers Stefan -- http://stefanbodewig.blogger.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please add two moderators
Thanks Berin, it worked, I just received my first spam mail for the gump list ;-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tales of running Gumpy from scratch
On Wed, 11 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: Stefan, you had chance to re-run yours on Linux against JDK 1.3? I swear I've now made that javac check just a warning... ERROR:gump:Failed to detect [javac] ERROR:gump:Command failed. [java com.sun.tools.javac.Main -help ]. ExitCode: 1 ERROR:gump:Failed to detect [java com.sun.tools.javac.Main] am I supposed to add tools.jar to my CLASSPATH? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tales of running Gumpy from scratch
On Thu, 12 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: ERROR:gump:Failed to detect [javac] Ok, failed, but didn't exit. An extreme warning, I know, but. Uhm, not sure as it doesn't do much after that except for: Unable to detect/test mandatory [java com.sun.tools.javac.Main] in path (see next). /home/bodewig/ASF/jakarta/jakarta-gump /home/bodewig/ASF/jakarta/jakarta-gump/python/gump /home/bodewig/ASF/jakarta/jakarta-gump/python /usr/lib/python2.2 /usr/lib/python2.2/plat-linux2 /usr/lib/python2.2/lib-dynload /usr/lib/python2.2/site-packages I had just snipped that off. Antoine wrote: This is what I did yesterday to get my gumpy running Stefan. Maybe we should add something in gumpy.sh to set this automatically based on $JAVA_HOME ? Maybe, if we don't find a better way from above. Just take a look at how the Ant wrapper script does it. It is a pain but it works for ant. Looking at JAVA_HOME is part of the process 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tales of running Gumpy from scratch
On Thu, 12 Feb 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: Just take a look at how the Ant wrapper script does it. Of Ant 1.6, that is. Starting with 1.6.0 we sort that out from within Java which is much easier to do as we can ensure we pull in the tools.jar from the same JDK that is currently running Ant. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@lsd]: xml-xerces2/dist-xerces failed
On Thu, 12 Feb 2004, Elena Litani [EMAIL PROTECTED] wrote: It seems like xercesImpl.jar can't be found. Uhm, is the docs target forking the java task? Uhm, yes it is. I'll fix it for you, need to add a property to the ant element in your Gump descriptor. However, we've also introduced a dependency on a new jar - resolver.jar from xml-commons. It hasn't been needed so far. You'd simply have to add depend project=xml-commons-resolver/ to the descriptor for dist-xerces when needed. Can someone fix the GUMP? Every Apache committer has commit access to the jakarta-gump module. The descriptor would be in jakarta-gump/projects/xml-xerces2.xml. Cheers Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@lsd]: jakarta-slide/jakarta-slide failed
On Thu, 12 Feb 2004, Oliver Zeigermann [EMAIL PROTECTED] wrote:
Does anyone have any idea why this fails? Just tried it on a cleanly
checked out version and everything works fine.
Gumpy works against the CVS HEAD version of commons-httpclient. It is
supposed to use the 2.x branch, but there seems to be a bug in Gumpy.
Take this as a heads up that CVS HEAD of httpclient is incompatible
with 2.x for your usage.
On traditional Gump systems Slide also fails, but for a different
reason, see http://gump.covalent.net/log/jakarta-slide.html. There
seems to be a hard coded 2.0beta1 instead of ${version} in your build
file.
Could it be GUMP uses jars different from ours?
Yes, it doesn't use any of the jars from slide's CVS 8-)
Gump builds everything against the very latest code of everything else
as an early warning system for backwards incompatible changes (among
many other things).
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump Icon/Slogan
On Tue, 10 Feb 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: If we get top level, what do you guys think about a logo/skin contest? Sounds fine. We had a logo contest for Ant where we let the users decide on the logo and it has been a lot of fun. Friend of Gump +1000! I love it!! +1 Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: who is moderating the gump lists ?
Thanks to a little tool provided by Ken Coar Results of your search (as of 2004-02-10): Lists with list matching '[EMAIL PROTECTED]': [EMAIL PROTECTED] Subscribers:93 Digest readers: 0 Moderators: [EMAIL PROTECTED], [EMAIL PROTECTED] I volunteer to get added as a moderator, this won't increase the amount of spam I receive too much. Any other takers before I ask the infrastructure list? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jaxen-from-packaged-dom4j: where to place work in CLASSPATH
On Tue, 10 Feb 2004, Scott Sanders [EMAIL PROTECTED] wrote: I am also willing to leave Gumpy as the correct way, OK, done. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Gump (again)
On Wed, 11 Feb 2004, Brett Porter [EMAIL PROTECTED] wrote: This wouldn't do it - junit is not specified in MAVEN_HOME/lib, but as a dependency in the junit plugin, later loaded into the maven classloader. But whoever is responsible for the JUnit plugin would like to know that things break. We should try to make this work for Maven in the longer run. But, really, how often does Junit change anyway? :D Often enough that Ant's JUnit task has been broken somewhere between JUnit 3.7 and 3.8. Do you have any plugins that rely on xdoclet? ;-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: re POI is having trouble with gump was: GUMP
On Tue, 10 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: BTW: Any thoughts on a way to ask Gump to start from fresh on a module, delete the local copies? Gump doesn't know if metadata changes (at least today). Maybe we should change that instead of introducing a delete-once marker? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HEADSUP] Overrides/merging...
On Tue, 10 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: I seriously doubt that overrides work as (traditionally) intended, and merging -- gosh knows, probably not. I don't have any overrides in my workspace anymore, I do merge in a deliver (which has to die) tag to the gump project. Is there an easy way in Gumpy to see whether this has been merged in, in traditional Gump I'd look into work/merge.xml. Unit tests? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDOM and Velocity
On Wed, 11 Feb 2004, Geir Magnusson, Jr. [EMAIL PROTECTED] wrote: We changed to follow the JDOM API change. OK. Has there been any feedback from Jason or the rest of the JDOM team? The class has been moved to the org.jdom package just a few days ago, so your change makes Velocity depend on JDOM b10rc1, which may be fine depending on Velocity's release schedule. Just curious Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDOM and Velocity
On Wed, 11 Feb 2004, Geir Magnusson, Jr. [EMAIL PROTECTED] wrote: It's a real pain in the keister, I have to say, No doubt. We'll modify the upcoming 1.4 release currently an RC It must be extra painful to get bitten by such a change at this stage of the release cycle. Oh my. Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDOM and Velocity
On Wed, 11 Feb 2004, Antoine Lévy-Lambert [EMAIL PROTECTED] wrote: On which gump instance did velocity build ? Mine 8-) Also http://gump.covalent.net/log/jakarta-velocity.html On lsd it did not build due to dom4j missing. Hmm? I don't think Velocity depends on dom4j, and this here http://lsd.student.utwente.nl/gump/jakarta-velocity/jakarta-velocity.html looks fine. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jaxen-from-packaged-dom4j: where to place work in CLASSPATH
On Wed, 11 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: I feel we need to start to migrate the knowledge from your head/traditional Gump into documentation, or we'll never have a community that can self-diagnose, self-manage. Understood. 8-) I'll see what I can do. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please add two moderators (was Re: who is moderating the gump lists ?)
Dear Apmail, could you please add [EMAIL PROTECTED] and [EMAIL PROTECTED] to the list of moderators for [EMAIL PROTECTED] Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDOM and Velocity
On Wed, 11 Feb 2004, Geir Magnusson, Jr. [EMAIL PROTECTED] wrote: maybe it's jaxen? well, maybe. Jaxen's CVS HEAD has absorbed saxpath while dom4j's CVS HEAD is still looking for the old org.saxpath stuff, so it hasn't been adapted to compile against Jaxen HEAD yet. On the other hand dom4j tries to compile Jaxen from source itself and this causes trouble when you use an installed Jaxen. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HEADSUP] Overrides/merging...
On Wed, 11 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: For things which are 'named' (Profiles, Modules, Projects, Repositories, Servers) an object is created (and stored in a hash) when first encountered. Subsequence XML representations of such an object with such a name get the hashed object to work on. So in theory merging should work and overriding may work - depending on which XML representation is read first and whether the first or the later representation wins. Unit tests? Meaning, does Gumpy have any? No, I know it has 8-) If we know how we want overrides and merges to work, it should be possible to put together simple workspaces to test the code. FWIIW: Gumpy needs to move from basic Python (teaching myself as I go along) to 'power Python', leveraging more packages being 'nicer' Python code. Maybe this is something that happens with the move to TLP, assuming we can get some of the Python savvy folks in the ASF involved. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Gump (again)
But whoever is responsible for the JUnit plugin would like to know that things break. We should try to make this work for Maven in the longer run. On Thu, 12 Feb 2004, Brett Porter [EMAIL PROTECTED] wrote: Absolutely - this is why the plugin needs to be rebuilt with the latest jars. Sometimes failures are more difficult than that. The plugin may compile but fail to execute with a new lib. So Gump should be able to override the jars used by the Maven plugins as well - sooner or later. Do plugins adhere to jar overrides? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: directory-naming
On Mon, 9 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: I believe I got a fair way along with this, I create the Maven project properties override file, and in it I try to override jar handling. I'll try to focus on this again soon. Thanks a lot. Stefan wrote: Making Maven build within in Gump would be important as well IMHO, but if this isn't possible for any reason, so be it. Yes. I feel passionately about that. Absolutely. By all means I think Maven should be buildable by Gump. But we shouldn't exclude projects that have elected to use Maven as their build tool from Gump just because we can't build Maven itself. I know we agree here, I' just stating the obvious 8-) Q: Do we know if the Maven descriptor is up to date? I pretty much doubt it. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Gump (again)
On Mon, 9 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: I see two choices in the command line to Maven: 1) Run the maven script (.bat or .sh) to let Maven run java (with it's JVM settings) and set it's environment. 2) Run the following: org.apache.maven.cli.App (2) is the preferred choice if it works as we'd get to catch even more problems - for example if a change in JUnit breaks Maven's junit plugin. This may be even more true as long as we are unable to build Maven in Gump. If it doesn't work, go for (1) as an interim solution. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jaxen-from-packaged-dom4j: where to place work in CLASSPATH
On Tue, 10 Feb 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: I may be missing a reason why traditional Gump works the way it does right now. well, at least I now know that I made sure it does: http://marc.theaimsgroup.com/?l=alexandria-devm=102585469601635w=2 and found this thread http://marc.theaimsgroup.com/?l=alexandria-devm=102517311610649w=2 So putting work last ensures that you can't cheat by pointing to jars in CVS while putting it first ensures you compile against the latest code in situations where there are duplicate classes. I'm willing to change my opinion of almost two years ago and make traditional Gump behave like Gumpy here. If you want to cheat, that's probably your problem. Thoughts? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/project mockobjects.xml
On Mon, 9 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: ERROR:gump:Command failed. [javac -help ]. ExitCode: 2 this is exactly what javac -help returns for JDK 1.3 (java full version 1.3.1_07-b02) on Linux. JDK 1.4.2's javac returns 0. I think I made this a warning, not an error now. fresh CVS update ERROR:gump:Command failed. [javac -help ]. ExitCode: 2 ERROR:gump:Failed to detect [javac] and later Unable to detect/test mandatory [javac] in path (see next). /home/bodewig/ASF/jakarta/jakarta-gump /home/bodewig/ASF/jakarta/jakarta-gump/python/gump /home/bodewig/ASF/jakarta/jakarta-gump/python /usr/lib/python2.2 /usr/lib/python2.2/plat-linux2 /usr/lib/python2.2/lib-dynload /usr/lib/python2.2/site-packages which probably echoes PYTHONPATH but not PATH. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Projects/Modules (and source dir / home dir / base dir)
On Mon, 9 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: For directories ... I see that ant has the concept of 'basedir' (relative to the module, I believe) and this is for kicking off a build. Yes. I assume it is named after Ant's own basedir attribute for the project tag in Ant build files. I see that project can override this -- but it doesn't mean this is the area for a project under a module, it is not where stuff is (per se). True. As for overrides, see below. Sometimes projects put build files into strange locations like a build subdirectory of where stuff is and expect the build to be executed from there. I see we have 'home' dir on a project, but that is for results -- not where stuff is. because some projects tend to place the outputs in a very different place than where stuff is. Take JUnit for example, it even moves it outside of the current source tree. [I also see 'source directory' (a misnomer?) for a module. Not sure if this get played w/ much.] Used by property reference=srcdir/, I agree, it's not too frequently used. Basically --- I feel a project (and it's contents) are not clearly/easily specified. Because projects are neither clear nor easy 8-) Can we have a concept of 'this is the root of a project under this module' -- and perhaps allow values to be set when this doesn't work, or do projects (in Gump) just not work that simply?] Hmm, take bootstrap-ant, ant and dist-ant. Where does each project live? test-ant? Does it mean ' override', or does it mean 'override default'? It means override. This is not for a straight ant nested into project case where the override mechanism doesn't make any sense. It becomes important when you have multiple definitions for a project and they get merged. This gives you a chance to augment the project definition (coming from Apache's Gump for example) with some extra pieces inside your workspace definition. See the rubypad.xml workspace where Sam has overridden the build targets for Cactus and Xalan's smoketest. I'm starting to wonder if we need to take a step back and see if the Gump metadata is exactly a model we'd like to continue with, Probably not 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Alexandria and JavaSrc and moving code
Hi, I didn't think of it immediately when Nicola Ken talked about moving the Alexandria code to Forrest. Dims has already asked (and even started a vote[1] to that effect) to move the JavaSrc code base to Maven. Maybe we/you should cordinate a little 8-) Stefan Footnotes: [1] http://marc.theaimsgroup.com/?t=10751398141r=1w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: directory-naming
On Fri, 06 Feb 2004, Phil Steitz [EMAIL PROTECTED] wrote: The project is a maven multi-project and I could not get maven to generate an effective build.xml, so I hacked together ant scripts and checked them into the svn repo, but somehow gump is still not seeing the top-level build.xml. I think I found the problem. The svn directory for directory-naming has been changed during the lifetime of its gump descriptor. If something like this happens (same for CVS dir or module changes), the checked out working directory on the machine running Gump has to get manually removed - as Gump will only run an svn update inside the working copy and not pick up the change otherwise. I've removed the working copy on LSD so the next nightly build should see your build.xml. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: directory-naming
On Mon, 9 Feb 2004, Brett Porter [EMAIL PROTECTED] wrote: I honestly think its time to make that a separate issue and just build projects with the latest release of Maven. I agree, but I'm currently not able to make Gumpy use an installed Maven as I'm neither familiar enough with Python nor the Gumpy code. The minimum requirement obviously would be that Gump(y) uses an installed version of Maven but this installed Maven will never download any jars and use the CLASSPATH or any other configurable source of jars when building a project - even if the project states some dependencies on specific released versions in its project.xml. I understand from you past posts that this should be possible, but I don't know whether we have all the facts on how to make it possible. Making Maven build within in Gump would be important as well IMHO, but if this isn't possible for any reason, so be it. On my traditional Gump installation the project maven-bootstrap doesn't start a compilation because commons-jelly-tags-ant fails. This particular project fails as one of the unit tests fails because of a hard coded absolute path that doesn't exist (this is what it seems to be to me). In Gumpy commons-jelly-tags-junit fails because one of the tests fails - and I'm not clear why. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed resolution for Gump as TLP
On Mon, 9 Feb 2004, Bill Barker [EMAIL PROTECTED] wrote: What I want to know is if Gump (or at least 'projects') is going to remain open to all ASF commiters. We'll have to see, but I think the current model has been successful. Maybe we will want to split Gump into a metadata module with write access for every Apache committer and a code module with more restricted rules. Maybe we want to keep it just the way it has been. I wouldn't want to become more restrictive than we've been before with metadata. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where do the cvs commit message go?
On Mon, 9 Feb 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: I have not seen the gump cvs commit messages in a while. Where are they sent to? [EMAIL PROTECTED] which should be [EMAIL PROTECTED], at least according to the headers of the commit mails I've received today. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit mails are not working ?
On Fri, 06 Feb 2004, Antoine Lévy-Lambert [EMAIL PROTECTED] wrote: in this case I will subscribe to this email list as [EMAIL PROTECTED] and it will be fine. No, don't. Well, not in order to get commit mails in, at least. Usually the moderator will use your first commit mail to allow your committing address in - which in turn makes all commit messages after that go to the list without moderation. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump docs gen AKA Alexandria (was Re: Gump as TLP)
On Thu, 5 Feb 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: What should I do, move the core here, to Forrest, whatever else? I don't know, the code could reside in alexandria for now and gump/gumpy might simply run it for that project. +1 I don't see a reason to move it either. We wouldn't move Ant's junitreport task just because we can also publish the unit test reports either. 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump docs gen AKA Alexandria
On Fri, 06 Feb 2004, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: What instead I tend to think is better would be to move it under Forrest. Wherever you find a community that supports it ... The main reason is that Alexandria is dead, because it doesn't have a community that supports it ;-) You need to get people interested in and working on it, then it doesn't matter at all where the code lives. If you think it will be welcome by the Forrest community, go for it. Well, the interested people from the Forrest community could as well join Alexandria. Whatever works best for you (plural you). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump as TLP
On Wed, 04 Feb 2004, Leo Simons [EMAIL PROTECTED] wrote: ... charged with the creation and maintenance of open-source software related to promotion and facilitation of automated integration of the software produced by other projects. I'm fine with it. It doesn't feel quite as warmly nor read as easily as the other stuff, but I don't think those are the primary criteria :D ...boy this is hard work! (Especially when English is not your native language ;)) +1 Exactly. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build of xml-batik on gump
On Thu, 05 Feb 2004, Antoine Lévy-Lambert [EMAIL PROTECTED] wrote: I do not know *yet* how to change the project descriptors so that it happens. If the jar you want to use is part of batik's CVS, simply add a work element pointing to the jar and remove the depend element from batik's descriptor. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nagging the cause vs. Nagging the effect
On Thu, 5 Feb 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: On 5 Feb 2004, at 02:17, Adam Jack wrote: I've long wished that Gump could nag the 'cause' of a problem, not the 'effect', but it is (AFAICT) pretty much impossible to guess who is cause from a compile failure. Tell you what: there have been long discussing about this and endless hours that I spent on the whiteboard trying to figure out *where* that data can emerge out of the entire mass of data that gump is either collecting or generating. I was still not able to find it, still not able to come up with a general algorithm that would, at least, if not identify the cause, at least discriminate between causing trends and effected trends. The way you'd do it manually is about as follows, I believe: * start with the last good build * replace one of the dependencies with its latest version at a time and rebuild - reiterate until the build fails. Gumpy should have enough data to do that, but the whole thing breaks down when Gump has been unable to build a project for weeks or even months as the number of changes becomes too big. I think the key is that the gump runs as for Gump or Gumpy do *not* contain enough information. But if we had both: 1) the latest dependency run 2) the stable dependency run and we had enough history of these (say a few months), I'm pretty sure the data *IS* there. I think Gumpy already collects, or at least could collect, historical data for all dependency runs. If the dependency run has been successful at least once, the data is supposed to be there. I realize that this is naive. 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/project mockobjects.xml
On Wed, 4 Feb 2004, Adam Jack [EMAIL PROTECTED] wrote: If I pick ant, python starts to hog my CPU and finally (about two minutes later) says Hog? You mean use enthusiastically, no? ;-) As enthusiastically as gen.sh during the merge part, just longer 8-) Xerces-J may be a bit faster than the Python XML parser. Looking at the code, this means the workspace has a module with an SVN entry, but without a 'repository' attribute? Yes, it has. Fixed and I get a whole lot further. Gumpy now complains about me not providing enough information about my environment (like FORREST_HOME not being set). Maybe it should check for them before it parses the workspace, that way I'd know that I need to provide more data a lot earlier. I'll look into setting it up sometime next week. BTW, along the lines is ERROR:gump:Command failed. [javac -help ]. ExitCode: 2 this is exactly what javac -help returns for JDK 1.3 (java full version 1.3.1_07-b02) on Linux. JDK 1.4.2's javac returns 0. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump as TLP
On Mon, 02 Feb 2004, Leo Simons [EMAIL PROTECTED] wrote: charged with the creation and maintenance of open-source software related to continuous integration, I'm not sure whether this is too broad and if this collides with the goals of the Maven project. So far Gump is tackling one facet of continuous integration which may be more than just building things against each others latest source control versions. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MO-java-dev] compilation problem for mockobjects
On Tue, 3 Feb 2004, Vincent Massol [EMAIL PROTECTED] wrote: I haven't been following the discussion but for the record I think using Gump is great and should be continued. I've seen a similar comment by Jeff in the archives (I tried to subscribe to mockobjects-java-dev but SF's mailing list manager was down yesterday, so I'm not yet subscribed). What I've done so far is that I've added mockobjects-0.09 and made all projects in Gump depend on that. Gump still tries to build the CVS HEAD revisions of mockobjects[1][2], but no other project depends on it and I've turned of nagging. Cheers Stefan Footnotes: [1] http://gump.covalent.net/log/mockobjects-cvs-head.html [2] it currently doesn't work in the new Python version, but we'll work on it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MO-java-dev] compilation problem for mockobjects
On Wed, 4 Feb 2004, Nat Pryce [EMAIL PROTECTED] wrote: Considering what Gump is meant to be used for, would it be better for it to be edge triggered rather than level triggered. It depends on the community you want to reach. Sometimes it takes repeated nagging to get the message through. Sometimes you generate the opposite effect by nagging, i.e. mails get ignored. That is, should it send a message when a project fails to build, and then sends a message when the project builds successfully again, instead of sending a message every time it fails to build a broken project? Yes, this would certainly be an option, and I think much of the statistics sthe new Python implementation of Gump collects can be used for that. We also generate RSS feeds that contain exactly these types of status changes IIRC. The email based nagging system has been Gump's traditional approach and it has done an outstanding job in many cases. I agree that it is plain annoying if it comes unwanted. Maybe we can improve the nagging part in the Python implementation to be configurable on a project level. Some projects may want a nightly report even on successful builds as confirmation, others may only want to get notified on status changes (as you describe it). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump as TLP
On Wed, 4 Feb 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: On 4 Feb 2004, at 04:14, Nicola Ken Barozzi wrote: In a sense it's about continuous integration applied also between communities and between the code and the community. Dunno how to say that though 8-) I like that continuous integration between different codebases and between the code and its community. Nice. Yes, I like the sound of it. But I also think that gump needs to act as a nightly build system as well. which would not integrate the latest code, but build against stable dependencies? ... charged with the creation and maintenance of open-source software related to automatic project artifact creation in order to promote stronger integration between the various codebases and between the codebase and the communities that maintain it. Nice. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump as TLP
On Wed, 04 Feb 2004, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: Stefano Mazzocchi wrote: ... in short, I would say it as ... charged with the creation and maintenance of open-source software related to automatic project artifact creation in order to promote stronger integration between the various codebases and between the codebase and the communities that maintain it. Nice. But Gump also makes stats and someone proposed javadocs (ala defunct alexandria). javadocs certainly are artifacts, so would be any other generated stuff I'd say. stats would be a means to promote the integration. Or maybe simply put: ... charged with the creation and maintenance of open-source software that promotes stronger integration between the various codebases and between the codebase and the communities that maintain it. That would include a Wiki (at least for some people) as a Wiki would be software that promoted integration of communities. 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump as TLP
On Wed, 04 Feb 2004, Leo Simons [EMAIL PROTECTED] wrote: too broad is difficult for me to assess. I vaguely recall board members raising concerns about too broad project goals in the contexts with proposed resolutions for Maven. More or less recursive definitions have worked for Ant (the Ant PMC is tasked with developing Ant, basically) but has raised concerns for Cocoon and Maven IIRC. We probably know what we want Gump to do, we may have different ideas on where we want to go in the future, but the big picture is clear. I don't think that the words we put into the resolution would make any difference. It's just that board resolutions tend to be in that pseudo-legalese that make you chew each word and test its taste. Stefan Bodewig wrote: and if this collides with the goals of the Maven project. probably. Is that bad? Maven 'collides' with some of the ant project goals, doesn't it? Is that bad? Depends on who you ask. I'd want to avoid unnecessary friction. I dislike the term collides tho'. Sounds negative. There's overlap. This is because it's a straight translation from my thoughts. Goals can't overlap in German, they can match exactly or collide. 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gumpy and option
Hi, excalibur-component builds on gump.covalent.net but not on lsd as Gumpy doesn't even try to build it. It says the prereq checkstyle was missing. checkstyle is an optional dependency, doesn't Gumpy support that, yet? Sorry that I can't do more than complaining ATM. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump as TLP
On Sat, 31 Jan 2004, Sander Striker [EMAIL PROTECTED] wrote: There is currently a community of 4 developers actively working on Gumpy Gumpy is in ASF CVS? Yes, inside the jakarta-gump module in the python subdir. And all devs are ASF committers? Yes. and since all ASF committers have access to the gump database for project dependencies, it's hard to keep track of how many different people actually contribute to Gump. This is using Gump, I presume, not development on the tool itself. Right now there is no hard line to draw between using and developing Gump. Gump, the tool uses metadata about projects. For Gump, the instance that performs the integration builds (a user of Gump, the tool 8-) on the machines listed by Stefano, this metadata is stored inside the jakarta-gump repository as well (mostly, part of it is maintained separately). Most contributions to Gump ATM are contributions to the metadata. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat build failures on gumpy
On Sun, 1 Feb 2004, Bill Barker [EMAIL PROTECTED] wrote: Now Tomcat seems to have a problem with: property name=commons-daemon.jsvc.tar.gz project=commons-daemon path=/daemon/dist/bin/jsvc.tar.gz/ Gumpy is interpreting the path to be relative to the Tomcat directory instead of relative to the commons-daemon directory. So Gumpy is wrong 8-) http://jakarta.apache.org/gump/metadata/ant.html Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/project xml-xindice.xml
On Thu, 29 Jan 2004, Antoine Lévy-Lambert [EMAIL PROTECTED] wrote: Did you make a build of xmldb yourself, or is this an official distro ? Honestly, I have no idea what it is or where it came from - I mean, whether it is some kind of official. From time to time projects depend on things we can't or don't want to build and we find that the required jar have been checked in somewhere. It's lazyness on our side that we reuse this instead of making it a fullblown package. I think in the xmldb case, only xindice needed it when it was declared, so we added a little project descriptor to it. At the point where other projects started to depend on it as well it should have been turned into an installed package (or a project we build). But there's always something that's more important, you know. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nags away...
On Thu, 29 Jan 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: Thanks to Scott Sanders (donating SMTP services) we have sent some nags again. Woohoo. I've just moderated in the message for [EMAIL PROTECTED] (test failure). Many thanks! Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HEADS UP request for comment on 'server'
On Thu, 29 Jan 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: I never knew what the old 'server' components were used for, but here is what I'd like to see: deliver, which has never been used except for the traditional Gump running on my machine AFAIK. It has never been properly documented either - go and kill it ;-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat build failures on gumpy
Hi, Adam, is the Python Gump assuming that the target attribute of ant contains exactly one target and passes it as a single argument? For a reason unknown to me the Tomcat community has chosen to put a space separated list of targets into this attribute instead of defining a Gump specific target that depends on them. Could you change gumpy to work with it like the traditional Gump did, i.e. split them at the spaces? Thanks Stefan -- http://stefanbodewig.blogger.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nightly builds, Gump, Maven and repository issues.
On Thu, 29 Jan 2004, Mark R. Diggory [EMAIL PROTECTED] wrote: 2.) There is the nightly build process on minotaur that Craig McClanahan runs. This generates nightly builds under /www/cvs.apache.org/builds/... There used to be a nightly process on Sam's machine that placed Gump-built nightlies for various projects there as well. 3.) There are the various continuous integration builds gump is managing. These are producing jars and other distributables. Right now, all those Gump installations run on non-ASF hardware. There have been talks about setting up a dedicated machine for builds and Gump would use that, but there is not much yet. It would be beneficial to see these various sources unified or synced up in someway. Gump's goal probably is a bit different from what Craig's script does. I'm pretty sure that Craig will build against the latest releases of components the thing he wants to build depends on - while Gump will always build against the latest code. This means that Gump may fail to produce anything if any component you depend upon changes in a backwards incompatible way (and your compilation fails because of this). This is probably not acceptable for a nightly build systems unless you have very few or very stable/well-behaving components you depend upon. For things like Struts Gump couldn't replace Craig's script - and vice versa as Struts would be losing the early warning if things change. For projects that don't get built by Craig's script and are unlikely to be broken by components they depend on - say Ant - Gump could produce exactly the content that the repository needs. Gump can already publish the created artifacts and in fact it does so http://gump.covalent.net/jars/. It would be possibly to rsync the content from there (or any other machine running Gump) over to minotaur if we find a secure-enough way to do it. Some tweaking of the directory structure may be required for this to work as well. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Is it time for gump.apache.org?
On Fri, 30 Jan 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: But do you really think that three or four people make up a community big enough to warrant a TLP? Just to clarify that. I won't stand in the way of such a move, I just think it's premature. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Oops .... Re: [GUMP@tsws1]: module5 failed
On Tue, 27 Jan 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: As you can guess, I'm working towards nagging (hopefully to real lists) again. +1 Thanks. I'll try not to cause a storm here. I have no problem with you spamming *this* list. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Packaged dom4j and build of jaxen
On Tue, 27 Jan 2004, Scott Sanders [EMAIL PROTECTED] wrote: As it was one thing that I *could* do, I just checked in a code change to make the jdom DocumentNavigator work with the HEAD revision of JDOM's CVS. great, looks very promising. Thanks a lot. Perhaps this can take us one step closer to jaxen/dom4j nirvana :) Yep, the test won't compile, though: [EMAIL PROTECTED] gump]$ ./build.sh jaxen-from-packaged-dom4j dist Buildfile: build.xml init: [mkdir] Created dir: /javastuff/gump/jaxen/target/lib get-deps: compile: [mkdir] Created dir: /javastuff/gump/jaxen/target/classes [javac] Compiling 199 source files to /javastuff/gump/jaxen/target/classes [javac] /javastuff/gump/jaxen/src/java/main/org/jaxen/jdom/DocumentNavigator.java:202: warning: getChildren(java.lang.String) in org.jdom.Element has been deprecated [javac] return node.getChildren(localName).iterator(); [javac]^ [javac] /javastuff/gump/jaxen/src/java/main/org/jaxen/jdom/DocumentNavigator.java:204: warning: getChildren(java.lang.String,org.jdom.Namespace) in org.jdom.Element has been deprecated [javac] return node.getChildren(localName, Namespace.getNamespace(namespacePrefix, namespaceURI)).iterator(); [javac]^ [javac] 2 warnings compile-tests: [mkdir] Created dir: /javastuff/gump/jaxen/target/test-classes [javac] Compiling 23 source files to /javastuff/gump/jaxen/target/test-classes [javac] /javastuff/gump/jaxen/src/java/test/org/jaxen/AddNamespaceTest.java:124: unreported exception org.jaxen.JaxenException; must be caught or declared to be thrown [javac] super( expr ); [javac] ^ [javac] /javastuff/gump/jaxen/src/java/test/org/jaxen/JaxenHandlerTest.java:158: setXPathHandler(org.jaxen.saxpath.XPathHandler) in org.jaxen.saxpath.SAXPathEventSource cannot be applied to (org.jaxen.JaxenHandler) [javac] reader.setXPathHandler( handler ); [javac] ^ [javac] /javastuff/gump/jaxen/src/java/test/org/jaxen/JaxenHandlerTest.java:203: setXPathHandler(org.jaxen.saxpath.XPathHandler) in org.jaxen.saxpath.SAXPathEventSource cannot be applied to (org.jaxen.JaxenHandler) [javac] reader.setXPathHandler( handler ); [javac] ^ [javac] 3 errors BUILD FAILED /javastuff/gump/jaxen/build.xml:112: Compile failed; see the compiler error output for details. Total time: 12 seconds Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Packaged dom4j and build of jaxen
On Wed, 28 Jan 2004, Antoine Lévy-Lambert [EMAIL PROTECTED] wrote: On lsd.student.utwente.nl, the jaxen tests compile, strange, still fails for me on a fresh checkout of Jaxen. I guess target/test-classes must be in the classpath for the Junit tests but are not. Yes, done. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/project jaxen.xml
On Wed, 28 Jan 2004, Antoine Lévy-Lambert [EMAIL PROTECTED] wrote: is this project file used on lsd.student.utwente.nl for the jaxen-from-packaged-dom4j project too ? It is supposed to, yes. Keep in mind that a full run from reading the configuration to actually finishing the last project takes many hours. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Packaged dom4j and build of jaxen
On Mon, 26 Jan 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: http://lsd.student.utwente.nl/gump/packaged-jaxen/index.html http://lsd.student.utwente.nl/gump/packaged-dom4j/index.html [Not sure who added these.] Me, ages ago - while trying to find a way to get things building. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Packaged dom4j and build of jaxen
On Mon, 26 Jan 2004, Antoine Lévy-Lambert [EMAIL PROTECTED] wrote: I have seen that the bits of the dom4j jar file which are used in the gump builds are different in the CVS HEAD version of dom4j, my guess is that they would be OK for jaxen. packaged-* is supposed to be the latest released version of either. I haven't checked back after I've added them, so they may be out of date, though. CVS HEAD of dom4j will not build against the packaged-jaxen we have, it requires something later. I have also built jaxen using the supplied build.xml, The main problem is the jdom dependency AFAIR. Using the supplied build.xml means defeating Gump's purpose as you are building against some uncontrolled (by Gump) dependencies. I'd really suggest using the packaged-* projects as dependencies instead of building an unclean version of jaxen and pretending things would be fine. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Packaged dom4j and build of jaxen
On Tue, 27 Jan 2004, Antoine Lévy-Lambert [EMAIL PROTECTED] wrote: all I would like in a first step is that *someone* (I do not know if I have the rights to do it, and in any case I do not know how to do it) replaces the packaged dom4j jar with this one : http://www.ibiblio.org/maven/dom4j/jars/dom4j-core-1.4-dev-8.jar We are using the final release of dom4j-1.4 which should be more recent than the version you are talking about. Let me repeat, the dom4j version in packaged-dom4j is no problem for the jaxen build, jdom is. No, you don't have the permissions to change the library used, neither have I for all the machines. They are not centrally stored, you'd need access to all machines running Gump instances. I do not know where in the gump metadata the location of static jars is defined, in the profile project name=packaged-dom4j package=dom4j-1.4/ together with pkgdir attribute of the workspace. In any case, if we use this one http://www.ibiblio.org/maven/dom4j/jars/dom4j-core-1.4-dev-8.jar as packaged dom4j I believe that this part of the inferno will cool down. There wouldn't be any difference as the build failures of jaxen-from-packaged-dom4j are only related to jdom. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/project ws-wsrp4j.xml
On 16 Jan 2004, [EMAIL PROTECTED] wrote: +depend project=jakarta-servletapi-4/ I tried servletapi-5 first as this is what pluto uses, but compilation failed with: [javac] /javastuff/gump/ws-wsrp4j/src/org/apache/wsrp4j/producer/provider/pluto/driver/StoredResponse.java:84: org.apache.wsrp4j.producer.provider.pluto.driver.StoredResponse is not abstract and does not override abstract method setCharacterEncoding(java.lang.String) in javax.servlet.ServletResponse [javac] public class StoredResponse implements HttpServletResponse, Serializable [javac]^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant xdocs proposals
On Mon, 12 Jan 2004, Antoine Lévy-Lambert [EMAIL PROTECTED]
wrote:
I have noticed that ant xdocs proposals is failing on most gump
instances,
Largely because xdoclet fails to build.
Normally the jar files which should be used for this build are
checked in in the ant repository under proposal/xdocs/lib.
Well, it is against Gump's declared purpose to use them.
So could one of you guys fix the descriptors
You guys includes you, Antoine, as all Apache committers have commit
access to the Gump repository.
or discuss a way forward to get this built ?
I'd propose to set up a second xdocs project with the xdoclet
dependencies replaced by work entries for the jars in Ant's CVS.
That new project would build and the old will not as long as XDoclet
doesn't build, but will use the latest XDoclet once it builds again.
Other ideas/changes will come next : - generate the xdocs from ant's
build/classes directory + lib/optional (ie what has just been built)
rather than based on ${ant.home}
ant.home is the location of the freshly compiled Ant, it get's set in
the Gump descriptor.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/project jakarta-jmeter.xml
On 9 Jan 2004, [EMAIL PROTECTED] wrote: Oro now 2.0.8 wouldn't it be easier to remove the work entry and rely on ORO's CVS HEAD? ORO is very stable. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/project jakarta-jmeter.xml
On Mon, 12 Jan 2004, Sebastian BAZLEY [EMAIL PROTECTED] wrote: The work entries are for build/test from JMeter CVS. Why do you test against a jar in your CVS instead of ORO's CVS? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] HttpClient HEAD dependencies
On Tue, 06 Jan 2004, Sebastian BAZLEY [EMAIL PROTECTED] wrote: Also, I'd be interested to know what a runtime dependency is - I did not see this anywhare in the Gump docs. Does it mean that the dependency is not needed at compile-time? No, runtime=true means it is needed at compile and at run-time. runtime=false means it is only needed at compilation time. Some things are only needed at compilation time, Ant or XDoclet for example. XDoclet itself needs a couple of projects if you want to run it, these are supposed to marked as runtime dependencies. If you want to use XDoclet, you say inherit=runtime in your project's descriptor and don't have to track all of XDoclet's dependencies manually. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Meaning of runtime (was: [PATCH] HttpClient HEAD dependencies)
On Tue, 6 Jan 2004, Sebastian Bazley [EMAIL PROTECTED] wrote: I think I understand how the inherit relates to the runtime attribute - see above. Yes. I don't understand how the runtime attribute is used *within* a project. Not at all. For example JMeter has several types of dependency: - compile - test (needs the same jars as compile, plus the jars created from the complied classes) - printable docs (uses Anakia - which is not needed elsewhere - and does not need all the other jars) So which of these are runtime? Only those you need to run JMeter. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/project ws-wsrp4j.xml
On 7 Jan 2004, [EMAIL PROTECTED] wrote: Fixed servlet reference Why does Pluto need a different version of the Servlet API? You have three to chose from already (jakarta-servletapi for 2.2, jakarta-servletapi-4 for 2.3 and jakarta-servletapi-5 for 2.4). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best Practices
On 15 Dec 2003, Stefan Bodewig [EMAIL PROTECTED] wrote: Re: don't create full distributions And given Gump's javadoc element, creating javadocs shouldn't be labeled unnecessary work IMHO. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/python/gump/document forrest.py
On 11 Dec 2003, [EMAIL PROTECTED] wrote: We get \ - \\ be careful to not do that on Windows or you'll render file names useless. Ant once had a command line processor that worked almost like a Unix shell - I had to gradually take out any escaping other than putting quotes around arguments as it simply didn't work on Windows at all. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/project jakarta-jmeter.xml
On 11 Dec 2003, [EMAIL PROTECTED] wrote: Gump does not allow spaces in properties - temp fix now it does - at least traditional Gump. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/project jakarta-jmeter.xml
On Thu, 11 Dec 2003, Sebastian BAZLEY [EMAIL PROTECTED] wrote: Presumably if I wanted to include single quotes in the value - which I don't - I would need to escape those, e.g. value=I don't need this - value=I don\'t need this ? This would work on Unix, but probably not on Windows (I'm not exactly familiar with Windows escaping rules). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-gump/stylesheet bash.xsl build.xsl win2k.xsl
I forgot to mention that On 9 Dec 2003, [EMAIL PROTECTED] wrote: Index: gump.xml [...] + sysproperty name=java.awt.headless value=true/ should set java.awt.headless for all builds on gump.covalent.net. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
