RE: Standing back (for a while?)...
Niclas (and Gang), I can understand how you feel, and I think that part of the issue is that building from the latest and greatest all the way up and down the tree is somewhat of an impossible task. I know for example that until commons-configuration does another release, fulcrum-configuration won't build due to API changes. Right now, everybody is failing because Velocity hasn't kept up with Log4j. And, on a certain level, expecting a component to keep up with CVS head of another component isn't realisitic. The things that I think would help are: 1) Identifiable people for each component. If there ISN'T an Apache owner for a component, it should be a library. We need someone who will get the fix in ASAP when the build fails. Jakarta-velocity has been broken for 33 runs, leading to either 150 or 165 projects to not attempt to build. Who will fix it? 2) Need the fallback! With jakarta-velocity failing, Gump apparently tries but fails to fallback to the previously built version. The fallback is crucial to prevent the small errors from creeping in. 3) Don't email me when a dependency starts building and therefore I build. I don't care if I build successfully because a dependency built. I only care when I fail. When something with a lot of dependencies builds, I get spammed a million times by Gump, which leads to the Gump being ignored syndrome. My 2 cents, and I hope after a breather you rejoin! You've personally done a lot to help me learn Gump, and get the fulcrum components to build happily. Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 8:36 AM To: [EMAIL PROTECTED] Subject: Standing back (for a while?)... Gang, I have decided to step away from Gump for a while, and the main reason is that I find it depressing to work with... Increments of overall success is slow, and decrements of overall success is fast. And during the period of big showstoppers, entropy sets in in all non-building projects so that when the big showstopper is resolved, a lot of small cases are back. I find that there must be something fundamentally wrong with Gump, if it self-deteriorate so quickly. Personally I think the solution is that the Gump group needs to work more intimately with the Ant/Maven and other build system groups, to put in the continous integration support directly into those tools, instead of the manual labour of bolting it on externally. I might be back later, but for now I wish you all Good Luck. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - 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]
BATCH: All dressed up, with nowhere to go...
Dear Gumpmeisters, The following 6 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Module village success, but with warnings. [EMAIL PROTECTED]: Module town success, but with warnings. [EMAIL PROTECTED]: Project txt2html-task (in module jakarta-servletapi-5) success, but with warnings. [EMAIL PROTECTED]: Module struts success, but with warnings. [EMAIL PROTECTED]: Project jtidy-cvs (in module jtidy) failed [EMAIL PROTECTED]: Project jetty-plus (in module jetty) failed *** G U M P [EMAIL PROTECTED]: Module village success, but with warnings. To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Module village contains errors. The current state of this module is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/village/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://brutus.apache.org/gump/public/village/gump_work/update_village.html Work Name: update_village (Type: Update) Work ended in a state of : Failed Elapsed: 3 mins 9 secs Command Line: cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:2401/home/cvspublic update -P -d -A [Working Directory: /usr/local/gump/public/workspace/cvs/village] - cvs [update aborted]: connect to share.whichever.com(157.22.245.10):2401 failed: Connection timed out - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/village/rss.xml - Atom: http://brutus.apache.org/gump/public/village/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 3029112004, brutus:brutus-public:3029112004 Gump E-mail Identifier (unique within run) #1. *** G U M P [EMAIL PROTECTED]: Module town success, but with warnings. To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Module town contains errors. The current state of this module is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/town/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://brutus.apache.org/gump/public/town/gump_work/update_town.html Work Name: update_town (Type: Update) Work ended in a state of : Failed Elapsed: 3 mins 11 secs Command Line: cvs -q -z3 -d :pserver:[EMAIL PROTECTED]:2401/home/cvspublic update -P -d -A [Working Directory: /usr/local/gump/public/workspace/cvs/town] - cvs [update aborted]: connect to share.whichever.com(157.22.245.10):2401 failed: Connection timed out - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/town/rss.xml - Atom: http://brutus.apache.org/gump/public/town/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 3029112004, brutus:brutus-public:3029112004 Gump E-mail Identifier (unique within run) #2. *** G U M P [EMAIL PROTECTED]: Project txt2html-task (in module jakarta-servletapi-5) success, but with warnings. To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project txt2html-task contains errors. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-servletapi-5/txt2html-task/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [ant] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/ant] -INFO- No license on redistributable project with outputs. -ERROR- Failed to publish [/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/build/ant] to repository : [Errno 21] Is a directory The following work was performed:
Re: Standing back (for a while?)...
Niclas Hedhman wrote: I have decided to step away from Gump for a while, and the main reason is that I find it depressing to work with... Increments of overall success is slow, and decrements of overall success is fast. And during the period of big showstoppers, entropy sets in in all non-building projects so that when the big showstopper is resolved, a lot of small cases are back. dude, I know how you feel! I find that there must be something fundamentally wrong with Gump, if it self-deteriorate so quickly. hmm. I think that the basic outline you've given above is correct. It simply is much easier to destroy a build (give me any java project out there and I can stop it from building with a single-character change in one file. Probably can do it blind-folded, too.) than to fix one. That said, we can change *a lot* about those negative feelings. Work in progress. Suggestions (complaints, even!) welcome. Personally I think the solution is that the Gump group needs to work more intimately with the Ant/Maven and other build system groups, to put in the continous integration support directly into those tools, instead of the manual labour of bolting it on externally. hmm. In the case of ant, it'll just have to be bolted on since it doesn't have a metadata descriptor model. You might call the stuff you bolt on magic or maven or whatever. The same will probably remain true for tools that build using configure make make test. I might be back later, but for now I wish you all Good Luck. thanks for all your hard work. Let's hope gump evolves into something that makes you want to come back and continue your efforts ;) cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Picking up the ball from Niclas (ugh!) on Velocity
So, I thought I would just submit a patch to Velocity to fix the velocity/log4j problem and everything would be fine. Wrong.. The issue is the non backwards compatible API change to log4j. And, I saw Niclas email about it as well. So, I dug some more and according to this email: http:[EMAIL PROTECTED]/2004-11/msg00271.html there is a binary version. So I thought hey, use that.. Only to discover that Gump can check out a tagged branch of code! And that there is a project called logging-log4j-12.xml already building that most dependees of log4j use. So, I made the change, and that should fix Velocity... Of course, it basically is like dynamically building a package.. Fulcrum Configuration relies on the older version of commons-configuration. I am going to apply the same trick there. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
Eric Pugh wrote: So, I thought I would just submit a patch to Velocity to fix the velocity/log4j problem and everything would be fine. Wrong.. The issue is the non backwards compatible API change to log4j. And, I saw Niclas email about it as well. So, I dug some more and according to this email: http:[EMAIL PROTECTED]/2004-11/msg00271.html there is a binary version. So I thought hey, use that.. Only to discover that Gump can check out a tagged branch of code! And that there is a project called logging-log4j-12.xml already building that most dependees of log4j use. So, I made the change, and that should fix Velocity... Of course, it basically is like dynamically building a package.. Fulcrum Configuration relies on the older version of commons-configuration. I am going to apply the same trick there. I have spoken to Geir Magnuson, who was not aware that velocity was being a problem and I indicated the problem and he said he would solve it in a few minutes. People, Gump is *NOT* about 100% success. Gump is about establishing communication channels between development communities. If you are interested in the first and not in the second, run a cron job every night on your build files and send your list an email if that build goes wrong. it's a two seconds job and I'll be happy to give access to brutus if you need that. On the other hand, if you are interested in creating a social engineering support tool and you are willing to get your hands dirty in python and prepare to have a huge ton of patience to convert a few hundreds people to a very difficult concept, then stick around for a few more years, because that's how much it will take before gump can be considered a success. The recent 'velocity stall' indicates that our way to signal problems is too noisy to convey information and Eric identified a few issues that I also have. The rule should be to start fixing gump and fix the communication channels rather than fixing the metadata to route around the problems. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Picking up the ball from Niclas (ugh!) on Velocity
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Gump is about establishing communication channels between development communities. ROTFLOL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
kaffe on brutus
Can someone with root on brutus run apt-get update kaffe (or let me do it :) [18:47] dalibor hi dims [18:47] dalibor still didn't get around to address the gump failure, ended up spending a lot of time merging in some new nio code fomr classpath first ... [18:50] dims dalibor: how do i update kaffee on brutus? [18:51] dims from a nightly build of kaffe? [18:52] dalibor dims, there are no debs of nightlies yet. but you could try apt-get update kaffe to fetch the latest version [18:52] dalibor other than that, I could ask avdyk to snapshot the current code and prepare a nightly deb for experimental [18:52] dims that would be awesome!!! [18:53] dims i will ask folks for karma to run apt-get update kaffe Thanks, dims -- Davanum Srinivas - http://webservices.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: kaffe on brutus
hmmmdidn't help. same problem as before. dalibor promised another version in unstable tomorrow. -- dims java.lang.StackOverflowError at java.util.zip.ZipEntry.setCompressedSize (ZipEntry.java) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.apache.tools.zip.ZipEntry.performSetCompressedSize (ZipEntry.java:426) at org.apache.tools.zip.ZipEntry.setComprSize (ZipEntry.java:352) at org.apache.tools.zip.ZipOutputStream.closeEntry (ZipOutputStream.java:356) at org.apache.tools.zip.ZipOutputStream.finish (ZipOutputStream.java:299) at org.apache.tools.zip.ZipOutputStream.close (ZipOutputStream.java:489) at org.apache.tools.ant.taskdefs.Zip.executeMain (Zip.java:502) at org.apache.tools.ant.taskdefs.Zip.execute (Zip.java:323) On Mon, 29 Nov 2004 18:00:14 -0800, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Davanum Srinivas wrote: Can someone with root on brutus run apt-get update kaffe (or let me do it :) [18:47] dalibor hi dims [18:47] dalibor still didn't get around to address the gump failure, ended up spending a lot of time merging in some new nio code fomr classpath first ... [18:50] dims dalibor: how do i update kaffee on brutus? [18:51] dims from a nightly build of kaffe? [18:52] dalibor dims, there are no debs of nightlies yet. but you could try apt-get update kaffe to fetch the latest version [18:52] dalibor other than that, I could ask avdyk to snapshot the current code and prepare a nightly deb for experimental [18:52] dims that would be awesome!!! [18:53] dims i will ask folks for karma to run apt-get update kaffe I just performed an apt-get upgrade on brutus. Kaffe was upgraded to version 1.1.4.PRECVS3-20041030 -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas - http://webservices.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
On Tuesday 30 November 2004 07:45, Stefano Mazzocchi wrote: Gump is about establishing communication channels between development communities. On the other hand, if you are interested in creating a social engineering support tool and you are willing to get your hands dirty in python and prepare to have a huge ton of patience to convert a few hundreds people to a very difficult concept, The rule should be to start fixing gump and fix the communication channels rather than fixing the metadata to route around the problems. Cool, but then you told me Don't change people we should work around them [projects not willing to co-operate]... I would call that mixed signals... ;o) Cheers Niclas P.S. Let me know when you figured out that Java is a better tool after all :o) so I can help more actively. -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - 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 10 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Project beepcore (in module beepcore) failed [EMAIL PROTECTED]: Project castor (in module castor) failed [EMAIL PROTECTED]: Project xml-security-tests (in module xml-security) failed [EMAIL PROTECTED]: Project invicta (in module invicta) failed [EMAIL PROTECTED]: Project struts-sslext (in module struts-sslext) failed [EMAIL PROTECTED]: Project jetty (in module jetty) failed [EMAIL PROTECTED]: Project jakarta-site2 (in module jakarta-site2) failed [EMAIL PROTECTED]: Project eyebrowse (in module eyebrowse) failed [EMAIL PROTECTED]: Project maven (in module maven) failed [EMAIL PROTECTED]: Project maven-bootstrap (in module maven) failed *** G U M P [EMAIL PROTECTED]: Project beepcore (in module beepcore) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project beepcore has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - beepcore : BEEP is a new Internet standards-track protocol Full details are available at: http://brutus.apache.org/gump/public/beepcore/beepcore/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [beepcore.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-logging unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/beepcore/beepcore/rss.xml - Atom: http://brutus.apache.org/gump/public/beepcore/beepcore/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #21. *** G U M P [EMAIL PROTECTED]: Project castor (in module castor) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project castor has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - castor : Java to XML, SQL, LDAP bindings Full details are available at: http://brutus.apache.org/gump/public/castor/castor/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [castor-29112004.jar] identifier set to output basename: [castor] -DEBUG- Output [castor-29112004-xml.jar] identifier set to output basename: [castor-29112004-xml] -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: commons-logging unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/castor/castor/rss.xml - Atom: http://brutus.apache.org/gump/public/castor/castor/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18002129112004, brutus:brutus-public:18002129112004 Gump E-mail Identifier (unique within run) #23. *** G U M P [EMAIL PROTECTED]: Project xml-security-tests (in module xml-security) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-security-tests has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - xml-security-tests : XML-Signature Syntax and Processing Full details are available at: http://brutus.apache.org/gump/public/xml-security/xml-security-tests/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on jce exists, no need to add for
