Re: JGroup == JavaGroups Re: cvs commit: gump/project javagroups.xml jgroups.xml
On Wed, 7 Jul 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: It seems we have two of these things. They are different (look at the package names). javagroups has been renamed to jgroups, because of trademark issues, I guess. JCS needs jgroups while something in Tomcat land is still using the old javagroups package. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[brutus] webapp - why?
Hi gang! could someone explain to me exactly *why* we're running forrest as a webapp? It's a relatively big resource hog... Looking at our resource usage, we have the following: load average: 0.97, 1.01, 1.31 Tasks: 112 total, 2 running, 110 sleeping, 0 stopped, 0 zombie Cpu(s): 23.9% user, 2.2% system, 0.0% nice, 73.9% idle Mem: 2069676k total, 1994204k used,75472k free, 253520k buffers Swap: 4289240k total,14164k used, 4275076k free, 1032492k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 22386 gump 9 0 105m 102m 9984 S 0.0 5.1 0:08.37 java 22387 gump 9 0 105m 102m 9984 S 0.0 5.1 0:00.97 java 22388 gump 9 0 105m 102m 9984 S 0.0 5.1 4:28.08 java (...) in other words, that's a lot of tomcat processes with a lot of resident memory. From just hitting refresh a lot against the webapp, I suspect brutus actually slows to a crawl if -- for example -- there's more than a few concurrent users, or some web bot is indexing the gump space. cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
what's all these processes?
Hi gang, still busy doing some gump profiling. I'm seeing this: [EMAIL PROTECTED]:/root# ps aux | grep gump | grep -v tomcat gump 23233 0.0 0.0 8568 1692 ?SJun25 0:57 /usr/bin/python2.3 /usr/bin/pydoc -p 1243 root 12593 0.0 0.0 4928 744 ?SJun29 0:00 sshd: gumpus d gump 8881 0.0 0.0 2268 1016 ?Ss 00:00 0:00 /bin/sh -c cd /usr/local/gump/public/gump; /bin/bash gumpy.sh all --xdocs gump 8883 0.0 0.0 2268 1060 ?S00:00 0:00 /bin/bash gumpy.sh all --xdocs gump 8886 0.0 0.1 6312 4024 ?S00:00 0:00 python gumpy.py all --xdocs gump 8902 0.0 0.0 2268 1008 ?S00:00 0:00 sh -c python gump/integrate.py -w ../brutus.xml all --xdocs out.txt 21 gump 8903 38.2 2.1 49492 44504 ? S00:00 42:19 python gump/integrate.py -w ../brutus.xml all --xdocs gump 9054 0.0 2.1 49492 44504 ? S00:00 0:00 python gump/integrate.py -w ../brutus.xml all --xdocs gump 14594 0.1 2.1 49492 44504 ? S01:49 0:00 python gump/integrate.py -w ../brutus.xml all --xdocs gump 14595 0.0 0.0 2280 1020 ?S01:49 0:00 sh -c java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dom3-gump /usr/local/gump/public/workspace/tmp/build_domts_dom3.txt 21 gump 14596 63.0 1.7 225692 35500 ? S01:49 0:43 java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dom3-gump gump 14597 0.0 1.7 225692 35500 ? S01:49 0:00 java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dom3-gump gump 14598 27.4 1.7 225692 35500 ? R01:49 0:18 java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dom3-gump gump 14599 0.0 1.7 225692 35500 ? S01:49 0:00 java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dom3-gump gump 14600 0.0 1.7 225692 35500 ? S01:49 0:00 java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dom3-gump gump 14601 0.0 1.7 225692 35500 ? S01:49 0:00 java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dom3-gump gump 14602 0.0 1.7 225692 35500 ? S01:49 0:00 java -Djava.awt.headless=true
Re: [brutus] webapp - why?
On Thu, 08 Jul 2004, Leo Simons [EMAIL PROTECTED] wrote: in other words, that's a lot of tomcat processes with a lot of resident memory. Sure its not only a lot of Java threads in a single process with a lot of resident memory? Linux process watching tools are unusable WRT threads - some people say Linux threads are unusable. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project james-server.xml
mcconnell2004/07/08 02:16:28 Modified:project james-server.xml Log: Update framework reference. Revision ChangesPath 1.9 +1 -3 gump/project/james-server.xml Index: james-server.xml === RCS file: /home/cvs/gump/project/james-server.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- james-server.xml 7 Jul 2004 19:50:08 - 1.8 +++ james-server.xml 8 Jul 2004 09:16:28 - 1.9 @@ -38,9 +38,7 @@ ant buildfile=gump.xml/ depend project=ant/ depend project=xml-xerces/ -depend project=avalon-framework-api/ -depend project=avalon-framework-impl inherit=runtime/ -depend project=avalon-framework-legacy inherit=runtime/ +depend project=avalon-framework inherit=runtime/ depend project=cornerstone-threads-api/ depend project=cornerstone-threads-impl inherit=runtime/ depend project=cornerstone-connection-api/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [brutus] webapp - why?
Stefan Bodewig wrote: On Thu, 08 Jul 2004, Leo Simons [EMAIL PROTECTED] wrote: in other words, that's a lot of tomcat processes with a lot of resident memory. Sure its not only a lot of Java threads in a single process with a lot of resident memory? Linux process watching tools are unusable WRT threads - some people say Linux threads are unusable. reasonably sure. Other tasks running concurrently are noticably faster when tomcat is off. Restarting tomcat also helps tremendously. I just tried that and then we're indeed down to just having many dupped threads. I'm guessing the forrest webapp has a memory leak or two. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
reference=home
Just an observation ... the following statement should (according to the gump spec) assign the home directory of the magic project to the property magic.home. depend name=magic.home reference=home inherit=runtime project=magic runtime=true/ However - the value assigned by gump is the jar file. Seems like a bug in the antdepend handling code - in which case I'll post a JIRA issue. Can someone confirm? Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project avalon-tools.xml
mcconnell2004/07/08 03:16:16 Modified:project avalon-tools.xml Log: Change the ant enclosed dependency to a property and add an explict depend under the project scope. This seems like a more reliable approach as the gump handling of depend attributes inside an ant are generating inconsistent results. Revision ChangesPath 1.18 +2 -2 gump/project/avalon-tools.xml Index: avalon-tools.xml === RCS file: /home/cvs/gump/project/avalon-tools.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- avalon-tools.xml 8 Jul 2004 07:26:14 - 1.17 +++ avalon-tools.xml 8 Jul 2004 10:16:16 - 1.18 @@ -46,8 +46,7 @@ ant basedir=tools/magic !-- for magic -- property name=gump.signature value=@@DATE@@/ - depend name=magic.home reference=home - project=magic inherit=runtime/ + property name=magic.home reference=home project=magic/ !-- external references -- depend property=gump.resource.ant project=ant id=ant/ depend property=gump.resource.junit project=junit/ @@ -55,6 +54,7 @@ depend property=gump.resource.ant-nodeps project=ant id=nodeps/ !-- end for -- /ant +depend project=magic runtime=true inherit=runtime/ home nested=tools/magic/target/deliverables/ jar name=jars/avalon-tools-magic-@@DATE@@.jar/ nag to=[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: resource usage]
My address book is a little ed up. :( Original Message Subject: resource usage Date: Thu, 08 Jul 2004 11:48:43 +0200 From: Leo Simons [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Hi gang! Noel J. Bergman wrote: I would also like the GUMP folks to take a close look at their needs. Specifically, I have just made arrangements that they ought to be able to get a copy of VMware GX for brutus. That will allow them to clone system configurations from a master disk image (virtual disk file) whenever they want to start afresh with a clean system. They could install whichever operating system(s) they want in the virtual machines, play around with configurations, etc., and not worry about problems. If a project ended up with a requirement came up to do some testing with MS.NET and Mono, they could do that, too. I know that they've looked at resources before, but they weren't accounting for disk images and the memory overhead. They may not need to add anything; I'm just suggesting that they check based upon this possibility. VMware would be nice (though I have no experience with GX, I imagine its better than the consumer stuff ;). I've been looking into our current resource consumption. Remember, we used to run gump on a duron ghz PC, and before that it was a pentium II... 1) processor when there's no gump run, it throts along at 5% or less. During gump runs it mostly takes about 25% or so (meaning the bottleneck is elsewhere, probably disk), except during merge steps and things like xml transformation, when it peaks out briefly (ie a second or two, never more) at a 100%. I think we could run two gump builds (like the main one and an experimental one) concurrently in seperate VMs and still have quite acceptable performance, even considering the overhead. 2) memory We have quite a bit of redundant memory. Gump itself eats about 50mb; the most intensive java compilation stuff (really big javadoc trees built using maven in a multiproject setup are an example) never takes more than a 1/2GB and that's a rare exception I've seen only once, and not on brutus so far. So the swap space is unused (we have 2GB of memory). I think if we run two gump builds concurrently in seperate VMs we would still not need to resort to swap space. 3) disk Of the 60Gb or so we have we're using about 15GB, and this is with several seperate gump trees, and including the OS. A single gump tree is about 4.5GB, with about 125MB of output every night. Even with the overhead of a GSX install, I guess we have enough space for a small image (the cvs checkouts 'n stuff don't need to be on the master image), two seperate VMs running at the same time, and /plenty/ of space to spare for gump to grow. So we're fine wrt space. I think disk speed is our bottleneck right now, and if we'd consider upgrading anything (which I don't think is neccessary), it's the main thing to attack. My guess is that the same would be true for a dedicated nightly build machine. cheers, - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [brutus] webapp - why?
could someone explain to me exactly *why* we're running forrest as a webapp? It's a relatively big resource hog... Recall when we ran forrest as a batch command? It would generate thousands of pages (costing lots of resources) even if those pages were never viewed. Basically, from what you say, both ways of using Forrest are expensive. Since we'd rather spend the resources on building than presentation, perhaps we ought just move to the XHTML option (in CleanUp branch). regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [brutus] webapp - why?
Adam R. B. Jack wrote: ... Since we'd rather spend the resources on building than presentation, perhaps we ought just move to the XHTML option (in CleanUp branch). +1 Forrest should be an option, not a strictly necessary dependency. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reference=home
On Thu, 08 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Just an observation ... the following statement should (according to the gump spec) assign the home directory of the magic project to the property magic.home. No. It should if you use property, but not if you use depend. depend doesn't even recognize the reference attribute. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dep inheritance ...
On Wed, 07 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: depend name=magic.home reference=home inherit=runtime project=magic/ Which according to me should be provided us with a few more entries in the classpath. I guess I'm missing something. //ant/depend doesn't support the inherit attribute at all. In order to achieve what you want, you need to use //ant/property plus a second depend nested into project. Which is, what you've already done AFAICS. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dep inheritance ...
Stefan Bodewig wrote: On Wed, 07 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: depend name=magic.home reference=home inherit=runtime project=magic/ Which according to me should be provided us with a few more entries in the classpath. I guess I'm missing something. //ant/depend doesn't support the inherit attribute at all. In order to achieve what you want, you need to use //ant/property plus a second depend nested into project. Which is, what you've already done AFAICS. Yep - keeping my fingers crossed for the next round of results. :-) -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sanity check
On Mon, 05 Jul 2004, Stephen McConnell [EMAIL PROTECTED] wrote: The idea scenario is that gump generates the module using the above after doing the checkout and before computing dependencies. So Gump had to know how to generate descriptors before it could start to do some work. As much as I understand your intention, I see rather big bootstrap problems here. Would your magic project description contain all information necessary to build your projects? You'd probably still need to pull SCM information and jar locations from Gump in addtion, right? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
missing 4 hours
The last gump run (which has come on-line about 30 mins ago) Start Date/Time (UTC) Thu, 08 Jul 2004 07:00:49 (UTC) End Date/Time (UTC) Thu, 08 Jul 2004 13:26:41 (UTC) What is happening between 13:26 and 17:15 (about 4 hours). There appears to be a really big delay between the end of a gump run and the publication of results. Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: missing 4 hours
The last gump run (which has come on-line about 30 mins ago) Start Date/Time (UTC) Thu, 08 Jul 2004 07:00:49 (UTC) End Date/Time (UTC) Thu, 08 Jul 2004 13:26:41 (UTC) What is happening between 13:26 and 17:15 (about 4 hours). There appears to be a really big delay between the end of a gump run and the publication of results. There are some serious memory leaks w/ the CVS HEAD Gump code. Python is non-trivial in keeping healthy (is my experience, or maybe I just trod on land mines). Anyways, the simple documentation of results (generating pages) has some awful memory leaks. I think the process bogs down to a crawl. The 'CleanUp' branch started as adding lots of __del__ to try to break circular dependencies and reduce these leaks. I think the situation is better. A lot more went into this branch (moving to DOM from Pythonic pseudo-(D)OM). Also, the update get performed right before the build, and the e-mails get sent right after the build completes (given the largest window to fix before next build). A bunch of stuff like that. I asked yesterday about merging CleanUp into CVS HEAD in the main 'cos you are working so diligently on this, and I am nervous I'll break you. After tonight I'll be done w/ my EMT refresher will be able to commit to fixing what breaks. I am tempted to perform the merge, but turn off notification (which might send duplicates for some odd reason) and see what transpires. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: what's all these processes?
still busy doing some gump profiling. I'm seeing this: I really appreciate that -- thank you! [EMAIL PROTECTED]:/root# ps aux | grep gump | grep -v tomcat gump 23233 0.0 0.0 8568 1692 ?SJun25 0:57 /usr/bin/python2.3 /usr/bin/pydoc -p 1243 Ok, the Python Documentation. A beautiful thing. root 12593 0.0 0.0 4928 744 ?SJun29 0:00 sshd: gumpus d gump 8881 0.0 0.0 2268 1016 ?Ss 00:00 0:00 /bin/sh -c cd /usr/local/gump/public/gump; /bin/bash gumpy.sh all --xdocs gump 8883 0.0 0.0 2268 1060 ?S00:00 0:00 /bin/bash gumpy.sh all --xdocs gump 8886 0.0 0.1 6312 4024 ?S00:00 0:00 python gumpy.py all --xdocs gump 8902 0.0 0.0 2268 1008 ?S00:00 0:00 sh -c python gump/integrate.py -w ../brutus.xml all --xdocs out.txt 21 gump 8903 38.2 2.1 49492 44504 ? S00:00 42:19 python gump/integrate.py -w ../brutus.xml all --xdocs gump 9054 0.0 2.1 49492 44504 ? S00:00 0:00 python gump/integrate.py -w ../brutus.xml all --xdocs gump 14594 0.1 2.1 49492 44504 ? S01:49 0:00 python gump/integrate.py -w ../brutus.xml all --xdocs That out.txt in there looks like a human. So, we have some crons and some humans running gumps, I *think*. Note: gumpy.sh [thin thin thin, to import local-env-py.sh] runs gumpy.py [doing CVS updates and such] which then launches gump/integrate.py (on the updates Python code) so one ought expect 3 processes per gump run. org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dom3-gump gump 14597 0.0 1.7 225692 35500 ? S01:49 0:00 java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/ xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-a pis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundle d.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-a pis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only dom3-gump root 14777 0.0 0.0 1548 516 pts/1S+ 01:50 0:00 grep gump why does every build command show up as 10 processes? Is that multithreading at work or somethin'? Nope, it isn't Python multithreading 'cos I turned that off. Hmm, that said -- there is (or was with Python 2.2) a separate process showing up when I started a timer to try to capture/kill errant builds. I think that went away w/ Python 2.3. Either this is just the DOM3 test working, or they are hanging not being killed. I'd have to look closer to really tell, but first I figure I'll ask... Stefan, can you tell us about these tests (if you know details). Do you know if they multi-thread -- or multi-process or something? Are they long lived. Do you think they could hang? BTW: We aren't using 'timeout' (that C program wrapper that more completely times things out). Even though the OS complains it isn't thread safe (especially on multi-CPU machine, I think.) I suspect we ought find it, compile it, and install it. http://brutus.apache.org/gump/public/environment.html#Tail+of+CheckEnvironment+%3A+check_timeout regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: resource usage]
Adam R. B. Jack wrote: We run VMWare here at TrySybase, and have for a couple of years. We tried running a full Gump on GSX (on an 'ok' box, not great) and we basically brought VMWare down. Basiclly thought, Gump pushed GSX too hard for resources. This might be good to test on brutus, no? GSX still resides on top of the operating system (like VMWAre Workstation does) Memory is the *main* thing that VMWAre go on and on and on about needing gobs of. Hence my inquiry to you folks about brutus. :-) We moved from GSX (served us well) to ESX about 6 months ago, and that is truly sweet. ESX is based on a Linux Kernal and has no OS sitting between it and the box's hardware. Things run very very nicely Good experience to hear. If we were to find a similar problem with GSX on brutus, I expect that VMware would want to know, and we could offer to try ESX in the same configuration, although I would not take brutus down to do it. I'd test it on one of the other x345s first, assuming there is still one unused. Anyhow, give it some thought. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: missing 4 hours
Adam R. B. Jack wrote: After tonight I'll be done w/ my EMT refresher will be able to commit to fixing what breaks. I am tempted to perform the merge, but turn off notification (which might send duplicates for some odd reason) and see what transpires. My opinion - go for it and lets see what happens. Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project avalon-tools.xml
mcconnell2004/07/08 10:15:44 Modified:project avalon-tools.xml Log: Add work directories to cover the test case execution. Revision ChangesPath 1.20 +2 -0 gump/project/avalon-tools.xml Index: avalon-tools.xml === RCS file: /home/cvs/gump/project/avalon-tools.xml,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- avalon-tools.xml 8 Jul 2004 10:25:24 - 1.19 +++ avalon-tools.xml 8 Jul 2004 17:15:44 - 1.20 @@ -30,6 +30,8 @@ depend project=junit runtime=true/ depend project=ant runtime=true inherit=runtime/ !--depend project=ant ids=ant junit nodeps ant-launcher runtime=true/-- +work nested=tools/magic/target/classes/ +work nested=tools/magic/target/test-classes/ home nested=tools/magic/target/@@DATE@@/ jar name=../deliverables/jars/avalon-tools-magic-@@DATE@@.jar/ nag to=[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
Stefano Mazzocchi wrote: I have started to use python myself because I loved the much faster try/fail cycle of a scripting language and python looked a lot friendlier than other scripting languages. But in my experience, it doesn't scale in terms of complexity as much as java does. This is my impression also :-( Also, it seems that there is a lot of black magic in getting it to run very solidly, while java has years of polishing on seriously loaded environments. So, I wonder: what would you think about a gump in java? Gump went from Ant to Java and XSLT scripts to Python... now what? ;-) The question I'm asking myself is: what are we trying to solve? Is Java the answer to the Pyhon Gump problems and to all the preceding ones? The first thing I thought was yeah but I'm afraid it's something that will change yet again. Ant and xslt: it was used because it's used to build, so it seemes natural to choose it * cons: complexity (AFAIK) Scripts with xslt: it was used because scripts basically don't give any dependency in Unix environments, and are completely separate from the things that they are building * cons: obscurity and black magic Python: it's a language that many developers know or can learn easily enough, and can be installed in different environments * cons: it isn't as clear as we thought in the first place and seems like a PITA to tune and still not trivial to install Java: it's truly cross-platform and the Gump PMC members all know it quite well; easy to install * cons: dunno Probably before the language we should ask ourselves how the code has to be structured. Maybe we should evaluate the new DOM-based Gump and discuss on that. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
Nicola Ken Barozzi wrote: Stefano Mazzocchi wrote: I have started to use python myself because I loved the much faster try/fail cycle of a scripting language and python looked a lot friendlier than other scripting languages. But in my experience, it doesn't scale in terms of complexity as much as java does. This is my impression also :-( Java: it's truly cross-platform and the Gump PMC members all know it quite well; easy to install * cons: dunno I think the main problem we will face in a Java Gump is dependencies. We will have to COMPLETELY resit depending on anything except JDK 1.4 R, Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Getting lots of /tmp/*.xls on Brutus
My local (work) Gump that builds a really small subset of the Gump stack (and then my code) started dying w/ lack of disk space. We found that we were getting a full /tmp, and then I saw that Brutus has a similar issue. [EMAIL PROTECTED]:~$ wc /tmp/*.xls -bash: /usr/bin/wc: Argument list too long [EMAIL PROTECTED]:~$ cat /tmp/*.xls | wc -bash: /bin/cat: Argument list too long 0 0 0 i.e. lots of files! Basically, I have to assume that these are from POI (please correct me if I am wrong) and one (or both) of the two POI runs. http://brutus.apache.org:8080/gump/jakarta-poi/index.html http://brutus.apache.org:8080/gump/jakarta-poi-3/index.html Could you look at this problem, and help us out? Could you see if the POI test runs could use a ./tmp (or similar) directory, 'cos Gump cleans that out each run. [I don't know if this uses some Java function that you have limited control over, but I thought I'd ask.] Also, would it be possible to separate the POI tests from the POI compile? I use POI at work (love it, thanks!) and we try to compile our stack of code regularly. Anything that creates this much data must be resource intensive :) -- so if we could have separate poi and poi-test, we'd be able to save local resources. No biggee though. Thanks in advance. 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: [RT] Was python a good idea?
I have started to use python myself because I loved the much faster
try/fail cycle of a scripting language and python looked a lot
friendlier than other scripting languages.
Python is fun to get started with has some really nice features. My guess
is I've not even come close to touching the nicer parts ('cos I've yet to
leave Java thinking far enough behind) and I kinda look forward to getting
there, some day.
But in my experience, it doesn't scale in terms of complexity as much as
java does.
Sure doesn't. Good practices (unit tests, getting good coverage, pychecker
and all) can help, but any line/character not touched is a potential
time-bomb. That said, those good practices are needed w/ any language, they
just take discipline. Basically, I've come to live w/ that realization
stopped trying to take so many short cuts (despite knowing better). Maybe I
owe Python thanks for that. ;-)
I've found a bunch of stuff I can't do w/ Python, but then I've found
similar w/ Java. Python is clearly far less mature, but I doubt that will
last very long. Basically, I have a love/hate relationship w/ Python (I've
caused myself a lot of hours of pain), but I don't regret having tinkered
with it.
Also, it seems that there is a lot of black magic in getting it to run
very solidly, while java has years of polishing on seriously loaded
environments.
That could easily be me. I chose to do some
So, I wonder: what would you think about a gump in java?
Good idea? Maybe. Personally, I've invested so much in Python Gump to want
to back off (although 6 months ago I'd've been there in a heart beat).
Personally, I feel Gump is beautifully irrelevant -- if it dropped of the
face of the planet few people would notice -- but when it find issues
helps out, it is a sweet thing. For me it is a beautify folly; so what
better than to experiment with, to teach some Java folks a new tool, to
learn Python get a new perspective on the world?
BTW: Won't Java (with JDK 1.5 feature) + Groovy and Python be about the same
thing sooner or later, anyway? ;-) The similarities will outweigh the
differences. ;-)
Basically, I think Python Gump was the right thing to do 'cos it breathed
life into a somewhat mundane/infrastructural task. I do think it has become
a barrier to entry for many, which I find disturbing. As such, I'd not fight
against folks wanting to re-write in Java ('cos that is clearly quite
doable).
regards,
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting lots of /tmp/*.xls on Brutus
Am Do, 2004-07-08 um 20.23 schrieb Adam R. B. Jack: i.e. lots of files! Basically, I have to assume that these are from POI (please correct me if I am wrong) and one (or both) of the two POI runs. You are write, the POI test cases do create temporary files without deleting them. I think you can remove them without any harm. Fellow POI committers, could you please delve into your test cases and resolve that issue? BTW, the HPSF test cases tidy the disk when they are finished (tap on my shoulder). Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
Nick Chalko wrote: Nicola Ken Barozzi wrote: Stefano Mazzocchi wrote: I have started to use python myself because I loved the much faster try/fail cycle of a scripting language and python looked a lot friendlier than other scripting languages. But in my experience, it doesn't scale in terms of complexity as much as java does. This is my impression also :-( Java: it's truly cross-platform and the Gump PMC members all know it quite well; easy to install * cons: dunno I think the main problem we will face in a Java Gump is dependencies. We will have to COMPLETELY resit depending on anything except JDK 1.4 Very true, but doable, IMO since we get XML/XSLT/DOM support in there. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Getting lots of /tmp/*.xls on Brutus
Am Do, 2004-07-08 um 20.50 schrieb Rainer Klute: You are write, ... You are right, it is too late, at least for me. :-( Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] please remove/rename the nekohtml project in Cocoon's descriptor
Stefan Bodewig wrote: Hi, Gump already has a project named nekohtml for NekoHTML 0.9.3. If this is what you need in Cocoon then please simple remove your project definition, otherwise please rename the project. Gump tries to merge the like-named project and drops both of them since their jar ids clash (and would claim there were missing build outputs if the ids didn't clash). Done. Sorry for the hassle. I'm a complete Gump newbie, and figured I would get something wrong! Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
Stefano Mazzocchi wrote: I think the main problem we will face in a Java Gump is dependencies. We will have to COMPLETELY resit depending on anything except JDK 1.4 Very true, but doable, IMO since we get XML/XSLT/DOM support in there. I might help more if it was in Java, but I don't see the need with out also changing to more of a pipeline architecture, or tackle using last good jar or something. Otherwise we are just spinning our wheels. R, Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
Adam, please, let me start saying this is (as indicated) a random
though, not a proposal, nor a criticism.
As Nicola said, moving from ant+xslt+bash to python was a tremendous
improvement. I just wonder if we should stop there, especially given
that this community is basically java gurus with a little big of python
envy for some of the features (that could be replicated in java, if one
*really* wanted them, btw).
Adam R. B. Jack wrote:
I have started to use python myself because I loved the much faster
try/fail cycle of a scripting language and python looked a lot
friendlier than other scripting languages.
Python is fun to get started with has some really nice features. My guess
is I've not even come close to touching the nicer parts ('cos I've yet to
leave Java thinking far enough behind) and I kinda look forward to getting
there, some day.
But in my experience, it doesn't scale in terms of complexity as much as
java does.
Sure doesn't.
Well, ask the Zope people about that: not many agree in python-guru land
(and not only for ego or protection of their past decisions).
The strong vs. weak typing debate is vivid in my head and you can
say that no matter how deep you go to describe the metadata associated
to your dependencies, there is a point where all of them get weak.
Gump, for example, shows how the time variable makes a strongly typed
system become weakly typed.
Also, if you get pretty heavy with Collections, even Java becomes weakly
typed.
*but* for some reason, java scales better with size and internal
complexity. it feels more solid, at least to me.
Good practices (unit tests, getting good coverage, pychecker
and all) can help, but any line/character not touched is a potential
time-bomb. That said, those good practices are needed w/ any language, they
just take discipline.
Very true. Fact is this is a community of java programmers which a
tendency for not really caring about religions and just getting the job
done.
I'm not against python or your work, I just wonder if this isn't
blocking all the tremendous java expertiese that we all have.
Basically, I've come to live w/ that realization
stopped trying to take so many short cuts (despite knowing better). Maybe I
owe Python thanks for that. ;-)
I've found a bunch of stuff I can't do w/ Python, but then I've found
similar w/ Java. Python is clearly far less mature, but I doubt that will
last very long. Basically, I have a love/hate relationship w/ Python (I've
caused myself a lot of hours of pain), but I don't regret having tinkered
with it.
I can sense that (otherwise, you have would have given up) but I also
see that as much as Gump was a one-man-show (driven by Sam) this gump is
another one man show (driven by you).
I consider myself Gump one of the most incredible innovations of the
entire foundation. I wonder what's going to happen if you go away or
stop being interested in that.
I'm not saying it's your fault, not at all... it's *our* fault that we
don't contribute... but everytime I think about looking at the code the
complexity of all that python just scares me away a little so I
postpone and I never do it.
I *really* want to extend gump so that it builds apr httpd and
subversion... but everytime I want to start, some other thing comes up
and that itch goes away.
Yesterday was one of those days and I think I know realize that it's
because of python.
I wonder how many others on this list feel the same, thus my RTs.
Also, it seems that there is a lot of black magic in getting it to run
very solidly, while java has years of polishing on seriously loaded
environments.
That could easily be me. I chose to do some
So, I wonder: what would you think about a gump in java?
Good idea? Maybe. Personally, I've invested so much in Python Gump to want
to back off (although 6 months ago I'd've been there in a heart beat).
Personally, I feel Gump is beautifully irrelevant -- if it dropped of the
face of the planet few people would notice -- but when it find issues
helps out, it is a sweet thing.
Personally, I think gump is the most important project of the entire
ASF, but it will take a few more years and a lot more work in certain
other directions to show that.
For me it is a beautify folly; so what
better than to experiment with, to teach some Java folks a new tool, to
learn Python get a new perspective on the world?
If it floats your boat, I'm happy. I'm just concerned that the day you
find something that is more interesting, we are left with a codebase
that nobody knows how to maintain.
BTW: Won't Java (with JDK 1.5 feature) + Groovy and Python be about the same
thing sooner or later, anyway? ;-) The similarities will outweigh the
differences. ;-)
There is a psycological impact in community dynamics that should not be
underestimated.
Basically, I think Python Gump was the right thing to do 'cos it breathed
life into a somewhat mundane/infrastructural task.
True.
I do think it has become a
cvs commit: gump/python/gump/shared comparator.py
ajack 2004/07/08 13:33:11 Modified:python/gump update.py preview.py build.py env.py debug.py check.py integrate.py python/gump/notify notification.py notifier.py logic.py python/gump/utils http.py sync.py launcher.py note.py work.py __init__.py owner.py file.py python/gump/model project.py server.py profile.py module.py repository.py depend.py builder.py propagation.py object.py property.py __init__.py tracker.py workspace.py state.py python/gump/document documenter.py resolver.py python/gump/test updater.py resulting.py pyunit.py syndicator.py resolving.py __init__.py xref.py maven.py utils.py notifying.py model.py python/gump/test/resources/complete1 download1.xml profile.xml module3.xml python/gump/syndication atom.py abstract.py rss.py syndicator.py python/gump/test/resources/full1 profile.xml svn_repository1.xml workspace.xml download1.xml module3.xml python/gump/update svn.py cvs.py updater.py python/gump/document/xdocs __init__.py resolver.py documenter.py xdoc.py python/gump/stats statsdb.py statistician.py python/gump/document/text resolver.py documenter.py python/gump/results resulter.py model.py python/gump/core gumpenv.py gumpinit.py config.py gumprun.py commandLine.py actor.py python/gump/build ant.py maven.py abstract.py builder.py script.py python/gump/admin stats.py python/gump/guru stats.py xref.py src/documentation/content/xdocs/metadata maven.xml project.xml template/forrest/content/xdocs site.xml .gumpytest.sh gumpy.py gumpy.sh .cvsignore python .cvsignore python/gump/gui view.py python/gump/runner runner.py tasks.py demand.py python/gump/svg depdiag.py scale.py python/gump/shared comparator.py Added: python/gump/loader .cvsignore __init__.py loader.py template/xhtml/gump_icons failed.png unset.png no_work_performed.png success.png prerequisite_failed.png complete.png python/gump/utils tasks.py domutils.py smtp.py timing.py python/gump/threads __init__.py .cvsignore tools.py python/gump/model cp.py misc.py python/gump/test threads.py loading.py timing.py xdocs.py python/gump/test/resources/complete1 artifact_repository1.xml python/gump/integration .cvsignore depot.py __init__.py cvs.py python/gump/test/resources/full1 artifact_repository1.xml python/gump/update artifact.py python/gump/document/xdocs config.py python/gump/performance xdocs.py gurus.py __init__.py .cvsignore deps.py python/gump/repository artifact.py template/xhtml/images gump-logo.png PythonPowered.gif icon.png apache.png template/xhtml/css style.css template/xhtml favicon.ico python/tool profileResults.py .cvsignore __init__.py commitCheck.py Removed: python/gump logconf.ini server try.xml hermes.xml lsd.xml dotnot.xml python/gump/utils xmlutils.py python/storage/random/results model.py loader.py __init__.py resulter.py .cvsignore python/gump/model rawmodel.py loader.py python/gump/net __init__.py .cvsignore cvs.py smtp.py python/gump/test loader_tests.py xdoc_tests.py xml_tests.py gumpset_tests.py python/gump/test/resources/complete1 jars_repository1.xml python/gump/test/resources/full1 jars_repository1.xml python/gump/update jars.py python/gump/repository jars.py python/logging handlers.py __init__.py PKG-INFO .cvsignore config.py .commitCheck.py Log: Merged CleanUp branch in. Revision ChangesPath 1.2 +1 -0 gump/python/gump/loader/.cvsignore http://cvs.apache.org/viewcvs/gump/python/gump/loader/.cvsignore.diff?r1=1.1r2=1.2 1.2 +21 -0 gump/python/gump/loader/__init__.py
Re: [RT] Was python a good idea?
Adam, please, let me start saying this is (as indicated) a random though, not a proposal, nor a criticism. Thanks, but not neccessary, I've had the [RT] myself many times. In the early days of this (as one gent on IM can attest) there were an uncountable number of times I bitched I could re-write Gump in Java in no time. I still think it is very easy/doable in Java. Maybe it would've been smarter. For me it is a beautify folly; so what better than to experiment with, to teach some Java folks a new tool, to learn Python get a new perspective on the world? If it floats your boat, I'm happy. I'm just concerned that the day you find something that is more interesting, we are left with a codebase that nobody knows how to maintain. IMHO, the codebase is the problem, not the language. Trust me, I write Python like I write Java, heck -- I don't know Pythonic Python. ;-) Kinda like I write Perl, kinda like I write -- ya know, it all just all tastes like chicken. ;-) Basically, there are a bunch of classes -- maybe too many -- and they need cleaning up, they need documenting, they need opening up to the rest of you. BTW: Won't Java (with JDK 1.5 feature) + Groovy and Python be about the same thing sooner or later, anyway? ;-) The similarities will outweigh the differences. ;-) There is a psycological impact in community dynamics that should not be underestimated. Yup, I hear that. I hope the CleanUp branch was the start of the cleanup, of a simplification. I think we need to enable plug-ins (the easiest way for communities to open up to new developers) and I think we need to fully document/clean the internal design. I've fought so long w/ Python performance that I've not been able to do that, I now feel I can. I don't plan on going anywhere until I've documented Gump, and given Python it's best chance. I think Gumpy is finally warming up I thank folks for their continued interest/patience... regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
Adam R. B. Jack wrote: I think we need to enable plug-ins (the easiest way for communities to open up to new developers) +1 -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
Adam R. B. Jack wrote:
Basically, I think Python Gump was the right thing to do 'cos it breathed
life into a somewhat mundane/infrastructural task. I do think it has become
a barrier to entry for many, which I find disturbing. As such, I'd not fight
against folks wanting to re-write in Java ('cos that is clearly quite
doable).
For what its worth - yes - Python is a barrier to entry for me
personally but I kind of like that. It's my perfect excuse for not
submitting patches and provides me with a good separation of me as tool
user versus developer (something I appreciate given the amount of stuff
I'm already committed to).
On the other hand - a java variant of Gump would be interesting in that
I could envisage closer integration between things like magic and gump
itself. It would also be a lot of fun to play around with gump plugins
- things that lavage the big interconnected picture - but I'm sure this
is possible with Python gump also.
0.02
Cheers, Steve.
--
|---|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ummm... help needed
- Original Message - From: Stephen McConnell [EMAIL PROTECTED] To: Gump code and data [EMAIL PROTECTED] Sent: Friday, July 09, 2004 1:47 AM Subject: ummm... help needed [...] classloaders at the same time or something like that. As a first step - could someone with access to brutus send me the unit test report file: /usr/local/gump/public/workspace/avalon-tools/tools/magic/target/test-report s TEST-org.apache.avalon.tools.model.test.ContextTestCase.txt I don't have access to brutus, but perhaps you could use the Ant concat task to display the contents of the file. See for example JMeter, which uses it in its build.xml gump-test target: http://brutus.apache.org:8080/gump/jakarta-jmeter/jakarta-jmeter-test/gump_work/build_jakarta-jmeter_jakarta-jmeter-test.html HTH, S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ummm... help needed
Sebastian Bazley wrote: I don't have access to brutus, but perhaps you could use the Ant concat task to display the contents of the file. See for example JMeter, which uses it in its build.xml gump-test target: Works like a charm - I've added this into magic unit test task so we get a report listed automatically if a unit test fails when running under gump. Thanks!! -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
brutus may be having a problem
http://brutus.apache.org:8080/gump/modules.html Message: null Description: No details available. Sender: org.apache.cocoon.servlet.CocoonServlet Source: Cocoon Servlet Request URI modules.html cause /home/gump/jakarta-tomcat-5.0.24/webapps/gump/content/xdocs/modules.xml (No such file or directory) request-uri /gump/modules.html Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project avalon-tools.xml
mcconnell2004/07/08 22:19:49 Modified:project avalon-tools.xml Log: (I have to try it) Revision ChangesPath 1.21 +1 -0 gump/project/avalon-tools.xml Index: avalon-tools.xml === RCS file: /home/cvs/gump/project/avalon-tools.xml,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- avalon-tools.xml 8 Jul 2004 17:15:44 - 1.20 +++ avalon-tools.xml 9 Jul 2004 05:19:48 - 1.21 @@ -49,6 +49,7 @@ !-- for magic -- property name=magic.home reference=home project=magic/ property name=gump.signature value=@@DATE@@/ + property name=build.sysclasspath value=dark-arts-volume-one/ !-- external references -- depend property=gump.resource.ant project=ant id=ant/ depend property=gump.resource.junit project=junit/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: brutus may be having a problem
http://brutus.apache.org:8080/gump/modules.html
Yup, maybe my merge has some kinks to work out. Still, Leo (or other), could
I request a quick reconfigure?
1) Let's remove tomcat.
2) Restore the config such that http://brutus.apache.org/gump/{flavour} goes
to /usr/local/gump/{flavour}/results.
I've reconfigure both public and jdk15 (and test) to write here stopped
the XDOCs output, am trying the better tested XHTML.
regards,
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project avalon-tools.xml
Log: (I have to try it) + property name=build.sysclasspath value=dark-arts-volume-one/ Sure, but I wouldn't be surprised if I tried to stop you (when I coded it). We'll see. :) regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (GUMP-73) HTTPD reconfiguration
Message:
A new issue has been created in JIRA.
-
View the issue:
http://issues.apache.org/jira/browse/GUMP-73
Here is an overview of the issue:
-
Key: GUMP-73
Summary: HTTPD reconfiguration
Type: Task
Status: Unassigned
Priority: Critical
Project: Gump
Components:
configuration of live servers
Assignee:
Reporter: Adam Jack
Created: Thu, 8 Jul 2004 10:44 PM
Updated: Thu, 8 Jul 2004 10:44 PM
Due: Fri, 9 Jul 2004 12:00 AM
Description:
) Let's remove (or, at least, shut down) tomcat.
2) Restore the config such that http://brutus.apache.org/gump/{flavour} goes
to /usr/local/gump/{flavour}/results.
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (GUMP-73) HTTPD reconfiguration
Message:
The following issue has been re-assigned.
Assignee: Leo Simons (mailto:[EMAIL PROTECTED])
Assigner: Adam Jack (mailto:[EMAIL PROTECTED])
Date: Thu, 8 Jul 2004 10:45 PM
Comment:
Pretty please... [save me figuring out what is wrong w/ it today].
-
View the issue:
http://issues.apache.org/jira/browse/GUMP-73
Here is an overview of the issue:
-
Key: GUMP-73
Summary: HTTPD reconfiguration
Type: Task
Status: Open
Priority: Critical
Project: Gump
Components:
configuration of live servers
Assignee: Leo Simons
Reporter: Adam Jack
Created: Thu, 8 Jul 2004 10:44 PM
Updated: Thu, 8 Jul 2004 10:45 PM
Due: Fri, 9 Jul 2004 12:00 AM
Description:
) Let's remove (or, at least, shut down) tomcat.
2) Restore the config such that http://brutus.apache.org/gump/{flavour} goes
to /usr/local/gump/{flavour}/results.
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
