Re: Gump and APR
On Fri, 26 Nov 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: I'll try to get some minimal make builder working next week to see where we get. I've created configure and make builders and will try them on some minimal test workspace of mine tomorrow (hard to do some real tests without anything but http and smtp). What I did was some monkey-see monkey.do and I won't pretend I actually know what I've done 8-) But I've seen a lot of cut-n-paste reuse (and even added to it), maybe I'll read more than just Dive into Python some day. What seemed to be the unit tests (in the gump/test dir) turned out to not work (imports some gump,core stuff that is nowhere to find). I realized that when I tried to write my own tests. Leo, I vaguely recall you added some test stuff, any pointers where I should start for my own tests? Stefan - 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 jakarta-velocity failed [EMAIL PROTECTED]: Project werken.xpath (in module jakarta-velocity) failed [EMAIL PROTECTED]: Module village success, but with warnings. [EMAIL PROTECTED]: Project xml-xerces1 (in module xml-xerces) failed [EMAIL PROTECTED]: Module town success, but with warnings. [EMAIL PROTECTED]: Module struts success, but with warnings. *** G U M P [EMAIL PROTECTED]: Module jakarta-velocity 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] Module jakarta-velocity has an issue affecting its community integration. The current state of this module is 'Failed', with reason 'Configuration Failed'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-velocity/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason configuration failed -ERROR- No such repository [jakarta-svn] in workspace on [jakarta-velocity] To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-velocity/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-velocity/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 1730112004, brutus:brutus-public:1730112004 Gump E-mail Identifier (unique within run) #1. *** G U M P [EMAIL PROTECTED]: Project werken.xpath (in module jakarta-velocity) 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 werken.xpath has an issue affecting its community integration. The current state of this project is 'Failed', with reason 'Configuration Failed'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-velocity/werken.xpath/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason configuration failed -DEBUG- Sole output [werken.xpath.jar] identifier set to project name -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-velocity/werken.xpath/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-velocity/werken.xpath/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 1730112004, brutus:brutus-public:1730112004 Gump E-mail Identifier (unique within run) #2. *** 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 14 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 1730112004, brutus:brutus-public:1730112004 Gump E-mail Identifier (unique within run) #3. *** G U M P [EMAIL PROTECTED]: Project xml-xerces1 (in module xml-xerces) failed To whom it may engage... This is an automated request,
RE: Picking up the ball from Niclas (ugh!) on Velocity
I think what he means is that we can't expect people to make changes just to make Gump happy. But, we can *attempt* to influence them to help. And I think that is where we are going wrong. For instance, Fulcrum components didn't build very well until I got involved (and got lots of help!).. You need a committer from the project being gumped to keep things running well. As far as I know, there are no log4j committers actively involved in keeping gump working. Hence, they made a backwards incompatible change, and the fact that gump keeled over doesn't bother then. Now, partly that may be a communication thing.. If Log4j fails, they get emailed. If log4j breaks every body else, they don't... Without active involvement by a group, the prospect of keeping things working becomes a thankless task (witness Niclas's frustration). I thought hey, I'll try and help and ran into, in an hour, the same frustration Niclas sees.. I am not a committer (or even involved beyond the occasional email) with Log4j or Velocity, so who do I got to prod for action? Geir's email highlights a very clear issue with the whole deprecation/version cycle. He can't switch to log4j until it releases. They don't want to keep deprecated code around for forever. I'll argue that neither party is at fault. It's just an icky sore spot that will be worked out at somepoint, and gump is just bringing up the incompatiblity sooner. I'd like Gump to now just say Yes, log4j HEAD fails on Velocity, lets step back to the last successful build with Velocity and use that, or, we work around it by building in Gump the older version (logging_log4j_12) and use that. I don't specifically think it is a tooling issue.. This stuff is hard, and while some rote stuff could be made simpler with better tooling, we are always going to have odd situations to deal with. So, I'll again argue about the benefit of packages/custom branches.. We need to build up mindshare the gump is this great build tool/continous integration tool. But we certainly can't wait a couple years, and I think that certain components that break frequently need to be packaged to provide some stability, as well as pruning some leaves that never build. Anything that hasn't built in the last 300 cycles for instance should be canned! At least, until we get some stability in gump... Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 6:36 AM To: Gump code and data Subject: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump and APR
Stefan Bodewig wrote: On Fri, 26 Nov 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: I'll try to get some minimal make builder working next week to see where we get. I've created configure and make builders and will try them on some minimal test workspace of mine tomorrow (hard to do some real tests without anything but http and smtp). What I did was some monkey-see monkey.do and I won't pretend I actually know what I've done 8-) But I've seen a lot of cut-n-paste reuse (and even added to it), maybe I'll read more than just Dive into Python some day. :-D What seemed to be the unit tests (in the gump/test dir) turned out to not work (imports some gump,core stuff that is nowhere to find). I realized that when I tried to write my own tests. I got some of them to work for me the other day.lemme try and fix that...bummer. Not now... Leo, I vaguely recall you added some test stuff, any pointers where I should start for my own tests? well, the current stuff in python/gump/test uses a custom unit testing package instead of the standard python 'unittest'. I got halfway through changing our existing tests to use unittest, but ran out of time. Maybe I'll get to it this weekend. I just committed a fix to the 'gump' script I'd been working on. Doing a cd ~/svn/gump/trunk svn up ./gump experimental-tests should give you an idea of how to start with setting up tests. This runs stuff in the src/py directory, since we still need to fix python/gump/test to work with the bin/testrunner.py script. ./gump test doesn't work atm though :/ cheers, LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
On Nov 30, 2004, at 6:19 AM, Eric Pugh wrote: I think what he means is that we can't expect people to make changes just to make Gump happy. But, we can *attempt* to influence them to help. And I think that is where we are going wrong. For instance, Fulcrum components didn't build very well until I got involved (and got lots of help!).. You need a committer from the project being gumped to keep things running well. As far as I know, there are no log4j committers actively involved in keeping gump working. Hence, they made a backwards incompatible change, and the fact that gump keeled over doesn't bother then. Now, partly that may be a communication thing.. If Log4j fails, they get emailed. If log4j breaks every body else, they don't... Without active involvement by a group, the prospect of keeping things working becomes a thankless task (witness Niclas's frustration). I thought hey, I'll try and help and ran into, in an hour, the same frustration Niclas sees.. I am not a committer (or even involved beyond the occasional email) with Log4j or Velocity, so who do I got to prod for action? Geir's email highlights a very clear issue with the whole deprecation/version cycle. He can't switch to log4j until it releases. They don't want to keep deprecated code around for forever. I'm not asking for forever. Just one version... even a short lived one... My take away lesson is really more of a reaffirmation - don't depend on outside things if you can help it... -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - 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 20:18, Geir Magnusson Jr wrote: On Nov 30, 2004, at 6:19 AM, Eric Pugh wrote: Geir's email highlights a very clear issue with the whole deprecation/version cycle. He can't switch to log4j until it releases. They don't want to keep deprecated code around for forever. I'm not asking for forever. Just one version... even a short lived one... My take away lesson is really more of a reaffirmation - don't depend on outside things if you can help it... Log4J has otherwise been very generous with having deprecated code around, but when I asked explicitly if this was a chagne for 1.3 and whether that means that everyone who uses RFA have to change the config files, I got from Ceki the answer; Yes to those two questions. Very strange change of attitude, and I don't know why this is happening. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: failure notice
On Tuesday 30 November 2004 21:32, Ceki Glc wrote: At 03:39 AM 11/30/2004, Geir Magnusson Jr wrote: anyway, the interesting thing is the problem I have fixing Velocity so Gump is happy ... Niclas Hedhman informed us of this problem. There was a conscious choice to remove the old RollingAppender and replace with something better. Gump is just a fuzzy user ;o) So irregardless of that, how come this mainly incompatible change is being made in a .x release? Wouldn't it be so much better to keep the old RFA still in there with a massive deprecated sign (possibly in the outputs as well), for one cycle? Even better if the older one delegates to the newer one, but that is less important... As the HEAD now is, you are asking an enormous amount of people to make changes if they want to upgrade to a newer version, which on paper (if anyone ever believes the Dewey convention) says it is a compatible upgrade with more features. But, then again, I am perhaps too sensitive and lazy, to see the beauty of culling the class without warning. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
On Nov 30, 2004, at 8:18 AM, Niclas Hedhman wrote: On Tuesday 30 November 2004 20:18, Geir Magnusson Jr wrote: On Nov 30, 2004, at 6:19 AM, Eric Pugh wrote: Geir's email highlights a very clear issue with the whole deprecation/version cycle. He can't switch to log4j until it releases. They don't want to keep deprecated code around for forever. I'm not asking for forever. Just one version... even a short lived one... My take away lesson is really more of a reaffirmation - don't depend on outside things if you can help it... Log4J has otherwise been very generous with having deprecated code around, but when I asked explicitly if this was a chagne for 1.3 and whether that means that everyone who uses RFA have to change the config files, I got from Ceki the answer; Yes to those two questions. Very strange change of attitude, and I don't know why this is happening. Yes, historically, log4j has bent over backwards to make things easy for users. geir Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: failure notice
On Nov 30, 2004, at 8:32 AM, Ceki Gülcü wrote: At 03:39 AM 11/30/2004, Geir Magnusson Jr wrote: some lists choose to moderate... Hello Geir, We currently don't but may switch back to moderated list. Sorry about the hassle. anyway, the interesting thing is the problem I have fixing Velocity so Gump is happy ... Niclas Hedhman informed us of this problem. There was a conscious choice to remove the old RollingAppender and replace with something better. That's all well and good, but why not deprecate for a version? To help you solve this problem there several routes exists. First and more philosophically, there is more to software development than keeping gump happy. This is true. 100% But what gump has done here is given us early warning that if one of us doesn't do something, Velocity users [and every other log4j user using RollingFileAppender] are *screwed* if they try to upgrade a minor version number of log4j, to 1.3. Having said that, you can keep gump happy by either switching to FileAppender or keep your own version of RollingFileAppender. If I switch to FileAppender, then the software won't behave the same (right?) or yes, I can take the RollingFileAppender code from you and put in Velocity, but I think that's suboptimal :) What I want is that existing velocity users can upgrade to log4j 1.3 w/o hassle. Perhaps the easiest alternative is to have velocity explicitly tell gump that velocity depends on log4j 1.2.x and not log4j head. Actually this would be he action I would recommended. But forgetting Gump, in general, what do you want me and other users to do? have to modify our code to update to 1.3? geir I hope this helps, Begin forwarded message: From: [EMAIL PROTECTED] Date: November 29, 2004 9:29:02 PM EST To: [EMAIL PROTECTED] Subject: failure notice Hi. This is the qmail-send program at apache.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: Sorry, only subscribers may post. If you are a subscriber, please forward this message to [EMAIL PROTECTED] to get your new address included (#5.7.2) --- Below this line is a copy of the message. Return-Path: [EMAIL PROTECTED] Received: (qmail 13066 invoked by uid 99); 30 Nov 2004 02:29:02 - X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from chi.mobile-health-diary.com (HELO chi.mobile-health-diary.com) (128.241.244.71) by apache.org (qpsmtpd/0.28) with SMTP; Mon, 29 Nov 2004 18:29:02 -0800 Received: (qmail 11965 invoked from network); 30 Nov 2004 02:29:00 - Received: from ool-43560634.dyn.optonline.net (HELO ?10.0.1.2?) ([EMAIL PROTECTED]) by b014.internal.mobile-health-diary.com with SMTP; 30 Nov 2004 02:29:00 - In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: [EMAIL PROTECTED] Content-Transfer-Encoding: quoted-printable Cc: Gump code and data [EMAIL PROTECTED], Log4J Developers List [EMAIL PROTECTED] From: Geir Magnusson Jr [EMAIL PROTECTED] Subject: Re: Gump reporting Date: Mon, 29 Nov 2004 21:28:57 -0500 To: Velocity Developers List [EMAIL PROTECTED] X-Mailer: Apple Mail (2.619) X-Virus-Checked: Checked Why isn't this backwards compatible? I'm trying to fix this, but I can't. There is no released version of =20= log4j that has this change, and I won't have vel based on whatever we =20= can build from head-du-jour. Is there a way to make this backwards compatible? Like deprecate =20 o.a.l.RFA, release so we can switch to o.a.l.rolling.RFA? geir On Nov 28, 2004, at 2:38 PM, Paulo Gaspar wrote: But how do you constrain the use of disk space with the FileAppender? With the RollingFileAppender, that is a simple matter of = configuration. Regards, Paulo Gaspar Ceki G=FClc=FC wrote: Hi Niclas, The change is not not a backward compatible. My suggestion would be =20= use a simple FileAppender instead of RollingFileAppender. At 02:13 PM 11/26/2004, Niclas Hedhman wrote: Hi, http://brutus.apache.org/gump/public/jakarta-velocity/jakarta-=20 velocity/gump_work/build_jakarta-velocity_jakarta-velocity.html Jakarta Velocity is somehow using the RollingFileAppender in code, =20= and I wonder if you guys have moved it from org.apache.log4j.RollingFileAppender to org.apache.log4j.rolling.RollingFileAppender and whether this constitutes a compatible change or not, as I think =20= if this is the case, it will also break a lot of configuration files out there. Thanks for any feedback. Cheers Niclas -- Ceki Gülcü The complete log4j manual: http://qos.ch/eclm Professional log4j support: http://qos.ch/log4jSupport -- Geir Magnusson Jr +1-203-665-6437 [EMAIL
RE: Fwd: failure notice
I actually checked in a change to the gump build to do this.. However, today xerces fell over, so now nobodies running at all.. When it runs again, hopefully we'll see it work. Of course, I may not have done it properly ;-) Eric -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 2:33 PM To: Geir Magnusson Jr Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Fwd: failure notice At 03:39 AM 11/30/2004, Geir Magnusson Jr wrote: some lists choose to moderate... Hello Geir, We currently don't but may switch back to moderated list. Sorry about the hassle. anyway, the interesting thing is the problem I have fixing Velocity so Gump is happy ... Niclas Hedhman informed us of this problem. There was a conscious choice to remove the old RollingAppender and replace with something better. To help you solve this problem there several routes exists. First and more philosophically, there is more to software development than keeping gump happy. Having said that, you can keep gump happy by either switching to FileAppender or keep your own version of RollingFileAppender. Perhaps the easiest alternative is to have velocity explicitly tell gump that velocity depends on log4j 1.2.x and not log4j head. Actually this would be he action I would recommended. I hope this helps, Begin forwarded message: From: [EMAIL PROTECTED] Date: November 29, 2004 9:29:02 PM EST To: [EMAIL PROTECTED] Subject: failure notice Hi. This is the qmail-send program at apache.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: Sorry, only subscribers may post. If you are a subscriber, please forward this message to [EMAIL PROTECTED] to get your new address included (#5.7.2) --- Below this line is a copy of the message. Return-Path: [EMAIL PROTECTED] Received: (qmail 13066 invoked by uid 99); 30 Nov 2004 02:29:02 - X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from chi.mobile-health-diary.com (HELO chi.mobile-health-diary.com) (128.241.244.71) by apache.org (qpsmtpd/0.28) with SMTP; Mon, 29 Nov 2004 18:29:02 -0800 Received: (qmail 11965 invoked from network); 30 Nov 2004 02:29:00 - Received: from ool-43560634.dyn.optonline.net (HELO ?10.0.1.2?) ([EMAIL PROTECTED]) by b014.internal.mobile-health-diary.com with SMTP; 30 Nov 2004 02:29:00 - In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: [EMAIL PROTECTED] Content-Transfer-Encoding: quoted-printable Cc: Gump code and data [EMAIL PROTECTED], Log4J Developers List [EMAIL PROTECTED] From: Geir Magnusson Jr [EMAIL PROTECTED] Subject: Re: Gump reporting Date: Mon, 29 Nov 2004 21:28:57 -0500 To: Velocity Developers List [EMAIL PROTECTED] X-Mailer: Apple Mail (2.619) X-Virus-Checked: Checked Why isn't this backwards compatible? I'm trying to fix this, but I can't. There is no released version of =20= log4j that has this change, and I won't have vel based on whatever we =20= can build from head-du-jour. Is there a way to make this backwards compatible? Like deprecate =20 o.a.l.RFA, release so we can switch to o.a.l.rolling.RFA? geir On Nov 28, 2004, at 2:38 PM, Paulo Gaspar wrote: But how do you constrain the use of disk space with the FileAppender? With the RollingFileAppender, that is a simple matter of = configuration. Regards, Paulo Gaspar Ceki G=FClc=FC wrote: Hi Niclas, The change is not not a backward compatible. My suggestion would be =20= use a simple FileAppender instead of RollingFileAppender. At 02:13 PM 11/26/2004, Niclas Hedhman wrote: Hi, http://brutus.apache.org/gump/public/jakarta-velocity/jakarta-=20 velocity/gump_work/build_jakarta-velocity_jakarta-velocity.html Jakarta Velocity is somehow using the RollingFileAppender in code, =20= and I wonder if you guys have moved it from org.apache.log4j.RollingFileAppender to org.apache.log4j.rolling.RollingFileAppender and whether this constitutes a compatible change or not, as I think =20= if this is the case, it will also break a lot of configuration files out there. Thanks for any feedback. Cheers Niclas -- Ceki Gülcü The complete log4j manual: http://qos.ch/eclm Professional log4j support: http://qos.ch/log4jSupport - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe,
Re: failure notice
At 02:58 PM 11/30/2004, Geir Magnusson Jr wrote: On Nov 30, 2004, at 8:32 AM, Ceki Gülcü wrote: At 03:39 AM 11/30/2004, Geir Magnusson Jr wrote: some lists choose to moderate... Hello Geir, We currently don't but may switch back to moderated list. Sorry about the hassle. anyway, the interesting thing is the problem I have fixing Velocity so Gump is happy ... Niclas Hedhman informed us of this problem. There was a conscious choice to remove the old RollingAppender and replace with something better. That's all well and good, but why not deprecate for a version? Because the old RollingAppender has bugs. Consequently, we don't want to make it available to Mrs. Piggy in the next version of log4j 1.3. But what gump has done here is given us early warning that if one of us doesn't do something, Velocity users [and every other log4j user using RollingFileAppender] are *screwed* if they try to upgrade a minor version number of log4j, to 1.3. What I want is that existing velocity users can upgrade to log4j 1.3 w/o hassle. Log4j 1.3 is currently in alpha. Ignore 1.3 until it goes RC. When it goes RC, switch to 1.3. It should be trivial to do so. But forgetting Gump, in general, what do you want me and other users to do? have to modify our code to update to 1.3? Wait, don't do anything for the time being. Velocity ships with a copy log4j doesn't it? Continue to ship log4j 1.2.9 until you decide to switch to 1.3, for example when it goes RC. Switching velocity to use log4j 1.3 instead of 1.2 should be pretty easy to do. How does that sound? geir -- Ceki Gülcü The complete log4j manual: http://qos.ch/eclm Professional log4j support: http://qos.ch/log4jSupport - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: failure notice
Ceki Gülcü wrote: To help you solve this problem there several routes exists. First and more philosophically, there is more to software development than keeping gump happy. Sure thing. But also, to keep the philosophical tune, when the wise points at the stars, the fool looks at the finger. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Kaffe anyone?
I was just curious why the main Gump run http://brutus.apache.org/gump/public/index.html is using Kaffe? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
Niclas Hedhman wrote: 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) Correct. We don't change people, we try to route around them, but we try first :-) Log4j has been, historically, a very collaborative project, but they (or just Ceki?) seemed to have turned sour. Can't tell why. I don't think he realizes that the reason why people used log4j was exactly this collaborative attitude and, without that, it will be a lot harder to market it. We tried, he's not listening, so we route around him. -- Stefano. - 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 2 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Module jakarta-velocity success [EMAIL PROTECTED]: Project werken.xpath (in module jakarta-velocity) success *** G U M P [EMAIL PROTECTED]: Module jakarta-velocity success To whom it may satisfy... 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 jakarta-velocity *no longer* has an issue. The current state of this module is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-velocity/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/jakarta-velocity/gump_work/update_jakarta-velocity.html Work Name: update_jakarta-velocity (Type: Update) Work ended in a state of : Failed Elapsed: Command Line: svn --quiet update --non-interactive jakarta-velocity [Working Directory: /usr/local/gump/public/workspace/cvs] - svn: 'jakarta-velocity' is not a working copy - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-velocity/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-velocity/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18000930112004, brutus:brutus-public:18000930112004 Gump E-mail Identifier (unique within run) #1. *** G U M P [EMAIL PROTECTED]: Project werken.xpath (in module jakarta-velocity) success To whom it may satisfy... 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 werken.xpath *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-velocity/werken.xpath/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [werken.xpath.jar] identifier set to project name -INFO- No license on redistributable project with outputs. To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-velocity/werken.xpath/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-velocity/werken.xpath/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18000930112004, brutus:brutus-public:18000930112004 Gump E-mail Identifier (unique within run) #2. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
does this mean that you worked around log4j? On Nov 30, 2004, at 1:10 PM, [EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 2 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Module jakarta-velocity success [EMAIL PROTECTED]: Project werken.xpath (in module jakarta-velocity) success *** G U M P [EMAIL PROTECTED]: Module jakarta-velocity success To whom it may satisfy... 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 jakarta-velocity *no longer* has an issue. The current state of this module is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-velocity/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/jakarta-velocity/gump_work/ update_jakarta-velocity.html Work Name: update_jakarta-velocity (Type: Update) Work ended in a state of : Failed Elapsed: Command Line: svn --quiet update --non-interactive jakarta-velocity [Working Directory: /usr/local/gump/public/workspace/cvs] - svn: 'jakarta-velocity' is not a working copy - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-velocity/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-velocity/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18000930112004, brutus:brutus-public:18000930112004 Gump E-mail Identifier (unique within run) #1. *** G U M P [EMAIL PROTECTED]: Project werken.xpath (in module jakarta-velocity) success To whom it may satisfy... 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 werken.xpath *no longer* has an issue. The current state of this project is 'Success'. Full details are available at: http://brutus.apache.org/gump/public/jakarta-velocity/werken.xpath/ index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [werken.xpath.jar] identifier set to project name -INFO- No license on redistributable project with outputs. To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-velocity/werken.xpath/ rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-velocity/werken.xpath/ atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 18000930112004, brutus:brutus-public:18000930112004 Gump E-mail Identifier (unique within run) #2. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
On Tue, 30 Nov 2004 11:39:07 -0800, Stefano Mazzocchi [EMAIL PROTECTED] wrote: I think gump's nagging is currently making more noise than signal and this is hurting our ability to come across as helpful instead of annoying. I propose to turn off nagging until we fix this, we are the only one making changes to the metadata anyway, so there is no much point in that. WDYT? Would the nags then go to the Gump list instead? +1 if so. -0 otherwise... -- Stefano. - 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: [vote] turning off nagging until we feel gump is solid enough for that
+1. Our probes are getting more done than nagging right now. On Nov 30, 2004, at 11:39 AM, Stefano Mazzocchi wrote: I think gump's nagging is currently making more noise than signal and this is hurting our ability to come across as helpful instead of annoying. I propose to turn off nagging until we fix this, we are the only one making changes to the metadata anyway, so there is no much point in that. WDYT? -- Stefano. - 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: [vote] turning off nagging until we feel gump is solid enough for that
I think that it's more complex then just turning it on or off.. I'm in favor of turning it off for now if thats the only option. What I prefer is that if a prereq doesn't build/builds finally, I don't get nagged. That is what generates (typically) the flood of emails... I only care if my project doesn't build/builds... Eric -Original Message- From: Scott Sanders [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 8:43 PM To: Gump code and data Subject: Re: [vote] turning off nagging until we feel gump is solid enough for that +1. Our probes are getting more done than nagging right now. On Nov 30, 2004, at 11:39 AM, Stefano Mazzocchi wrote: I think gump's nagging is currently making more noise than signal and this is hurting our ability to come across as helpful instead of annoying. I propose to turn off nagging until we fix this, we are the only one making changes to the metadata anyway, so there is no much point in that. WDYT? -- Stefano. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
kaffe build from cvs on brutus
Team, Good News!!! got ant's bootstrap.sh to work on brutus using a locally built kafee. stefano, dalibor and me worked on building kaffe from its CVS HEAD on brutus, the code is in /home/dims/kaffe and the results are at /usr/local/gump-kaffe and i have switched the /usr/local/gump/kaffe/gump/cron/local-env-brutus.sh to point to this kaffe instance. Sequence of steps: Step #1: Run apt-get build-dep kaffe to get all the dependencies Step #2: Get the CVS HEAD of Kaffe as follows: cd /home/dims export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/kaffe cvs login Enter the password readonly cvs checkout kaffe Step #3: Build and Install Kaffe as follows: cd kaffe ./configure --with-jikes --prefix=/usr/local/gump-kaffe make make install Note that step #1 needed root privs and stefano did the honors. Thanks a ton to dalibor for patiently walking through the steps. Let's cross our fingers and wait for the run at 18:00 PST today. thanks, dims -- Davanum Srinivas - http://webservices.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: kaffe build from cvs on brutus
OK, we got past the ant bootstrap problem. xerces is the new stumbling block (http://brutus.apache.org/gump/kaffe/xml-xerces2/xml-xerces/gump_work/build_xml-xerces2_xml-xerces.html) Since there is no tools.jar and hence no com.sun.tools.javac.Main. Am adding the following line: sysproperty name=build.compiler value=jikes/ to /home/gump/workspaces2/kaffe/gump/work/merge.xml Let's see how far we get with that tomorrow. Thanks, dims On Tue, 30 Nov 2004 19:10:37 -0500, Davanum Srinivas [EMAIL PROTECTED] wrote: Team, Good News!!! got ant's bootstrap.sh to work on brutus using a locally built kafee. stefano, dalibor and me worked on building kaffe from its CVS HEAD on brutus, the code is in /home/dims/kaffe and the results are at /usr/local/gump-kaffe and i have switched the /usr/local/gump/kaffe/gump/cron/local-env-brutus.sh to point to this kaffe instance. Sequence of steps: Step #1: Run apt-get build-dep kaffe to get all the dependencies Step #2: Get the CVS HEAD of Kaffe as follows: cd /home/dims export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/kaffe cvs login Enter the password readonly cvs checkout kaffe Step #3: Build and Install Kaffe as follows: cd kaffe ./configure --with-jikes --prefix=/usr/local/gump-kaffe make make install Note that step #1 needed root privs and stefano did the honors. Thanks a ton to dalibor for patiently walking through the steps. Let's cross our fingers and wait for the run at 18:00 PST today. thanks, dims -- Davanum Srinivas - http://webservices.apache.org/~dims/ -- Davanum Srinivas - http://webservices.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem running Apache Gump [brutus-public]
There is a problem with run 'brutus-public' (30112004_210001), location :
http://brutus.apache.org/gump/public
The log ought be at:
http://brutus.apache.org/gump/public/gump_log.txt
The last (up to) 50 lines of the log are :
File /home/gump/workspaces2/public/gump/python/gump/core/model/project.py,
line 535, in complete
depProject.complete(workspace)
File /home/gump/workspaces2/public/gump/python/gump/core/model/project.py,
line 535, in complete
depProject.complete(workspace)
File /home/gump/workspaces2/public/gump/python/gump/core/model/project.py,
line 535, in complete
depProject.complete(workspace)
File /home/gump/workspaces2/public/gump/python/gump/core/model/project.py,
line 535, in complete
depProject.complete(workspace)
File /home/gump/workspaces2/public/gump/python/gump/core/model/project.py,
line 535, in complete
depProject.complete(workspace)
File /home/gump/workspaces2/public/gump/python/gump/core/model/project.py,
line 535, in complete
depProject.complete(workspace)
File /home/gump/workspaces2/public/gump/python/gump/core/model/project.py,
line 535, in complete
depProject.complete(workspace)
File /home/gump/workspaces2/public/gump/python/gump/core/model/project.py,
line 535, in complete
depProject.complete(workspace)
File /home/gump/workspaces2/public/gump/python/gump/core/model/project.py,
line 535, in complete
depProject.complete(workspace)
File /home/gump/workspaces2/public/gump/python/gump/core/model/project.py,
line 535, in complete
depProject.complete(workspace)
File /home/gump/workspaces2/public/gump/python/gump/core/model/project.py,
line 526, in complete
if self.maven: self.maven.expand(self,workspace)
File /home/gump/workspaces2/public/gump/python/gump/core/model/builder.py,
line 63, in expand
self.expandDomProperties(project,workspace)
File /home/gump/workspaces2/public/gump/python/gump/core/model/builder.py,
line 118, in expandDomProperties
self.importProperty(pdom)
File /home/gump/workspaces2/public/gump/python/gump/core/model/property.py,
line 249, in importProperty
self.properties.importProperty(domproperty)
File /home/gump/workspaces2/public/gump/python/gump/core/model/property.py,
line 206, in importProperty
property=Property(name,pdom,self.getOwner())
File /home/gump/workspaces2/public/gump/python/gump/core/model/property.py,
line 29, in __init__
NamedModelObject.__init__(self,name,dom,parent)
File /home/gump/workspaces2/public/gump/python/gump/core/model/object.py,
line 285, in __init__
ModelObject.__init__(self,dom,owner)
File /home/gump/workspaces2/public/gump/python/gump/core/model/object.py,
line 44, in __init__
Workable.__init__(self)
File /home/gump/workspaces2/public/gump/python/gump/util/work.py, line 264,
in __init__
self.worklist=WorkList(self)
File /home/gump/workspaces2/public/gump/python/gump/util/work.py, line 177,
in __init__
self.times=TimeStampSet('Named Work')
File /home/gump/workspaces2/public/gump/python/gump/util/timing.py, line
336, in __init__
if not start:start=TimeStamp('Start of ' + name)
File /home/gump/workspaces2/public/gump/python/gump/util/timing.py, line
236, in __init__
stamp=getLocalNow()
File /home/gump/workspaces2/public/gump/python/gump/util/timing.py, line
95, in getLocalNow
return datetime.datetime.now(LOCAL_TIMEZONE_INFO)
File /home/gump/workspaces2/public/gump/python/gump/util/timing.py, line
69, in utcoffset
if self._isdst(dt):
RuntimeError: maximum recursion depth exceeded
Process Exit Code : 1
--
Gump Version: 2.0.2-alpha-0003
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Apollo and Muse (was Re: Problem running Apache Gump [brutus-public])
This is what good old Java/XSLT Gump says (yes, I still run it - Python 2.3 for Redhat 7.x anybody?): Dropping module apollo because of Exception java.lang.Exception: repository not found processing module apollo Dropping module muse because of Exception java.lang.Exception: repository not found processing module muse Dropping project apollo because of Exception java.lang.Exception: module apollo not found processing project apollo Dropping project muse because of Exception java.lang.Exception: module muse not found processing project muse Since I don't have commit access to either descriptor I'll remove them from the profile. Is there any reason to again use descriptors hosted outside of our control instead of adding them to the gump metadata directory? The incubator committers certainly can commit to it here as well. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: kaffe build from cvs on brutus
On Tue, 30 Nov 2004, Davanum Srinivas [EMAIL PROTECTED] wrote: Since there is no tools.jar and hence no com.sun.tools.javac.Main. Am adding the following line: sysproperty name=build.compiler value=jikes/ to /home/gump/workspaces2/kaffe/gump/work/merge.xml I thought I already did that, hmm. Doesn't need to be a sysproperty, at least not for Ant. Yes, this is the correct solution, let's see whether it works for Maven builds as well. Cheers Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] turning off nagging until we feel gump is solid enough for that
On Tue, 30 Nov 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: I think gump's nagging is currently making more noise than signal and this is hurting our ability to come across as helpful instead of annoying. Maybe. I agree with Eric that the you no longer have a problem mails are a particularly annoying. I propose to turn off nagging until we fix this, which means we first need to agree what a fixed version would be 8-) I agree if we still send nags to [EMAIL PROTECTED] or [EMAIL PROTECTED] And we could remove the success nags completely, at least for me. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
