Re: CVS woes
I usually do : cvs update -dP . Cheers, Antoine Adam R. B. Jack wrote: Ok, I refactored gump.document today, creating gump.document.text|template|forrest, and I checked them in. I go to a machine to attempt to double check, and I can't seem to get them out of CVS. I see them in CVS (up on the server) or so it appear, but I can't seem to get clients to download them. I am using 'cvs -q update . -dP' -- is that ok? Any help appreciated -- or I break another LSD build in 48 minutes. :( regards Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com - 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: Brutus recently finished & windows of opportunity
Hi Adam, I noticed on brutus some failures of xdoclet which did not happen on lsd. Also now the jaxen from packaged dom4j is failing on brutus. I hope that the jaxen guys did not check in something that does not build. Also, I have been mostly offline the last 2 or 3 weeks. I have relaxed at home a bit, and also at work I have a lot to do. Cheers, Antoine Adam R. B. Jack wrote: Since I dorked all runs last night (with a one character typo :( ) I kicked off a run on Brutus. It just finished (in case this helps anybody): http://brutus.apache.org/gump/public/index.html BTW: Any suggestions for good times for runs? http://brutus.apache.org/gump/public/servers.html regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generating SVG from Python
Adam R. B. Jack wrote: Anybody see an reason (licensing, other) why we should not use this: http://www2.sfk.nl/svg in Gump? [I found nothing else via Google. I also looked on python.org (including in the package index) and in ASPN cookbook.] The license seems OK for me (see below) I'd like to use it to generate some SVG images. I believe that some browsers can render [right term?] them raw (IE just seemed to, albeit slowly), but I also believe that Forrest uses Batik to generate PNG (I assume for browser portability). Again, I'll try to make this optional, so folks don't have to give up the cycles if they don't wish to. I am a SVG fan, so +1. If somebody is interested, I know how to install the Adobe SVG Plugin in FireFox on Windows (not easy, I found some information about this at different places on mozilla forums). I'd like to start simple (perhaps generate some slider type images to show FOG values, etc.) Eventually I'd like to draw some graphs representing dependency tress, etc. Any feedback? Any objections? No Objection ! Cheers, :-) Antoine Here is the license notice I found in the source code of SVGdraw.py (there seems not to be any separate license file). ##Copyright (c) 2002, Fedor Baart & Hans de Wit (Stichting Farmaceutische Kengetallen) ##All rights reserved. ## ##Redistribution and use in source and binary forms, with or without modification, ##are permitted provided that the following conditions are met: ## ##Redistributions of source code must retain the above copyright notice, this ##list of conditions and the following disclaimer. ## ##Redistributions in binary form must reproduce the above copyright notice, ##this list of conditions and the following disclaimer in the documentation and/or ##other materials provided with the distribution. ## ##Neither the name of the Stichting Farmaceutische Kengetallen nor the names of ##its contributors may be used to endorse or promote products derived from this ##software without specific prior written permission. ## ##THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" ##AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE ##IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE ##DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE ##FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL ##DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR ##SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER ##CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, ##OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE ##OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ##Thanks to Gerald Rosennfellner for his help and useful comments. Here a programming example from the same source file : d=drawing() #then you create a SVG root element s=svg() #then you add some elements eg a circle and add it to the svg root element c=circle() #you can supply attributes by using named arguments. c=circle(fill='red',stroke='blue') #or by updating the attributes attribute: c.attributes['stroke-width']=1 s.addElement(c) #then you add the svg root element to the drawing d.setSVG(s) #and finaly you xmlify the drawing d.toXml() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ant xdoc proposal output
Hi, I would like to publish the html generated by ant xdocs proposals, either directly on the ant.apache.org website, or on another location linked from ant.apache.org. What would be the best way of doing this ? Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Speed of brutus
Sam Ruby wrote: Antoine Lévy-Lambert wrote: Hi Adam, I have noticed that some cvs update failed due to /tmp being full. For instance jdom. http://brutus.apache.org/gump/public/jdom/index.html I'm pretty sure that "can't create temporary directory /tmp/cvs-serv" is an indication that there is a problem on the cvs server end. I'll send a note to Jason and Brett to see what's up... - Sam Ruby This is an even better catch Sam ! :-) Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Speed of brutus
Adam R. B. Jack wrote: I see from http://brutus.apache.org/gump/public/ Elapsed Time : 1 hour 56 mins 20 secs I have to agree, I was very impressed with speed. For some reason a little less was built than on LSD, see these, but still -- it is very fast. http://lsd.student.utwente.nl/gump/#Project+Summary http://brutus.apache.org/gump/public/ndex.html#Project+Summary Hi Adam, I have noticed that some cvs update failed due to /tmp being full. For instance jdom. http://brutus.apache.org/gump/public/jdom/index.html Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:
Adam, you did a great job here. :-) Cheers, Antoine Adam R. B. Jack wrote: Due to a conflict, and also to network issues, this commit message didn't get used on all the changes I just did: - Attempt to implement 1) java.awt.headless 2) build.sysclasspath 3) build.clonevm ... so we can control them as needed, not brute force. Hopefully we get an environment more matching traditional (and problems like xdocslets spinning goes away). - Basically I stopped hard coding, and started using the mechanism Stefan created. The command line (at bottom here) ought be what we should expect to see from builds. Hopefully it is correct. Please verify if you can. regards Adam - F:\data\OSS\gump\python>python gump/test/pyunit.py testProperties [...] INFO:gump:Perform [ModelTestSuite::>] Normal Properties: gump.model.property.Property:project1.jar gump.model.property.Property:ant.home gump.model.property.Property:containsSpaces Workspace Normal Properties: gump.model.property.Property:build.sysclasspath Workspace System Properties: gump.model.property.Property:build.clonevm Command Line: java -Dbuild.clonevm=true org.apache.tools.ant.Main -Dbuild.sysclasspath=only "- Dproject1.jar=F:\data\OSS\gump\python\test\gump\module1\dist\lib\output1.jar " "- Dant.home=F:\data\OSS\gump\python\test\gump\module1\dist" "-DcontainsSpaces=a b c '' d e" gump BTW: I'll investigate escaping in parameters. -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build Timed Out
Adam R. B. Jack wrote: Any suggestions? Have you had chance to the thread with subject 'Enigma: build of xdoclet'? There is a rogue build chewing cycles, and hence delaying yours beyond the timeout. regards Adam I do not have time for this issue this week-end. If you just disable somehow the build of xdoclet - preferentially only for gumpy/lsd, but please save all the logs and mail them on the list or put then on a known html location, so that when competent people (Stefan) will have time, they can look at them. Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/blog/SuccessStories jrefactory.txt
Nick, I am not familiar with writing blogs. You can further edit what I wrote. I hope that it will be OK at some stage. And now I am going to be offline, the week-end is beginning, and my kids would like to play on my PCs. Cheers, Antoine [EMAIL PROTECTED] wrote: antoine 2004/03/26 09:13:38 Modified:blog/SuccessStories jrefactory.txt Log: try to improve formatting Revision ChangesPath 1.3 +10 -9 gump/blog/SuccessStories/jrefactory.txt Index: jrefactory.txt === RCS file: /home/cvs/gump/blog/SuccessStories/jrefactory.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jrefactory.txt 26 Mar 2004 17:02:55 - 1.2 +++ jrefactory.txt 26 Mar 2004 17:13:38 - 1.3 @@ -29,28 +29,29 @@ As a consequence, the acceptable values for the lineending setting of PrettyPrinter changed to become the one's of ant's fixcrlf task. - + This caused the build of xdoclet to fail around mid January. - + I entered a bug report in the bug tracking system of JRefactory, and also asked the xdoclet team to adapt their build file to the new behavior of PrettyPrinter, which they did. http://sourceforge.net/tracker/index.php?func=detail&aid=877400&group_id=13219&atid=113219";> pretty.settings end.line property comments need a fix - + Mike Atkinson seems to have worked on this issue yesterday (March 25th 2004). - - + + jaxen/saxpath changes - + Due to changes in jaxen, which has absorbed saxpath, JRefactory had a compilation failure. - + I sent a mail to the JRefactory mailing list on the 24th of March, and Mike Atkinson fixed the faulty org.acm.seguin.pmd.jaxen.DocumentNavigator yesterday (March 25th). - + So, yes, human nagging is effective. When it is effective, and how you do -it diplomatically is another issue. \ No newline at end of file +it diplomatically is another issue. + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump on Moof
Adam Jack wrote: I know we are about to install on new hardware, but do we wish to send the moof install live? Surely having an OSX run is a good thing, since it allows greater coverage. If we chose to proceed, I think we need: 1) A 'gump' account on moof that we can su to. 2) A cronjob in that account (with environment set up). 3) Perhaps tomcat/forrest installed (for webapp xdocs). regards, Adam Sounds good, Antoine PS : I am impressed by the work you are doing on gump Adam. Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Enigma : build of xdoclet
The build of xdoclet is : - succesful on covalent, - failing on lsd. This is a strange problem. On lsd it looks like the build is recursively invoking itself, judging at the log which is getting crazily indented [builder] [builder] [builder] [builder] [builder] [builder] [builder] Cheers, Antoine http://gump.covalent.net/log/xdoclet.html http://lsd.student.utwente.nl/gump/xdoclet/gump_work/build_xdoclet_xdoclet.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jrefactory building again on gump
Thanks JRefactoriers, particularly Mike concerning the changes you have committed which make jrefactory build again on Gump. I am wondering whether [EMAIL PROTECTED] is in fact the same as [EMAIL PROTECTED] I have also noticed that your mail list does not seem to be archived any where, and I am not getting what I am sending to your list, even though I am subscribed to it,. Cheers, Antoine [1] cvs update : http://lsd.student.utwente.nl/gump/jrefactory/gump_work/update_jrefactory.html [2] project results http://lsd.student.utwente.nl/gump/jrefactory/jrefactory.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: last night's build on lsd
Adam Jack wrote: I hate to say it, but sometime we really 'pay' (in terms of workarounds, outages, time delays) for the decisions to go with forrest. I don't know if we ought consider it 'yet another Gump stress test' and keep it, but I am starting to think more and more of writing HTML pages directly, via some Python code. I also thought forrest is a good product. But if it takes ages to generate the pages, we should move to something else. As you said, a pure python solution makes sense. Might be a lot of work though. Talking of stress, gump.dotnot is taking almost a day... http://gump.dotnot.org/#Details I'm thinking of giving Gump a shot on moof. Do you think this is a good idea, or just going to damage another server? It cannot damage the server. Go for it ! regards, Adam Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
last night's build on lsd
It looks like the gump run did not work on lsd last night. I did not have a look to find out what has gone on. (the html pages on lsd are of yesterday, the email all dressed up with nowhere to go did not get sent either) Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project xdoclet.xml
The build of xdoclet is a masterpiece of complexity. I wonder whether we should not rename the xdoclet project docs and invoke directly the build-docs.xml build file. I would need to check in this case which properties we would have to set. Cheers, Antoine [EMAIL PROTECTED] wrote: antoine 2004/03/24 14:26:04 Modified:project xdoclet.xml Log: squeeze xjavadoc dependency checking Revision ChangesPath 1.64 +2 -0 gump/project/xdoclet.xml Index: xdoclet.xml === RCS file: /home/cvs/gump/project/xdoclet.xml,v retrieving revision 1.63 retrieving revision 1.64 diff -u -r1.63 -r1.64 --- xdoclet.xml 2 Mar 2004 23:04:07 - 1.63 +++ xdoclet.xml 24 Mar 2004 22:26:04 - 1.64 @@ -143,6 +143,8 @@ + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
build of xdoclet on gump
Hello xdoclet developers,
I am participating to the gump team.
For those of you who do not know yet, gump is a social experiment.
And concretely a night build system, which builds a number of open
source projects
based on CVS or svn head revisions.
Gump tries to build xdoclet, but there is a small problem I think with
the dependency upon javacc.
I am sending you a patch for your build.xml, so that xjavadoc.jar
becomes a property which can be overridden from outside.
Cheers,
Antoine
Index: build.xml
===
RCS file: /cvsroot/xdoclet/xdoclet/build.xml,v
retrieving revision 1.30
diff -u -r1.30 build.xml
--- build.xml 26 Nov 2003 00:56:37 - 1.30
+++ build.xml 24 Mar 2004 21:51:24 -
@@ -4,6 +4,7 @@
+
@@ -14,8 +15,8 @@
XJavaDoc sources are available. Checking against
${lib.dir}/xjavadoc-${xjavadoc.version}.jar
-
+
@@ -45,7 +46,7 @@
http://xdoclet.sourceforge.net/repository/xjavadoc/jars/xjavadoc-${xjavadoc.version}.jar";
- dest="${lib.dir}/xjavadoc-${xjavadoc.version}.jar"/>
+ dest="${xjavadoc.jar}"/>
@@ -132,7 +133,7 @@
-
+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
build of jrefactory
Hi Jrefactoriers,
I am not sure whether you are aware of it : your project is built with gump,
or more exactly gump tries to build it.
See this URL :
http://lsd.student.utwente.nl/gump/jrefactory/jrefactory.html
/data3/gump/jrefactory/src/org/acm/seguin/pmd/jaxen/DocumentNavigator.java:193:
parseXPath(java.lang.String) in
org.acm.seguin.pmd.jaxen.DocumentNavigator cannot implement
parseXPath(java.lang.String) in org.jaxen.Navigator; overridden method
does not throw org.saxpath.SAXPathException
[javac] public XPath parseXPath(String arg0) throws
SAXPathException {
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 1 error
BUILD FAILED
/data3/gump/jrefactory/build.xml:371: 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)
Saxpath has been integrated into jaxen, and I guess that
org.jaxen.Navigator API has changed.
Can you adapt to all these changes.
Also gump has a feature called "nagging". nagging means that an
automatic email gets sent when your project fails to build.
Can I set up gump to nag you ?
Thanks in advance, and cheers from Walldorf.
Antoine
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jrefactory failure [was BATCH: All dressed up, with nowhere to go...]
Stefan Bodewig wrote:
[EMAIL PROTECTED]: jrefactory/jrefactory failed
See webwork. It would probably suffice to turn the pretty printer it
into an installed package.
The problem of jrefactory is that they need to react to the fact that
saxpath is now part of jaxen,
/data3/gump/jrefactory/src/org/acm/seguin/pmd/jaxen/DocumentNavigator.java:193:
parseXPath(java.lang.String) in org.acm.seguin.pmd.jaxen.DocumentNavigator
cannot implement parseXPath(java.lang.String)
in org.jaxen.Navigator; overridden method does not throw org.saxpath.SAXPathException
[javac] public XPath parseXPath(String arg0) throws SAXPathException {
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 1 error
BUILD FAILED
/data3/gump/jrefactory/build.xml:371: 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)
They probably could remove their dependency to saxpath too.
I am going to bug them, and see whether I will be lucky.
Antoine
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project jrefactory.xml
Stefan, thanks for your comments, I have just checked in what you have suggested. collect.jar in jrefactory is not common-collections from apache (judging by the package names java.lang. ... ) It looks like something coming from Sun, and having to do with reflection or something like that, I am not sure what it exactly is. Cheers, Antoine Stefan Bodewig wrote: On 23 Mar 2004, <[EMAIL PROTECTED]> wrote: + + + + + + + + + + + + + + + + + ugly. Any idea what the contents are? bcel.jar sounds like jakarta-bcel, collect could be commons-collections. JAI could be an installed package if other projects need it as well. saxpath is already somewhere as an installed package. In general I'd rather use a technique like inside the module combined with in the project for jars in CVS. This enables us to switch between using a jar from CVS, using an installed package and building a project from scratch more easily. 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: cvs commit: gump/project jrefactory.xml
[EMAIL PROTECTED] wrote: antoine 2004/03/23 12:55:05 Modified:project jrefactory.xml Log: changed the target invoked for the jrefactory alone Revision ChangesPath 1.16 +20 -1 gump/project/jrefactory.xml Index: jrefactory.xml === Adam, can you do a sanity check on my changes. I changed the target invoked for the project jrefactory, because the all target redid the pretty project (I guess we do not want to build a project twice in a run), and also it deleted the original jar produced in pretty and rebuilt it under another name, which the dependencies of pretty (xdoclet) did not know. Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] href considered harmful
Adam Jack wrote: Gump is a social experiment, and this part of the experiment has shown to be a negative and annoying factor. I feel that my own recent experiences with jicarilla are an excellent example: even with an active and experienced member of the core gump group trying to actively maintain gump descriptors in sourceforge cvs, things break and the workflow is nothing short of a nightmare. It is a tough decision to remove a feature (like href) that has such potential for 'community outreach'. It seems such a good idea (to avoid CVS bound, and distribute responsibility) and that it can't be bad, can it? I think it can... I think we have to review exactly where we stand w.r.t to the Gump workflow, and recognize that we tried to distribute metadata management too soon for the communities. Sure, for an expert Gump metadata is simple, but it does have a lot of complex choices (to support reality). The combinatorials of Gump metadata (when merged) are quite daunting. With no generator/wizards/overviewer/compiler/tester we are expecting the community to throw metadata up to us and hope it runs. That is counter productive to our goal of happy communities. Gump metadata is like having a complex development in a runtime interpreted language with nightly runs based upon untested code in a repository. This is analogous to punch cards & batch runs and requests more patience/discipline/investment than communities will give. [Heck, this *is* the early days of my writing Gumpy in Python checking in to test remotely, prior to getting some unit tests. ;-) Hard, hard, work --a frustrating bad development environment.] Adam, I agree very much with all you have written. May I ask you another question : if I would like to replace the use of ls and cat in gumpy with pure python code (like sync), do you have any suggestions ? Do we already have testcases for the use of ls and cat in the tools.py ? Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: User id that runs Gump on moof (and LSD...)
I am also +1 I am also +1 on the idea of the "gump user". Impersonal users are often used by organizations setting up automated jobs. I have seen impersonal users used for : - running application servers in a bank, - running builds in a large software house, The impersonal user is a good medium to make sure that an application will go on running, whoever takes care of managing it, and whatever the vagaries of personal turnover in open source organizations or in for-profit companies. Adam R. B. Jack wrote: what we could also do is create a 'gump' user, and give multiple people the password. Alternatively, we don't give out the password, but add multiple people's keys to the authorized_keys file. I've always frowned on shared user ids (assuming they were excuses for not getting group permissions right) but that isn't the case here, we are working around an SVN bug. [If the bug really does only have a life expectancy of a few weeks, the rollout might take longer.] As such +1 to this idea. So long as gump is a member of the gump group, that we all have ids within, then it can be easily obsoleted once unecessary. I don't like the single point of failure we have now at all. 100% agreed. Anybody know how to do a share cronjob any other way? No. I do not know how to share a cronjob without an impersonal user. Also, one can only control (kill) the processes of one's own UNIX user. I'm also supposed to be catching a train in five mins so I don't have time to change anything over there right now. I agree, it'd be daft to do a quick transition without everybody around. That said, what I am really hoping for is: 1) Grant folks access to live/working Gumps so they can do 'quick runs' (like python gump/debug.py xmlunit --debug --quick, to test properties, etc.) 2) Grant folks access to live/working Gumps to spread the knowledge, and get more input/opinions on how to install this nicely. 3) Get documentation for the installs into the wiki, and that documentation come from somebody unfamiliar with the config, so they explain it better. I hope that we can still get these. regards Adam5o Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: User id that runs Gump on moof (and LSD...)
Thanks for all these precisions Adam. I will get started working on this on Monday. Have a nice week-end too. Antoine Adam R. B. Jack wrote: There are lots of things I do not know about lsd. Ok, so perhaps you can have LSD and then Stefan and/or Stefano could have moof. Leo, of course LSD is yours (if you want it) for as long as you allow us left to use it. LEo, you get to chose since you have to do the 'chown -R' on the tree. :-) It might help if you can email me the .profile or equivalent that you use on lsd and on moof, so that I know how you set up your path, or in other words where are all the critical utilities like maven, svn, cvs, *forrest* Basically I need help with this. I am not a good enough *nix user (these days) to figure out the "correct" way to set a .profile that things in cron get to benefit from. I'd really like to have folks help clean that up, if at all possible. svn/cvs are installed by root (Mr Simmons) and so are whereever they are... Unfortunately I installed maven and forrest into ~ajack/opt. Maybe Leo could move them into /data3/gump/gump-install/opt or something. /data3/gump/opt is where the packages are. [EMAIL PROTECTED] gump-install]$ more local-env-py.sh export ROOT=/data3/gump export GUMP=$ROOT/gump-install export GUMP_WS=$ROOT/ export GUMP_LOG_DIR=$ROOT/log export FORREST_HOME=/home/ajack/opt/forrest export PATH=$PATH:$FORREST_HOME/bin export MAVEN_HOME=/home/ajack/opt/maven-1.0-rc1 export PATH=$PATH:$MAVEN_HOME/bin export JAVA_HOME=/usr/java/j2sdk1.4.2/ export CLASSPATH=$JAVA_HOME/lib/tools.jar export PATH=$PATH:$JAVA_HOME/bin BTW: CVS puts a .cvspass in $HOME and I see others, from maven, and such. I suspect these will get re-created. BTW: There is private information in the lsd.xml in the install directory, please *never* post it, or check it in to CVS, or anything like that. Also, LSD.xml is marked as private="true" for that reason. If you have a crontab on lsd, do you want to email me the contents ? Here it is: # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.3967 installed on Sun Feb 29 20:27:58 2004) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) 0 2 * * * cd /data3/gump/gump-install; /bin/nice -n 15 /bin/bash /data3/gump/gump-install/gumpy.sh This is quite possibly overkill, but it is complete. Basically we have gump in /data3/gump/gump-install becase (on LSD only) /data3/gump is also the workspace directory. [We had an issue where some files (statistics) are still stored under the install, not under the workspace basedir (still do, I ought enter that in JIRA), and the CVS update/sync was wiping stuff out.] I might also try to get moof running. Next week, I should have time to work on gump, I will be staying in Walldorf until Thursday, Let's try to spread the wealth/chaores, IMHO. Stefan or Stefanoi or Leo or other want Moof? BTW: Here is my request. For each person taking over a machine, please document that machines config/set-up in the wiki. [I think Leo asked for this in a JIRA entry.] regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: User id that runs Gump on moof (and LSD...)
Adam R. B. Jack wrote: Since I have LSD running under 'ajack' as are gump.try.sybase.com and gump.dotnot.org, I think we need somebody else's id to run the Apache Python Gump on moof. This is especially important with me going away next week. I think it has to be one id (sadly) because an SVN bug (which I hear might get fixed in a few weeks) does nasties with the permissions on the .svn/entries file. Any takers? BTW: I'm also game to spread the wealth and give up on my id being the one on LSD, if folks things that is a good idea. regards, Adam There are lots of things I do not know about lsd. It might help if you can email me the .profile or equivalent that you use on lsd and on moof, so that I know how you set up your path, or in other words where are all the critical utilities like maven, svn, cvs, *forrest* If you have a crontab on lsd, do you want to email me the contents ? I might also try to get moof running. Next week, I should have time to work on gump, I will be staying in Walldorf until Thursday, Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: User id that runs Gump on moof (and LSD...)
Hi Adam, I take it, unless someone else volunteered before me. Antoine Adam R. B. Jack wrote: Since I have LSD running under 'ajack' as are gump.try.sybase.com and gump.dotnot.org, I think we need somebody else's id to run the Apache Python Gump on moof. This is especially important with me going away next week. I think it has to be one id (sadly) because an SVN bug (which I hear might get fixed in a few weeks) does nasties with the permissions on the .svn/entries file. Any takers? BTW: I'm also game to spread the wealth and give up on my id being the one on LSD, if folks things that is a good idea. regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: can we upgrade java@lsd to 1.4.2_04 from 1.4.2-b28 ?
Antoine Lévy-Lambert wrote: We currently have this version of Java on gump : java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Michael Glavassevich wrote that we should upgrade to : JDK 1.4.2_04 which is actually present there : http://java.sun.com/j2se/1.4.2/download.html in order to be able to build xml-xerces1. Cheers, Antoine Sorry, I posted this one while you were posting your own message, Have a good evening Adam, Cheers from Walldorf, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
can we upgrade java@lsd to 1.4.2_04 from 1.4.2-b28 ?
We currently have this version of Java on gump : java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Michael Glavassevich wrote that we should upgrade to : JDK 1.4.2_04 which is actually present there : http://java.sun.com/j2se/1.4.2/download.html in order to be able to build xml-xerces1. Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build of jakarta-pluto - gump or gumpy problem ?[was : Persian enigma]
Antoine Lévy-Lambert wrote: The project descriptor for jakarta-pluto says this : and the jars exist at these locations, ie for instance : /data3/gump/jakarta-pluto/container/target/pluto-1.0.jar but gumpy looks for : /data3/gump/jakarta-pluto/temp/container/target/pluto-1.0.jar which does not exist. the jakarta-pluto.xml file also contains these lines : I think I misqualified the problem. I have just changed the project descriptor for jakarta-pluto, removing these home related settings. I wonder whether, to the contrary, traditional gump does not check the presence of the jars listed in the descriptor. And should check ? Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gumpy bug building jakarta-pluto ? [was : Persian enigma]
The project descriptor for jakarta-pluto says this : and the jars exist at these locations, ie for instance : /data3/gump/jakarta-pluto/container/target/pluto-1.0.jar but gumpy looks for : /data3/gump/jakarta-pluto/temp/container/target/pluto-1.0.jar which does not exist. the jakarta-pluto.xml file also contains these lines : Julie MacNaught wrote: There is a similar problem with jakarta-pluto. I.e. builds on covalent, not on lsd . Julie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build of xml-xerces 1 on gump@lsd
Michael, thanks for informing us, I am pretty sure that we will fix lsd as soon as we can then. Cheers, Antoine Michael Glavassevich wrote: Hi Antoine, I understand that this was a compiler bug [1] which was recently fixed in JDK 1.4.2_04 [2]. Whomever's responsible for the environment on lsd may want to upgrade the JDK. [1] http://developer.java.sun.com/developer/bugParade/bugs/4863451.html [2] http://java.sun.com/j2se/1.4.2/ReleaseNotes.html Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [EMAIL PROTECTED] E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Persian enigma
Stefan Bodewig wrote: On Mon, 15 Mar 2004, Antoine Lévy-Lambert <[EMAIL PROTECTED]> wrote: what does Xvfb mean ? a virtual frame buffer X server. An X server that writes into memory and doesn't display anything anywhere. It could also be a different locale setting since Gump seems to use a different locale when it gets run by cron on my machine. when it fails on you, do you get the same compilation errors as gumpy, Yes. Stefan Stefan, which is the locale setting in which you run the build ? - when you do it by cron, - when if fails on you ? the X frame server does not seem like a good explanation, the locale is more appealing. can we reasonably ask the xml-xerces developers to change the source file which is causing the problem (after all it is only in JavaDoc comments that we have problems). Since I think they want to display a backslash in html, maybe changing \u005c into \ would give the same result and not be sensitive to locale setting on the gump machine. Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Persian enigma
Stefan, what does Xvfb mean ? when it fails on you, do you get the same compilation errors as gumpy, (a complaint about forbidden \u escapes). I have had a look (using Excel, thanks M$) to find out what the forbidden unicode escape actually is, I think it is a back slash (92 in decimal). Antoine Stefan Bodewig wrote: On Mon, 15 Mar 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote: The only differences I see are the two system properties since I run Xvfb and set DISPLAY accordingly. It just failed for me when I run ./build.sh xml-xerces1 jar in an xterm without using Xvfb. This looks really strange. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Persian enigma
xerces1 builds with classical gump, but not with gumpy. Anybody has an idea, why this Persian Monarch does not like Pythons ? Antoine [1] http://gump.covalent.net/log/xml-xerces1.html [2] http://lsd.student.utwente.nl/gump/xml-xerces/xml-xerces1.html [3] http://article.gmane.org/gmane.comp.jakarta.gump/4847 The command line on lsd is : java -Djava.awt.headless=true -Dbuild.clonevm=true org.apache.tools.ant.Main -debug -Dgump.merge=/data3/gump/gump-install/work/merge.xml -Dbuild.sysclasspath=only jar 4 of this type of compilation errors happen there : /data3/gump/xml-xerces/java/build/src/org/apache/xerces/utils/regex/ RegularExpression.java:139: illegal unicode escape [javac] * \u005cuc, \L, \U, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
build of xml-xerces 1 on gump@lsd
Gump is building xml-xerces1 with the CVS tag xerces_j_1 This tag contains the offending source file org.apache.xerces.utils.regex.RegularExpression org.apache.xerces.utils.regex.RegularExpression is in the Attic in CVS HEAD. Do we want to change the definition of the project xerces1 to say that the jar file is frozen ? (which means stopping building, just using a particular jarfile instead) If we want to try and build xerces1 every night in the gump run, then we would need a fix for this problem. No clue what kind of fix would make sense. Cheers, Antoine Footnotes [1] http://cvs.apache.org/viewcvs.cgi/xml-xerces/java/src/org/apache/xerces/utils/regex/#dirlist [2] http://lsd.student.utwente.nl/gump/xml-xerces/xml-xerces1.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with build of jakarta-slide
Adam R. B. Jack wrote: Hmm, maybe the issue was that the dodgy characters in log4j-test were killing the forrest, so the pages were stale. I hand ran the forrest about the time you sent this, and right now it shows success (with a duration of 1). http://lsd.student.utwente.nl/gump/jakarta-slide/jakarta-slide.html :-) Good that you found that out. I was wondering whether we had problems in the sync of Gumpy, or ant problems, ... I would have suspected the whole world :-( Still, what you are asking is interesting, it is interesting to see the things that a build does, that vary from CVS|SVN. I wonder if we ought allways do such a diff -r, for curiosity reasons: A cleanup of the CVS/svn subdirs in the different project directories on lsd would make sense. (Because now we have stale, misleading CVS/Entries files in the CVS subdirs of the projects dirs.) Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump on moof
I would like also to be in this group. Cheers, Antoine Stefan Bodewig wrote: On Fri, 12 Mar 2004, Adam R. B. Jack <[EMAIL PROTECTED]> wrote: Somebody mind creating a /use/local/gump directory that the gump group has permissions to? And please add me to that group while you are at it. Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with build of jakarta-slide
Adam R. B. Jack wrote: can you check whether gumpy *syncs* properly on lsd. You don't have unfailing confidence in your code? ;-) No, unfortunately, I do not have unfailing confidence in my code. :-( Actually, I might have busted it w/ that skip directories like .svn|CVS that I added yesterday. Don't know. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with build of jakarta-slide
Hi Adam, can you check whether gumpy *syncs* properly on lsd. Stefan http://article.gmane.org/gmane.comp.jakarta.ant.devel/28636 wrote that Slide should build. I have seen that jakarta-slide/build.xml and jakarta-slide/testsuite/build.xml have been synced from CVS last night. Can you check whether the files have been copied afterwards from /data3/gump/cvs/jakarta-slide to /data3/gump/jakarta-slide ? Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RT] gump doing progress
Some random thoughts, lately I have not been able to contribute much, my employer makes me work too. ;-) I have the impression that we are progressing. For instance, I like very much that Niclas is trying to fix the avalon builds. Also with jakarta-slide, Unico Hommes is working to solve an issue with a property jdom.jar which was badly defined or used in the testsuite subproject (he has checked in some changes today which should make the next run successful, at least I hope so, I did not test it). I think that once the excalibur-logger will build, we will reach a much higher success percentage - unless we see down the road some other showstoppers. Gump is really useful. Without gump, I am not sure whether the problems with the changes of API of jdom and the consequences for velocity and jakarta-slide would have been detected. And fixed. I also read about the issues between Struts and velocity-tools, this sound interesting too. I have read the threads about "Moving gump forward". I am sure a Web Application to edit the metadata of gump can be nice. But I am not unhappy just editing xml files by hand and checking them into CVS. If we have a Web Application, it will have to be fast and confortable to bring a real progress in comparison with the plain xml files. I also agree with others that storing gumps metadata into a relational database is certainly awkward. I wonder whether it is not best to stick to xml files, may be have the Web App do cvs commits when changes are done ? xml database(s) would be seducing for this type of things, but I think gump should remain simple. The drawback of developing a Web App will be that when we will want to add new fields or change the schema in some ways, we will have to change gumpy and the Web App. I did not try the python UI which already exists for editing the metadata, maybe we should consider maintaining and extending it rather than going to the Web App solution ? Fat graphical clients have advantages over Web interfaces, they can be more appealing present nice widgets which are difficult to mimick in a servlet or jsp. Last thought, concerning the docu, from project/ws-juddi.xml I did not see in the documentation how this tag is specified. Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven ibiblio update problem for the jdom team
I have read this on the jdom list, and I thought that someone on the gump list might know about that. Original Message Subject:Re: [jdom-interest] XPath problem using org.jdom.xpath Date: Thu, 11 Mar 2004 08:48:30 -0600 From: Bradley S. Huffman <[EMAIL PROTECTED]> To: Laurent Bihanic <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Laurent Bihanic writes: Jason, would it be possible for you to recompile Jaxen and update the jaxen-jdom.jar in both CVS and the JDOM beta10 distribution ? And if someone actually does this could they tell me the secret to getting Maven to quit barfing because jdom-b10.jar isn't in the repository on ibiblio. Changing the URL in project.xml or build.xml doesn't seem to work. Many, many thanks to Jason or whoever put build.bat and build.sh in the CVS so once you download the code, you can type one command, and it actual works. I wish other projects would follow suit. Brad ___ To control your jdom-interest membership: http://lists.denveronline.net/mailman/options/jdom-interest/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Gump Wiki] New: GumpScripts
Adam,
thanks for all this docu.
It contains everything I always wanted to know about Gump, but was
afraid to ask.
Cheers,
Antoine
[EMAIL PROTECTED] wrote:
Date: 2004-03-07T10:54:40
Editor: AdamJack <[EMAIL PROTECTED]>
Wiki: Gump Wiki
Page: GumpScripts
URL: http://wiki.apache.org/gump/GumpScripts
no comment
New Page:
=GumpScripts=
There are a number of scripts available, all with the same commandline interface.
* gump/update.py -- just does the CVS/SVN updates
* gump/build.py -- just does the build portions
* gump/check.py -- checks the various entities (projects/modules)
* gump/integrate.py -- does it all
* gump/gui/view.py -- a GUI (work in progress)
= Commandline Interface =
All scripts take the following:
-w {workspace} [project expression [--verbose|--debug]]
e.g.
-w ../gump.xml jakarta-*
-w ../gump.xml all --debug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: feature request: top critical failures
Stefano Mazzocchi wrote: Dear gumpmaisters, excalibur-logging is breaking basically 40% of our tree and nobody gives a damn. Hi Stefano, Actually in the last one or two months, I have been "giving a damn" as you said. With the participation of the corresponding communities, and the help of Stefan Bodewig, we got a number of builds with a lot of dependencies, located upstream of excalibur-logging, repaired : - jaxen, - dom4j, - xml-fop, - .velocity But you are right, if the number of dependencies is displayed, it will be easier to detect the spots which are harming a lot gump. Concerning excalibur-logging : The build file of excalibur-logging does not match the source tree of this component, and expects java sources to be at a place where they are not. I will try to suggest a new build.xml to the avalon team for this component. May be it could be built with Maven, but I do not know Maven, and I do not know either the interface between gump and Maven. I am also wondering whether we should not define some gump best practices for ant build files of individual projects : - the full path of each dependency jar should be a property, not just the name of the jar (so that gump can override the property properly) - preferably, the build.xml of each project should not attempt to build another project, or there should be a way for gump (by setting properties) to prevent this from happening. I am thinking here about xdoclet. xdoclet is expecting xjavadoc to be in a parallel source tree ( ../xjavadoc ) which is OK for gump and tries to build the xjavadoc.jar (not good) when the xdoclet build file thinks the xjavadoc.jar is not uptodate with the sources. I will give a shout to the xdoclet guys concerning this later. The point I am trying to make is that : *A good build file (for gump) is a simple build file* Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/python/gump/test sync.py pyunit.py
Thanks for all your comments. I am going to do the changes that you are suggesting, and check them in early next week. Cheers, Antoine Adam R. B. Jack wrote: this is my first attempt at doing something in Python for gumpy. Awesome, I can't wait for us to be free of the bonds of 'rsync'. (I don't know how we'll get a feel for this, when thrown into the deep end w/ the CVS/SVN data we have, but I guess we wait a little then just plunge.) Since this code is not called from any where yet, it should not break gumpy, the worst thing which could break are the tests. Great, we'll see how those go for a while then migrate. First, it seems you really figure this stuff out -- including my home grown pyunit stuff, cool. Second, in checking these out I noticed a couple of minor things: - In Sync.execute if you change the except below to makedirs to a finally, we ought get an exception when (if ) makedir fails. - It see that epurate is called unconditionally, could there be an optional switch on Sync to do that, or not? If we are to replace cp as well as rsynch we need 'copy on top of w/o clean-up'. A ponderance: - If we made the functions at the bottom of the module into methods on the class, and if we made Sync inherit from Annotatable (& call Annotatable.__init__(self) in __init__, we could log information to the object, and then (if we wanted to know what was done, perhaps for debugging) we could copy those annotations off (perhaps transfer them to the Module object for listing in the forrest page.) By the way, I have run the tests under Windows and Boa Constructor with Python 2.2. They run for me using Activestate Python 2.3. :-) [I know I ought work on 2.2, but I was hoping we could move. I'll test this on Linux on 2.2 sometime soon.] I have seen that the logging sometimes work and sometimes not. Gosh, interesting. I've never see that. I also never (overtly) noticed the logging config making much difference, I assumed that writting to stderr was the default. Could it be that in some cases your output is buffered and that output not sync'ed? [No pun intended. ;-)] I'm clutching at straws, I've no idea... Under cygwin I can run my test OK under Python 2.3.3 cygwin version. This is just to be thorough, I take it, to ensure you cope in case folks do -- but they oughtn't (right) for other reason (launching Java/Ant) that you've stated before. Right? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Descriptor Location...
Adam R. B. Jack wrote: This is cool ! No need to grep through the metadata xml files any more. Cheers, Antoine ... is working again: http://lsd.student.utwente.nl/gump/gump_xref/descriptor_project.html [The reverse of this page is on each project/module.] The bug was (is) related to this, but I've only put a workaround in place. http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-22 regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/python/gump/test sync.py pyunit.py
Hi, this is my first attempt at doing something in Python for gumpy. Since this code is not called from any where yet, it should not break gumpy, the worst thing which could break are the tests. By the way, I have run the tests under Windows and Boa Constructor with Python 2.2. I have seen that the logging sometimes work and sometimes not. I mean that if I set the log level to debug, under Windows I sometimes see the log messages in the output window of Boa and sometimes not, both for my test and for other tests. What is the issue there ? Does it have to do with some tests changing the current directory, which then prevents the logging module from finding the logging configuration, or is this something more subtle or a Python bug or ... Under cygwin I can run my test OK under Python 2.3.3 cygwin version. Cheers, Antoine [EMAIL PROTECTED] wrote: antoine 2004/03/04 13:38:47 Modified:python/gump/test pyunit.py Added: python/gump/utils sync.py python/gump/test sync.py Log: a sync utility with 4 unit tests - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: [PROPOSAL] End Gump builds for sandbox projects]
I am not sure whether this email reached the gump list. Forgive me if this is spam. Antoine Original Message Subject: Re: [PROPOSAL] End Gump builds for sandbox projects Date: Wed, 3 Mar 2004 23:26:17 - From: Stephen Colebourne <[EMAIL PROTECTED]> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> To: Jakarta Commons Developers List <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> I found this description of Gump and future aims quite interesting. So I'll withdraw this proposal. Stephen - Original Message - From: "Adam R. B. Jack" <[EMAIL PROTECTED]> > This is a proposal to begin to end the abuse of the sandbox. (The sandbox > was intended as a temporary 'play area' for new ideas, not a long term > project home) This is a fascinating approach, and not unlike something that drove me towards Gump in the first place. I was a heavy user of a common (sandbox) project that after a lot of (user) investment on my part went badly stagnant. I felt pretty mift, and wished I had some metrics (or similar) to help me make my choices of dependencies in the first place. I turned to Gump to attempt to determine which projects were healthy (stagnant isn't a bad thing for a feature rich, stable product, with a stable stack below it) and which weren't. I feel it is only 'open' to give an assessment of a project's status, and what better way that the 'googlesque' (I'm sure it is a word waiting to enter the dictionary ;-) approach of letting community usage/satisfaction do the talking. Increase the rating of a project by using it, depending on it. Decrease it by walking away (as I did) breaking dependency. Here Gump attempts to 'rate' a project by 'FOG Factor' (eventually something mystical, a combination of all, but right now a ratio of successes verse failures, including those of the dependency stack) : http://lsd.student.utwente.nl/gump/gump_stats/project_fogfactor.html This is by 'count of dependees' (how many projects depend on the project): http://lsd.student.utwente.nl/gump/gump_stats/module_dependees.html This is by last updated (on the module) - yup, sadly bogus for commons, I know. :( http://lsd.student.utwente.nl/gump/gump_stats/module_updated.html Gump is far from done, we'll work with folks to create new views/new stats, but it is amasing valuable (albethem statistical) insights into projects on a daily basis. As such - please do NOT remove these things from Gump, please help us use Gump to publically determine the wheat from the chaff, whilst you apply PMC or peer means to clean house of projects that have failed to achieve mass. Gump might be in a position (especially with help of users like you seeking solutions) to help you determine what course of action to take for each component... - 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]
problem with the build of xdoclet
In the build of the night from the 1st to the 2nd of March xdoclet did
not build.
What actually happened is that it tried to rebuild xjavadoc, but did not
have javaCC in the classpath to do it.
The build.xml of xdoclet contains this snippet :
targetfile="${lib.dir}/xjavadoc-${xjavadoc.version}.jar">
I would rather like
targetfile="${xjavadoc.jar}">
In the later case we can set the property xjavadoc.jar before the build
of xdoclet starts, and then it will be found.
Are you OK that I should go ahead and ask the xdoclet guys to do this
change ?
Antoine
Footnotes
[1]
http://cvs.sourceforge.net/viewcvs.py/xdoclet/xdoclet/build.xml?view=markup
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] please update logging/build.xml for the sake of gump !!!
Hi,
The gump build of jakarta-commons/logging is failing. [1]
I have attached a patch for the build.xml [2]
Thanks in advance for submitting it quickly, so that it is OK in the
next Gump run.
Antoine
Footnotes :
[1] http://lsd.student.utwente.nl/gump/jakarta-commons/commons-logging.html
[2] http://cvs.apache.org/viewcvs.cgi/jakarta-commons/logging/build.xml
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-commons/logging/build.xml,v
retrieving revision 1.42
diff -u -r1.42 build.xml
--- build.xml 2 Mar 2004 21:02:51 - 1.42
+++ build.xml 3 Mar 2004 13:22:27 -
@@ -418,8 +418,6 @@
todir="${dist.home}"/>
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Problems with the gump builds on lsd and on gump.covalent.net - http access
Hi,
I am seeing a number of problems with the gump builds on lsd and on
gump.covalent.net.
It looks like some builds are trying to get resources from the Internet
and are failing there :
example : *rhino* [1] [2]
yesterday, I also noticed a failure of the build of *commons-codec*
hanging 1 hour in the javadoc generation on lsd.
The build.xml of jakarta-commons/codec contains the following line in
the javadoc task :
link="http://java.sun.com/products/jdk/1.3/docs/api/";>
Another subproject of jakarta-commons had the same problem too.
Can it be that javadoc then visits the sun web site to find out which
packages are present under http://java.sun.com/products/jdk/1.3/docs/api/ ?
I would guess so.
The part of the build which is causing the problem is here :
http://lxr.mozilla.org/mozilla/source/js/rhino/toolsrc/build.xml
I am thinking of contacting the rhino team, and asking them to do the
following
1) create a property containing the full path of the source zip the
build downloads from Sun
${nest}/${build.dir}/swingExSrc.zip
2) test for the availability of the file before doing the download, and
only do the download if the file is not present locally.
3) then in gump we could define the location of this swingExSrc.zip in
the descriptor for rhino,
and add this file to the list of prerequisites for a gump instance doing
a full build.
Maybe add a small gump module containing a packaged project for this one
too ?
Do others think this is a good approach ?
Antoine
Footnotes :
[1] http://lsd.student.utwente.nl/gump/rhino/rhino.html
[2] http://gump.covalent.net/log/rhino.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Ant import problem [was Re: jbs (Jicarilla Build System?) and includes...]
Hi Adam, and jicarilla developers, (this is feeback about the build of jicarilla on gump, a system doing nightly builds of head revision of open-source projects) the jicarilla build is assuming that the user has a .jbs subdirectory, this is not very cool. Antoine http://cvs.sourceforge.net/viewcvs.py/jicarilla/jicarilla-sandbox/buildsystem/build-basic-reactor.xml?view=markup !-- *this is the case of gump *--> buildfile: build.xml [property] dropping /data3/gump/jicarilla-sandbox/platform/components/collections/target/classes from path as it doesn't exist [property] dropping /data3/gump/jicarilla-sandbox/platform/components/collections/target/test-classes from path as it doesn't exist BUILD FAILED /data3/gump/jicarilla-sandbox/platform/components/collections/build.xml:6: Cannot find /home/ajack/.jbs/build-project.xml imported from /data3/gump/jicarilla-sandbox/platform/components/collections/build.xml Total time: 0 seconds http://lsd.student.utwente.nl/gump/jicarilla-sandbox/jicarilla-collections.html#Build+%3A+build_jicarilla-sandbox_jicarilla-collections - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
patch for testsuite/build.xml
Hi Sliders, can you update the build.xml file located in the testsuite subdir, there is a leftover of your last change of jdom version, this is putting the gump build for your software unneedly in the red, where it should be green like a prairie in Normandie. Cheers, Antoine Index: testsuite/build.xml === RCS file: /home/cvspublic/jakarta-slide/testsuite/build.xml,v retrieving revision 1.19 diff -u -r1.19 build.xml --- testsuite/build.xml 18 Feb 2004 09:31:59 - 1.19 +++ testsuite/build.xml 1 Mar 2004 22:54:25 - @@ -49,7 +49,7 @@ - + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@lsd]: avalon/avalon failed
Adam R. B. Jack wrote: Could you enter this as an enhancement request into JIRA? I (about a month ago) tried having this information listed in xref, and also on each project/module, but even though it is in there (see the href attribute) http://lsd.student.utwente.nl/gump/avalon/index_details.html#Definition I somehow failed: http://build.try.sybase.com/eclipse-gump/gump_xref/descriptor_project.html Adam, is this build.try.sybase.com URL supposed to be public ? I cannot open it in my Web browser. Yes, I did not see this module definition link on lsd. There are lots of useful links in the forrest output present on LSD, you have done a great job. Rather than writing a JIRA, I will have a look at the existing docu, and add whatever I feel is missing and I understand. Adding to the documentation is a good way of getting a number of points clarified, sometimes discussed.. And then it can help other gump users.. Cheers, Antoine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: [GUMP@lsd]: jakarta-cactus/jakarta-cactus-sample-servlet-12 failed
Vincent Massol wrote: Hi, I need your help to solve this one below... 1/ Is there a URL from where I can see the build output (i.e. the target-* dirs created by the build)? Don't know. 2/ Is the line: [cactus] configurationOptionStr=null generated by Gump? I don't recally this coming from Cactus. Thanks! -Vincent It looks like a line generated by ant - ant itself has been started by gump - running a task called cactus. If I understand well the gump descriptor, the build file is in samples/servlet/build.xml and the dist target is invoked there. Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jakarta-gump -> gump
Hi, I hae seen that infrastructure has just renamed the repository from jakarta-gump to gump. I believe the machines where gump is running would need the following : - in the directory tree containing the version of gump used to run gump, change the contents of the file CVS/Repository every where to start with gump instead of jakarta-gump - maybe also change the name of the directory where gump is installed from jakarta-gump to gump and adapt crontabs/shell scripts Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
last night build on lsd
1) dom4j is building again :-) 2) jakarta-slide's build is failing with an irritating message saying it cannot copy /data3/gump/jakarta-slide/lib/jdom-b9.jar http://lsd.student.utwente.nl/gump/jakarta-slide/jakarta-slide.html the build should actually be looking for jdom-20040226-.jar because Oliver Zeigermann put this one 2 days ago in the repository of jakarta-slide 3) avalon is still failing on gumpy, although the avalon guys have updated their descriptor, adding the suggested mkdir line. http://lsd.student.utwente.nl/gump/avalon/avalon.html Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
