brutus the New IBM Machine
I like the name. Aaron Bannert wrote: Hi Gang, Brian, Scott Sanders and I set up two of the 345s last night and then racked them up in the colo. We kept an inventory of the two machines we unpacked that I'll attach below. It's probably safe to assume that the other two machines also have identical configurations. Both machines are running sshd and allow remote root over ssh. Accounts will need to be setup on both machines. Call me for the passwords. Machines: 1) "brutus.apache.org" - The Gump Machine Debian something, stock everything, minimal install. Kernel doesn't recognise SMP, kernel doesn't recognise >860G of RAM. Other than that, everything seemed to be detected ok. I believe console redirection is enabled on this machine. Also, we're able to boot without a keyboard, and then plug in a keyboard after boot and still have it work. The built-in LSI RAID module didn't appear to support striping, so we opted to leave the drives separate. The Gump people may wish to stripe the two drives in this machine for better disk I/O without the loss of available space (in software, or maybe in hardware if the LSI turns out to support striping (RAID0)). Filesystem Size Used Avail Use% Mounted on /dev/sda1 7.9G 147M 7.4G 2% / /dev/sda6 26G34M25G 1% /home /dev/sdb6 34G 125M32G 1% /usr Basically the only thing running on here right now is sshd. We've created a root account and a "rubys" account. Sam, feel free to give me a call later to find out your password and the root password (my number is in members.txt). Hosting/Colo Situation: Power: The socket we had installed at the Colo doesn't fit the plug on the power distributor. Brian wrote down the exact lables from the plug and the socket, so I don't have them here. I suppose we'll have to have UL change the socket to match our plug. Comments? UPS: The on-loan and failing APC at the bottom of our rack is disconnected. The Belkin that Brian brought in is being used, but only the terminal server and hermes are using battery backup. Even though I brought in a power strip/surge protector, we're out of sockets again, but once we get the power distributor working we'll have plenty of sockets. Switch: I believe we have two more open ports on the switch. Rack space: UL gave us some shelves which we're using for the new IBM machines. We made some room for the next two once they're ready. Terminal server: We made two more serial plugs for the two new machine, and plugged them into ports 3 and 4 (IIRC, and I don't know in which order). We didn't test these plugs, but we should be able to fire up getty on the serial ports and see if we get a prompt over the terminal server. Inventory: Both machines were the same. Here's the specs on each: 1) 2x 2.8Ghz Xeon CPUs (with hyperthreading) 2) 2x PC2100 - 1GB DDR 266Mhz CL2.5 ECC RAM (2GB total) 3) 1x Power Supply Unit, Hot Swap (room for one more) 4) 2x 36.4GB 15kRPM U320 SCSI HotSwap Harddrives - CRU 32P0736 (room for 4 more drives) Enjoy, -aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/blog/SuccessStories jrefactory.txt
No problems, I did a little more formating, Whanged the "I"'s to "Antoine" got the funny "e" to display ;-) And published. R, Nick Antoine Lévy-Lambert wrote: 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, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/blog/SuccessStories jrefactory.txt
nickchalko2004/03/26 12:55:42 Modified:blog/SuccessStories jrefactory.txt Log: Published PR: Obtained from: Submitted by: Reviewed by: CVS: -- CVS: PR: CVS: If this change addresses a PR in the problem report tracking CVS: database, then enter the PR number(s) here. CVS: Obtained from: CVS: If this change has been taken from another system, such as NCSA, CVS: then name the system in this line, otherwise delete it. CVS: Submitted by: CVS: If this code has been contributed to Apache by someone else; i.e., CVS: they sent us a patch or a new module, then include their name/email CVS: address here. If this is your work then delete this line. CVS: Reviewed by: CVS: If we are doing pre-commit code reviews and someone else has CVS: reviewed your changes, include their name(s) here. CVS: If you have not had it reviewed then delete this line. Revision ChangesPath 1.7 +1 -5 gump/blog/SuccessStories/jrefactory.txt Index: jrefactory.txt === RCS file: /home/cvs/gump/blog/SuccessStories/jrefactory.txt,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- jrefactory.txt26 Mar 2004 20:54:48 - 1.6 +++ jrefactory.txt26 Mar 2004 20:55:42 - 1.7 @@ -1,8 +1,4 @@ -PREVIEW JRefactory adapt their code to changes in jaxen/saxpath - -Preview at -http://gump.chalko.com/gb/blog/SuccessStories?preview=true&smm=y&permalink=jrefactory.txt - +JRefactory adapts their code to changes in jaxen/saxpath
cvs commit: gump/blog/SuccessStories jrefactory.txt
nickchalko2004/03/26 12:54:48 Modified:blog/SuccessStories jrefactory.txt Log: lower case e acute not grave PR: Obtained from: Submitted by: Reviewed by: CVS: -- CVS: PR: CVS: If this change addresses a PR in the problem report tracking CVS: database, then enter the PR number(s) here. CVS: Obtained from: CVS: If this change has been taken from another system, such as NCSA, CVS: then name the system in this line, otherwise delete it. CVS: Submitted by: CVS: If this code has been contributed to Apache by someone else; i.e., CVS: they sent us a patch or a new module, then include their name/email CVS: address here. If this is your work then delete this line. CVS: Reviewed by: CVS: If we are doing pre-commit code reviews and someone else has CVS: reviewed your changes, include their name(s) here. CVS: If you have not had it reviewed then delete this line. Revision ChangesPath 1.6 +1 -1 gump/blog/SuccessStories/jrefactory.txt Index: jrefactory.txt === RCS file: /home/cvs/gump/blog/SuccessStories/jrefactory.txt,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- jrefactory.txt26 Mar 2004 20:53:29 - 1.5 +++ jrefactory.txt26 Mar 2004 20:54:48 - 1.6 @@ -23,7 +23,7 @@ issue of line ending with PrettyPrinter task -Antoine LÈvy-Lambert had found a problem with the PrettyPrinter task supplied by +Antoine Lévy-Lambert had found a problem with the PrettyPrinter task supplied by http://jrefactory.sourceforge.net/";>JRefactory. Without any clear announcement, the JRefactory team had changed their http://jrefactory.sourceforge.net/Main_components_prettyprint.html";>PrettyPrinter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/blog/SuccessStories jrefactory.txt
nickchalko2004/03/26 12:53:29 Modified:blog/SuccessStories jrefactory.txt Log: Trying to fix the "e" PR: Obtained from: Submitted by: Reviewed by: CVS: -- CVS: PR: CVS: If this change addresses a PR in the problem report tracking CVS: database, then enter the PR number(s) here. CVS: Obtained from: CVS: If this change has been taken from another system, such as NCSA, CVS: then name the system in this line, otherwise delete it. CVS: Submitted by: CVS: If this code has been contributed to Apache by someone else; i.e., CVS: they sent us a patch or a new module, then include their name/email CVS: address here. If this is your work then delete this line. CVS: Reviewed by: CVS: If we are doing pre-commit code reviews and someone else has CVS: reviewed your changes, include their name(s) here. CVS: If you have not had it reviewed then delete this line. Revision ChangesPath 1.5 +1 -1 gump/blog/SuccessStories/jrefactory.txt Index: jrefactory.txt === RCS file: /home/cvs/gump/blog/SuccessStories/jrefactory.txt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- jrefactory.txt26 Mar 2004 20:50:53 - 1.4 +++ jrefactory.txt26 Mar 2004 20:53:29 - 1.5 @@ -23,7 +23,7 @@ issue of line ending with PrettyPrinter task -Antoine Lévy-Lambert had found a problem with the PrettyPrinter task supplied by +Antoine LÈvy-Lambert had found a problem with the PrettyPrinter task supplied by http://jrefactory.sourceforge.net/";>JRefactory. Without any clear announcement, the JRefactory team had changed their http://jrefactory.sourceforge.net/Main_components_prettyprint.html";>PrettyPrinter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/blog/SuccessStories jrefactory.txt
nickchalko2004/03/26 12:50:53 Modified:blog/SuccessStories jrefactory.txt Log: Formating, and links. PR: Obtained from: Submitted by: Reviewed by: CVS: -- CVS: PR: CVS: If this change addresses a PR in the problem report tracking CVS: database, then enter the PR number(s) here. CVS: Obtained from: CVS: If this change has been taken from another system, such as NCSA, CVS: then name the system in this line, otherwise delete it. CVS: Submitted by: CVS: If this code has been contributed to Apache by someone else; i.e., CVS: they sent us a patch or a new module, then include their name/email CVS: address here. If this is your work then delete this line. CVS: Reviewed by: CVS: If we are doing pre-commit code reviews and someone else has CVS: reviewed your changes, include their name(s) here. CVS: If you have not had it reviewed then delete this line. Revision ChangesPath 1.4 +16 -14gump/blog/SuccessStories/jrefactory.txt Index: jrefactory.txt === RCS file: /home/cvs/gump/blog/SuccessStories/jrefactory.txt,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- jrefactory.txt26 Mar 2004 17:13:38 - 1.3 +++ jrefactory.txt26 Mar 2004 20:50:53 - 1.4 @@ -22,36 +22,38 @@ issue of line ending with PrettyPrinter task - -I had found a problem with the PrettyPrinter task supplied by JRefactory. -Without any clear announcement, the JRefactory team had changed their PrettyPrinter -task to delegate processing of line endings to the ant fixcrlf task - which is good. + +Antoine Lévy-Lambert had found a problem with the PrettyPrinter task supplied by +http://jrefactory.sourceforge.net/";>JRefactory. +Without any clear announcement, the JRefactory team had changed their +http://jrefactory.sourceforge.net/Main_components_prettyprint.html";>PrettyPrinter +task to delegate processing of line endings to the ant fixcrlf task - which is good. 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, + +Antoine 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, + +Antoine 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. - + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] My personal roadmap for gump
> Yada yada yada. Could go on for a while, but I won't. Let's hear about > you! :-D I'm interesting in Gump's viewpoint on OSS projects, and their interactions, and I want to work on how that viewpoint can be leveraged. I care about presenting this simple metadata in as many ways as valuable, from different perspectives. I thought I wanted mathematical perspectives alone, but I've become convinced that visual representations would be even better. I would like to see Gump scale to many more projects, to create some map of core OSS (folks can use google to find/evaluate more obscure ones.) I don't want to see the 'rich get richer', and have folks focus in on the main projects, but I'll accept that risk because I think folks deserve insights into projects. I don't want OSS to be a crap shoot, I want some objective insights when I chose to depend/rely upon somebody else (and invest my energy in learning their solution.) For example, I hear that forrest uses cocoon uses avalon, but even as close to Gump metadata as I am (and however I see dependency tables), I don't really understand "how much", or "what aspects". If I hear something is being de-emphasized, I can't judge how this might ripple up to what I do. I would love a visual graph of dependencies, perhaps with line thickness annotating how strong a tie there is, etc. I want to be able to "see OSS interactions" through views created by Gump. So, for me it is all about views/insights/introspections/maps, hence I like what folks can do with a cocoon/forrest webapp -- and graphs/charts/images. Anything that allows us (perhaps dynamically on demand) to drill into this information... regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Enigma : build of xdoclet
Adam Jack wrote: Interesting. LSD took 7 hours to run, which is 3 hours longer than usual. Just for reference - I can see at least a couple of "Error - Failed with reason build timed out" on three avalon projects (which were all ok before). Steve. -- || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/merlin/distributions/latest| || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Enigma : build of xdoclet
Interesting. LSD took 7 hours to run, which is 3 hours longer than usual. Gump.try was swamped by a tonne of Java processes (that looked like ant forking ant) and I had to kill it. I suspect you are right this is looping on itself. Stefan, if this due to Python Gump using the hard coded 'clone vm' on ant, perhaps? Anybody able to get inside this? BTW: We really need to fix this: http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-35 'cos even though Gump moves on when these things happens, it doesn't get the cycles it needs 'cos it is fighting these undead. regards, Adam - Original Message - From: "Antoine Lévy-Lambert" <[EMAIL PROTECTED]> To: "Gump code and data" <[EMAIL PROTECTED]> Sent: Friday, March 26, 2004 9:57 AM Subject: 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.h tml > > > - > 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/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]
cvs commit: gump/blog/SuccessStories jrefactory.txt
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.txt26 Mar 2004 17:02:55 - 1.2 +++ jrefactory.txt26 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: cvs commit: gump/blog/SuccessStories jrefactory.txt
Formating looks funny Take a look at http://gump.chalko.com/gb/blog/SuccessStories?preview=true&smm=y&permalink=jrefactory.txt And then release when it looks the way you want. [EMAIL PROTECTED] wrote: nickchalko2004/03/26 09:02:55 Modified:blog/SuccessStories jrefactory.txt Log: Changed to preview until the format is right. PR: Obtained from: Submitted by: Reviewed by: CVS: -- CVS: PR: CVS: If this change addresses a PR in the problem report tracking CVS: database, then enter the PR number(s) here. CVS: Obtained from: CVS: If this change has been taken from another system, such as NCSA, CVS: then name the system in this line, otherwise delete it. CVS: Submitted by: CVS: If this code has been contributed to Apache by someone else; i.e., CVS: they sent us a patch or a new module, then include their name/email CVS: address here. If this is your work then delete this line. CVS: Reviewed by: CVS: If we are doing pre-commit code reviews and someone else has CVS: reviewed your changes, include their name(s) here. CVS: If you have not had it reviewed then delete this line. Revision ChangesPath 1.2 +23 -4 gump/blog/SuccessStories/jrefactory.txt Index: jrefactory.txt === RCS file: /home/cvs/gump/blog/SuccessStories/jrefactory.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jrefactory.txt 26 Mar 2004 16:37:40 - 1.1 +++ jrefactory.txt 26 Mar 2004 17:02:55 - 1.2 @@ -1,13 +1,32 @@ -JRefactory adapt their code to changes in jaxen/saxpath +PREVIEW JRefactory adapt their code to changes in jaxen/saxpath - +Preview at +http://gump.chalko.com/gb/blog/SuccessStories?preview=true&smm=y&permalink=jrefactory.txt + + + + issue of line ending with PrettyPrinter task - + I had found a problem with the PrettyPrinter task supplied by JRefactory. Without any clear announcement, the JRefactory team had changed their PrettyPrinter task to delegate processing of line endings to the ant fixcrlf task - which is good. - + As a consequence, the acceptable values for the lineending setting of PrettyPrinter changed to become the one's of ant's fixcrlf task. - 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]
cvs commit: gump/blog/SuccessStories jrefactory.txt
nickchalko2004/03/26 09:02:55 Modified:blog/SuccessStories jrefactory.txt Log: Changed to preview until the format is right. PR: Obtained from: Submitted by: Reviewed by: CVS: -- CVS: PR: CVS: If this change addresses a PR in the problem report tracking CVS: database, then enter the PR number(s) here. CVS: Obtained from: CVS: If this change has been taken from another system, such as NCSA, CVS: then name the system in this line, otherwise delete it. CVS: Submitted by: CVS: If this code has been contributed to Apache by someone else; i.e., CVS: they sent us a patch or a new module, then include their name/email CVS: address here. If this is your work then delete this line. CVS: Reviewed by: CVS: If we are doing pre-commit code reviews and someone else has CVS: reviewed your changes, include their name(s) here. CVS: If you have not had it reviewed then delete this line. Revision ChangesPath 1.2 +23 -4 gump/blog/SuccessStories/jrefactory.txt Index: jrefactory.txt === RCS file: /home/cvs/gump/blog/SuccessStories/jrefactory.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jrefactory.txt26 Mar 2004 16:37:40 - 1.1 +++ jrefactory.txt26 Mar 2004 17:02:55 - 1.2 @@ -1,13 +1,32 @@ -JRefactory adapt their code to changes in jaxen/saxpath +PREVIEW JRefactory adapt their code to changes in jaxen/saxpath - +Preview at +http://gump.chalko.com/gb/blog/SuccessStories?preview=true&smm=y&permalink=jrefactory.txt + + + + issue of line ending with PrettyPrinter task - + I had found a problem with the PrettyPrinter task supplied by JRefactory. Without any clear announcement, the JRefactory team had changed their PrettyPrinter task to delegate processing of line endings to the ant fixcrlf task - which is good. - + As a consequence, the acceptable values for the lineending setting of PrettyPrinter changed to become the one's of ant's fixcrlf task. - 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]
cvs commit: gump/blog/SuccessStories jrefactory.txt
antoine 2004/03/26 08:37:40 Added: blog/SuccessStories jrefactory.txt Log: Blog concerning jrefactory Revision ChangesPath 1.1 gump/blog/SuccessStories/jrefactory.txt Index: jrefactory.txt === JRefactory adapt their code to changes in jaxen/saxpath issue of line ending with PrettyPrinter task I had found a problem with the PrettyPrinter task supplied by JRefactory. Without any clear announcement, the JRefactory team had changed their PrettyPrinter task to delegate processing of line endings to the ant fixcrlf task - which is good. 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] Updated: NewUserIntroduction
Date: 2004-03-26T08:24:12 Editor: 12.144.199.2 <> Wiki: Gump Wiki Page: NewUserIntroduction URL: http://wiki.apache.org/gump/NewUserIntroduction no comment Change Log: -- @@ -3,7 +3,7 @@ This paper is not even close to being finished or readable. Please move along...or help write it! -Some things I want to persue here... +Some things I want to pursue here... * leasury reading * broad overview @@ -123,4 +123,14 @@ '''it's not about features, it's about community.''' -= + + + += Please don't take this comment the wrong way, but you have not answered the question: "What is Gump?" = +I appreciate your comments about social community, but what is the purpose of that community? +If you don't tell me what Gump can do for me, why would I want to join your community? + +I think that Gump is a tool that allows me to access coordinated builds of ASF projects... +Or maybe it just notifies me when a new version of an ASF project is incompatible with other projects. +Is Gump something the developer of any project should care about, or only the developers of infrastructure projects? += - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: About ForrestCocoon was: Gump Thrashing/Spinning...
Adam Jack wrote: Forrest uses cocoon (http://cocoon.apache.org/2.0/) Which is a servlet that does xml pipelines XML -> transform -> transform --> xml (or whatever) out. Along with caching all kinds of other cool stuff. That is what you get when you use the "forrest run" command Because many, many of our pages are never visited this might actually reduce the computational load. Yup, seems highly likely. It also means that if Forrest barfs on a certain page we still get access to the other pages. Forrest can use simple HTML if you save it as *.ihtml My suggestion would be to generate a Forrest usable site with ihtml pages using cheetah, and then publish it so that a dynamic Forrest can show it nicely skinned. This way we get the best of all: 1 - use templates 2 - can see pages without running Forrest 3 - don't even need to run static Forrest -- 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]
Gump on Moof
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
Re: Generating HTML (was Gump Threashing/Spinning)
> > > Now Gump generates it's xdocs using an object tree structure. Watching > the > > > python memory grow from 20M (after loading all XML) to 136M (during > > > generating these pages) it has some sort of leak (actual or effective) > > > > ouch! Maybe it would pay off to use pipelining (you know, SAX, stuff) > > instead of DOM to generate the object tree. > > I wonder if it is some sort of circular dependency (amonst the objects) so > when I destroy a tree (by pointing the variable to a new one) I wonder if it > truely gets destroyed. I know the DOM has an unlink() method for some good > reason, along these lines. > > There is so much thrown up into memory, more with translations to try to > cope with character sets (and binary junk) and such. I no longer believe > that any is being thrown away when I mean it to be... Adding an unlink() to the tree, and calling it, seems to keep memory usage down to 36M and not 136M. Seems Python needs a hand in recognizing when things are no longer used. BTW: It seems I've persuaded forrest to play happily again by removing the 'dependency path' (from cause to project) that I'd added. No clue why, but whatever. Gump ran on LSD last night, although it still took a long long time. However, we are closer to normal again & able to install on Apache hardware as a valid test. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: About ForrestCocoon was: Gump Thrashing/Spinning...
> Forrest uses cocoon (http://cocoon.apache.org/2.0/) > Which is a servlet that does xml pipelines > XML -> transform -> transform --> xml (or whatever) out. > Along with caching all kinds of other cool stuff. > That is what you get when you use the "forrest run" command > > Because many, many of our pages are never visited this might actually > reduce the computational load. Yup, seems highly likely. It also means that if Forrest barfs on a certain page we still get access to the other pages. > So for us that means we run tomcat with a forrest install and then just > push our xdocs to the right location. > When a users visits a page that the xml underneath has been updated the > page will regenerate. Cool. So I assume we simply copy (sync) the xdocs into the 'log' directory, and not run forrest & copy(sync) outputs. It is a shame that each run will generate new xdocs, even though the real content may not change, but that doesn't seem too painful. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BATCH: All dressed up, with nowhere to go...
Dear Gumpmeisters, The following 9 nags should have been sent G U M P [EMAIL PROTECTED]: webwork/webwork failed [EMAIL PROTECTED]: mx4j/mx4j-tools-from-packaged-jetty failed [EMAIL PROTECTED]: freemarker/freemarker failed [EMAIL PROTECTED]: jakarta-tapestry/ognl failed [EMAIL PROTECTED]: javasrc/javasrc failed [EMAIL PROTECTED]: xml-xerces/xml-xerces1 failed [EMAIL PROTECTED]: jakarta-turbine-tdk/jakarta-turbine-tdk-docs failed [EMAIL PROTECTED]: eyebrowse/eyebrowse failed [EMAIL PROTECTED]: jgen/jgen failed G U M P [EMAIL PROTECTED]: webwork/webwork failed To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://gump.apache.org/nagged.html, and/or contact [EMAIL PROTECTED] Project webwork has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 4 runs. The current state is 'Failed', for reason 'Build Failed' Full details are available at: http://lsd.student.utwente.nl/gump/webwork/webwork.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Info - Enable "verbose" output, due to 3 previous error(s). - Error - Failed with reason build failed - Info - Enable "debug" output, due to build failure. - - - - - -- -- G U M P Gump performed this work: Work Name: build_webwork_webwork (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 13 seconds Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xml-apis.jar:/data3/gump/xml-xalan/java/build/xalan-unbundled.jar:/data3/gump/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/data3/gump/gump-install/work/merge.xml -Dbuild.sysclasspath=only [Working Directory: /data3/gump/webwork] - [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:69: cannot resolve symbol [javac] symbol : class MultipartListener [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartListener listener = new MultipartListener() [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:69: cannot resolve symbol [javac] symbol : class MultipartListener [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartListener listener = new MultipartListener() [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:92: cannot resolve symbol [javac] symbol : class MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] multi = new MultipartRequest(req.getContentType(), [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:96: cannot resolve symbol [javac] symbol : variable MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartRequest.IGNORE_FILES_IF_MAX_BYES_EXCEEDED, [javac]^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:102: cannot resolve symbol [javac] symbol : class MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] multi = new MultipartRequest(req.getContentType(), [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:107: cannot resolve symbol [javac] symbol : variable MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartRequest.IGNORE_FILES_IF_MAX_BYES_EXCEEDED, [javac]^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 15 errors BUILD FAILED /data3/gump/webwork/build.xml:167: Compile failed; see the compiler error output for details. at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:938) at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:268) at org.apache.tools.ant.Task.perform(Task.java:363) at org.apache.tools.ant.Target.execute(Target.java:301) at org.apache.tools.ant.Target.performTasks(Target.java:328) at org.apache.tools.ant.Project.execu
cvs commit: gump/project ant.xml
bodewig 2004/03/26 05:09:37 Modified:project ant.xml Log: Some jar renames, take advantage of JAI from jrefactory Revision ChangesPath 1.15 +7 -5 gump/project/ant.xml Index: ant.xml === RCS file: /home/cvs/gump/project/ant.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- ant.xml 27 Feb 2004 13:33:56 - 1.14 +++ ant.xml 26 Mar 2004 13:09:37 - 1.15 @@ -81,6 +81,7 @@ + @@ -88,24 +89,25 @@ + + + + - - + - - + - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump Architecture
On Thu, 25 Mar 2004, Leo Simons <[EMAIL PROTECTED]> wrote: > Traditional gump has this architecture. > > On completion, some other script files are or can be run to do some > other things (like send out failure notifications). which is done by a Perl script, which just adds to the tool mix of "traditional" Gump. > (Scripts are available to check things directly provided you have > console access to the server, but only a handful of people > (approximately 4 or 5 on the planet) know how to use them But note that if you know how to use them, debugging a Gump build becomes very effective and avoids the "wait 24 hours" part. We really need an equivalent of this in whatever Gump ends up to be in future iterations. Be it easier to use scripts on a server everybody has access to or be it via a build-on-demand webapp. > Replace this batch concept with a command/action/event > concept. I think we need both. We will always want to have some sort of "nightly Gump build" that ensures that all projects will be updated and built. In the end the batch concept can be emulated by pushing the command in via a batch job. > - Get rid of the "giant tree transformations". It has proven to > scale only with difficulty. If you separate the graph building from the commands, then submitting commands will need some help by the system. I wouldn't want to figure out which projects I have to build first when I say "update and build ant". The batch-like part I've talked about above will still need the full graph, but I agree that the full graph doesn't need to be - and maybe even shouldn't be - the core part of Gump. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] My personal roadmap for gump
On Wed, 24 Mar 2004, Leo Simons <[EMAIL PROTECTED]> wrote: > Yada yada yada. Could go on for a while, but I won't. Let's hear > about you! :-D Luckily Gump has enough visionaries to leave room for the pragmatics, one of whom is me. ;-) I know that I don't have infinite time to spend on Gump (or anything else) and I really hate it when I start things and know I won't be able to finish them. So I try to focus on the places where I can be most effective. Right now I concentrate on getting as many things buildable as possible. By getting the metadata correct and the dependencies straight I'm far more effective for Gump than by fiddling with Python. It has been fun to go back and forth together with Niclas until we finally had most of Avalon building. I try to avoid the "wait 24 hours" part of Leo's other [RT] by offering my Gump setup for tests. This means that I don't have time to get up-to-speed with Python to help with actual Gumpy development. I can comment and chime in into the discussion and that's what I do. Having said that, my primary goals for Gump - after being able to build as much as possible - are support for different build systems (Maven, NAnt, make, ...) and making Gump reach beyond Java. The .NET platform may be tricky given the instability of Mono for non-Intel platforms (and in particular for non-Linux OSes on non-Intel platforms), but in the end I'd like us to be able to offer Gump as a service to the whole of the ASF. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP][PATCH] more dependencies
Hi, after the avalon dependency now works (in my local install), there are new compilation issues, that I hope to resolve with the appended path. cocoon-javac is no good name for whatever lives in javacApi-0.9.jar, feel free to provide something better plus some description and where to find it - I have no idea what it is. I also don't know whether the build will actually need the impl jar as well, cocoon will probably need the impl jar at runtime. Cheers Stefan Index: gump.xml === RCS file: /home/cvspublic/cocoon-2.1/gump.xml,v retrieving revision 1.134 diff -u -r1.134 gump.xml --- gump.xml25 Mar 2004 14:24:57 - 1.134 +++ gump.xml26 Mar 2004 09:11:33 - @@ -66,12 +66,13 @@ + + - @@ -1234,6 +1235,11 @@ + + + +org.tempuri.javac + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
