[GUMP@brutus]: Project bootstrap-ant (in Module ant) 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 folk at [EMAIL PROTECTED] Project bootstrap-ant has an issue affecting its community integration. This issue affects 55

Re: cvs commit: ant build.xml

Seems this change made something not happy on the JDK1.4 that Gump runs (namely, that below). Does the bootstrap-ant script need to be aware of some conditional compilation? - ... Bootstrapping Ant Distribution ... Compiling Ant Classes src/main/org/apac

AW: [GUMP@brutus]: Project bootstrap-ant (in Module ant) failed

src/main/org/apache/tools/ant/taskdefs/condition/IsPingable.java:81: cannot resolve symbol symbol : method isReachable (int) location: class java.net.InetAddress return address.isReachable(timeout*1000); ^ New method since JDK 1.5, S

[GUMP@brutus]: Project bootstrap-ant (in Module ant) 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 folk at [EMAIL PROTECTED] Project bootstrap-ant has an issue affecting its community integration. This issue affects 55

yeah, I broke gump

Forgot about the bootstrap inclusion of condition/*.java will fix in a mo' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

yeah, I broke gump

Forgot about the bootstrap inclusion of condition/*.java will fix in a mo' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/condition - New directory

stevel 2004/10/08 01:52:15 ant/src/main/org/apache/tools/ant/taskdefs/optional/condition - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: yeah, I broke gump

On Fri, 08 Oct 2004, Steve Loughran <[EMAIL PROTECTED]> wrote: > Forgot about the bootstrap inclusion of condition/*.java Didn't we want to hand out "I broke Gump tonight" T-Shirts? Stefan - To unsubscribe, e-mail: [EMAIL PROTE

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/condition IsPingable.java

stevel 2004/10/08 01:59:19 Added: src/main/org/apache/tools/ant/taskdefs/optional/condition IsPingable.java Removed: src/main/org/apache/tools/ant/taskdefs/condition IsPingable.java Log: Move optional conditions to a suitable p

DO NOT REPLY [Bug 23942] - Addition of a local property

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

cvs commit: ant build.xml

stevel 2004/10/08 01:59:48 Modified:.build.xml Log: update selector to go with the move Revision ChangesPath 1.432 +1 -1 ant/build.xml Index: build.xml === RCS file: /home/cvs/ant/b

cvs commit: ant/src/main/org/apache/tools/ant/listener CommonsLoggingListener.java

stevel 2004/10/08 02:00:24 Modified:src/main/org/apache/tools/ant/listener CommonsLoggingListener.java Log: raise log level of targets to match that of task events Revision ChangesPath 1.12 +1 -1 ant/src/main/org/apache/tools/ant/listen

DO NOT REPLY [Bug 31598] New: - XmlLogger does not output to logfile

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Java.java

stevel 2004/10/08 02:34:41 Modified:src/main/org/apache/tools/ant/taskdefs Java.java Log: accessors to command line are occasionally useful when working with java Revision ChangesPath 1.95 +20 -0 ant/src/main/org/apache/tools/ant/taskdefs/Java.java Index: J

local properties

Hi, I have had a proposal outstanding for a while for local properties: http://issues.apache.org/bugzilla/show_bug.cgi?id=23942 I would like to see them included in ant. There has been a (lot) of discussions - see http://marc.theaimsgroup.com/?t=10876592661&r=1&w=2 http://marc.theaimsgroup.com/

AW: yeah, I broke gump

Somethink like the German "Schwarzer Peter" or "A***-Karte"? :) Jan > -Ursprüngliche Nachricht- > Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Gesendet am: Freitag, 8. Oktober 2004 10:58 > An: [EMAIL PROTECTED] > Betreff: Re: yeah, I broke gump > > On Fri, 08 Oct 2004, Steve Loughran

cvs commit: ant/src/testcases/org/example/junit XmlParserTest.java

stevel 2004/10/08 03:43:39 Added: src/testcases/org/example/junit XmlParserTest.java Log: Test that verifies XML parser version (Xerces) and feature set. Revision ChangesPath 1.1 ant/src/testcases/org/example/junit/XmlParserTest.java Index: XmlPar

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/compilers AptCompilerAdapter.java AptExternalCompilerAdapter.java

stevel 2004/10/08 03:46:36 Added: src/main/org/apache/tools/ant/taskdefs Apt.java src/main/org/apache/tools/ant/taskdefs/compilers AptCompilerAdapter.java AptExternalCompilerAdapter.java Log: Wrapper for Apt tool in Ja

DO NOT REPLY [Bug 23942] - Addition of a local property

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 31601] New: - asterisk propagation in wrapper script

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

RE: local properties

Peter, I just posted something on bug 23942 about a different approach to this issue that I implemented on my machine at home. It is a very small addition to macro and it does not require any changes to the ANT machinery. I think everything we want to be able to do in macros can be done this way.

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/rmic DefaultRmicAdapter.java ForkingSunRmic.java WLRmic.java

stevel 2004/10/08 04:09:46 Modified:docs/manual/OptionalTasks depend.html src/main/org/apache/tools/ant/taskdefs/optional/depend Depend.java src/main/org/apache/tools/ant/taskdefs/rmic DefaultRmicAdapter.java

DO NOT REPLY [Bug 31589] - Problems specific to OpenVMS

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

[GUMP@brutus]: Project bootstrap-ant (in Module ant) 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 folk at [EMAIL PROTECTED] Project bootstrap-ant *no longer* has an issue. Project State : 'Success', Reason '' Full d

dynamic declarations of conditions

So now we have (assuming gump works) a new condition in Ant that is only there when Java1.5 is present. Which means that we cannot hard code it into the condition task, but instead rely on dynamic typing and loading. Which is fine, except that we still need to declare the new condition on sta

Re: local properties

Jose Alberto Fernandez wrote: Peter, I just posted something on bug 23942 about a different approach to this issue that I implemented on my machine at home. It is a very small addition to macro and it does not require any changes to the ANT machinery. I think everything we want to be able to do in

AW: local properties

Sorry about not knowing the whole story :) But could that be possible/usefule? ${tmp.test} ${tmp.test} [test] hello <-- from macrodef [echo] ${tmp.test} <-- outside macrodef, prop is unset Jan > -Ursprüngliche Nachric

RE: local properties

> From: Peter Reilly [mailto:[EMAIL PROTECTED] > Jose Alberto Fernandez wrote: > > >I just posted something on bug 23942 about a different approach > >to this issue that I implemented on my machine at home. > > > >It is a very small addition to macro and it does not require > >any changes to the A

Re: local properties (what about PropertyHelper?)

QUESTIONS ON PropertyHelper (Ant 1.6+) ANT-dev mailing list: o Should PropertyHelper replacements honor currently attached hooks? What if a hook is attached and then the helper is unset (reset to the original Ant-installed one?) Should the (new) hooks be "moved" to the original helper? o Can

Conditional (Target) Execution

A while back there was a discussion about having a syntax for use in the if and unless attributes of targets. It has occurred to me that perhaps we just need a task akin to "sequential" that can have a condition data type as its first "child". This condition would determine whether the further c

Re: dynamic declarations of conditions

Steve Loughran wrote: So now we have (assuming gump works) a new condition in Ant that is only there when Java1.5 is present. Which means that we cannot hard code it into the condition task, but instead rely on dynamic typing and loading. Which is fine, except that we still need to declare the

DO NOT REPLY [Bug 23942] - Addition of a local property

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

RE: local properties

Let me get to your comments first :-) > From: Peter Reilly [mailto:[EMAIL PROTECTED] > > Yes I have seen it. > I do not like it, - the [EMAIL PROTECTED] syntax is a bit ikky ;-) > However, it does solve the macrodef use case so if people > go for it, I would have no objection.! > The synta

Re: Conditional (Target) Execution

There is an task in ant-contrib that does this: Prop is set Peter Phil Weighill-Smith wrote: A while back there was a discussion about having a syntax for use in the if and unless attributes of targets. It has occurred to me that perhaps we just need a task akin to "sequential" t

Re: local properties (what about PropertyHelper?)

I think that the current way of doing propery helpers and hooks is a bit wrong: 1) one can both replace the property helper (by setting a reference), and one can put hooks in. Both are difficult to use and have bugs. 2) I would like to have recursive property resolution (even if it causes

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs defaults.properties

stevel 2004/10/08 09:40:08 Modified:src/main/org/apache/tools/ant/taskdefs defaults.properties Log: apt tool Revision ChangesPath 1.158 +1 -0 ant/src/main/org/apache/tools/ant/taskdefs/defaults.properties Index: defaults.properties ==

RE: local properties

Ok, here are my responses: > From: Dominique Devienne [mailto:[EMAIL PROTECTED] > > > I haven't looked at your impl Peter, but there are two things > about Jose Alberto's proposal I wanted to note: > > 1) The generated unique name would need to at least use the >'let' name's as a prefix,

DO NOT REPLY [Bug 29978] - No way to run Apt processor for JDK 1.5

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

hotswap

On Thu, 07 Oct 2004 19:02:39 -0400, David Kavanagh <[EMAIL PROTECTED]> wrote: > I just noticed a 1.5+ feature that is going into Ant 1.7. Many months > ago, I had a 1.4+ feature that I wanted to get put into Ant, but it was > rejected because it wouldn't be backward compatible to version 1.2.2. >

RE: local properties

1) It's like polluting a tranditional program's variable space with stuff the application did not explicitly cause -- it makes debugging more difficult (and confusing if the results of the Ant execution is published in a readonly format like a website). 2) The previous state

Re: hotswap

When you say "scared", I hope the code didn't look that bad! (I mean, I thought you might be talking about the power it could unleash). No, we don't use it for production at all. Yes, we use it for development only. I like that I can edit in Vim and invoke an ant target to compile and hotswap my ch

Re: local properties

1. I like the implementation simplicity of Jose's solution. We chould check it in now and see how well it works in practice, with the warnign we can pull it right up to the moment Ant1.7.0 ships. 2. I also like the conceptual model of for anyone experienced in using local variables. It does in

Re: local properties

--- Steve Loughran <[EMAIL PROTECTED]> wrote: [SNIP] > Regarding nesting of property resolution, which is > also on that thread > ${${b}.c} this reminds me too much of pointers. If > we want something > like that, lets have a hashtable-like syntax > > ${myprops[${b}]} > I have nothing against r

RE: local properties

--- Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: [SNIP] > > From: Dominique Devienne [SNIP] > > 2) All these uniquely named properties go on > living after > >the macro has executed. That pollutes the > namespace. > > > > Yes it does. But I still have to see a good argument > on why shal

DO NOT REPLY [Bug 31589] - Problems specific to OpenVMS

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 31589] - Problems specific to OpenVMS

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

[PATCH] set filename of default buildfile

This patch allowes people to set the default filename that ant uses if none is given and sets ant.file.default to default file name value. M docs/manual/running.html M docs/manual/using.html M src/main/org/apache/tools/ant/Main.java M src/main/org/apache/tools/ant/taskdefs/Ant.java M src/main/org/

Re: local properties (and recursive expansion?)

Jose Alberto Fernandez wrote: > It is a very small addition to macro and it does not require > any changes to the ANT machinery. I think everything we want > to be able to do in macros can be done this way. While we're on the subject, anyone still thinking about recursive property expansion? --

RE: local properties (and recursive expansion?)

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Jose Alberto Fernandez wrote: > > > It is a very small addition to macro and it does not require > > any changes to the ANT machinery. I think everything we want > > to be able to do in macros can be done this way. > > While we're on the su

Re: local properties (and recursive expansion?)

I would rather put into a build file, because it is a property of a build file to use this feature. - Alexey. Dominique Devienne wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: It is a very small addition to macro and it does not require any changes to

Re: local properties (and recursive expansion?)

Dominique Devienne wrote: > > While we're on the subject, anyone still thinking about recursive > > property expansion? > > Yes, Peter just mentioned it. And I also support it, FWIW. > I'd prefer to have it built-in to core too, possibly with a > command line switch to explicitly enable it to be

RE: local properties (and recursive expansion?)

> From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED] > > I would rather put into a build file, because it is a property of a > build file to use this feature. Yes Alexey, I agree with you. I've long thought that it's really strange there are a lot of things you cannot easily do from within the

DO NOT REPLY [Bug 31589] - Problems specific to OpenVMS

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu