AW: [PATCH] Next round of typo fixes

Patch submitted, and UnPackageNameMapper.java also fixed for line endings. Merci beaucoup. Cheers, Antoine -Ursprüngliche Nachricht- Von: Shatzer, Larry [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 16. September 2003 20:10 An: 'Ant Developers List' Betreff: RE: [PATCH] Next round of typo

cvs commit: ant/src/main/org/apache/tools/ant/util UnPackageNameMapper.java

antoine 2003/09/17 13:15:57 Modified:src/main/org/apache/tools/ant/util UnPackageNameMapper.java Log: Removed backslash r characters (problem mentioned by Larry Shatzer) Revision ChangesPath 1.3 +85 -85 ant/src/main/org/apache/tools/ant/util/UnPackageNameMapper.

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/depend AntAnalyzer.java ClassFileIterator.java Depend.java

antoine 2003/09/17 13:11:44 Modified:src/main/org/apache/tools/ant/taskdefs/condition FilesMatch.java src/main/org/apache/tools/ant/taskdefs/cvslib ChangeLogParser.java ChangeLogTask.java ChangeLogWrit

Re: Execute#getExitCode doesn't work as advertised

Hi, actually your new solution was my first approach which I left because of this documentation, regarding option 1 wouldn't this still need a patch to set killedProcess() to true (i know horrible way to say what I mean, but this should be clear) when destroy is called via the InterruptedExcepti

AW: Should cause an error when used inside a ?

Sounds good, Antoine -Ursprüngliche Nachricht- Von: peter reilly [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 17. September 2003 16:21 An: Ant Developers List Betreff: Re: Should cause an error when used inside a ? On Wednesday 17 September 2003 13:24, Stefan Bodewig wrote: > On Wed, 1

AW: Execute#getExitCode doesn't work as advertised

What you say makes sense Stefan, Antoine -Ursprungliche Nachricht- Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 17. September 2003 10:38 An: [EMAIL PROTECTED] Betreff: Execute#getExitCode doesn't work as advertised Martijn Kruithof raised this issue in his patch for

RE: [NOT PATCH] Possible new optional task for file modification

Unfortunately your attachment was stripped. -- Larry > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 16, 2003 5:42 AM > To: [EMAIL PROTECTED] > Subject: [NOT PATCH] Possible new optional task for file modification > > > (Sorry if thi

Re: [VOTE]: Getting 1.6 out the door

On Wednesday 17 September 2003 12:59, Stefan Bodewig wrote: > On Wed, 17 Sep 2003, peter reilly <[EMAIL PROTECTED]> wrote: > > The element gets rejected in > > UnknownElement#handleChildren() before > > Antlib#addConfigured() is called for the element > > of the antlib. > > I see. It seems we ha

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

peterreilly2003/09/17 10:06:44 Modified:src/main/org/apache/tools/ant/taskdefs Antlib.java Log: Restrict antlib tasks to be instanceof AntLibInterface Deal with types later Revision ChangesPath 1.11 +4 -0 ant/src/main/org/apache/tools/ant/taskdefs/Antlib.java

cvs commit: ant/src/etc/testcases/taskdefs antlib.xml antlib.current-test.xml

peterreilly2003/09/17 09:17:56 Modified:src/testcases/org/apache/tools/ant/taskdefs AntlibTest.java src/etc/testcases/taskdefs antlib.xml antlib.current-test.xml Log: Update antlib testcases to reflect restrictions in tasks allowd in an antlib

cvs commit: ant/docs/manual/CoreTypes antlib.html

peterreilly2003/09/17 08:47:55 Modified:docs/manual/CoreTypes antlib.html Log: remove sequential reference from antlib manual Revision ChangesPath 1.2 +4 -8 ant/docs/manual/CoreTypes/antlib.html Index: antlib.html

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

peterreilly2003/09/17 07:23:27 Modified:src/main/org/apache/tools/ant Target.java Log: add back removed description + checkstyle javadoc Revision ChangesPath 1.46 +2 -1 ant/src/main/org/apache/tools/ant/Target.java Index: Target.java ===

Re: Should cause an error when used inside a ?

On Wednesday 17 September 2003 13:24, Stefan Bodewig wrote: > On Wed, 17 Sep 2003, peter reilly <[EMAIL PROTECTED]> wrote: > > I think that the use-case is valid. > > Hmm, maybe - given the timing of Antoine's release plan - we should > limit to top-level right now and revisit nesteing import into

cvs commit: ant/src/main/org/apache/tools/ant/helper ProjectHelper2.java

peterreilly2003/09/17 07:13:54 Modified:src/main/org/apache/tools/ant Target.java src/main/org/apache/tools/ant/helper ProjectHelper2.java Log: change implementation of handling importing files top-level tasks to be less hachy Revision ChangesPath 1.45

Re: circular s

On Wednesday 17 September 2003 14:18, Stefan Bodewig wrote: > On Wed, 17 Sep 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote: > > Wait, you said that it prints out: > > > > "Skipped already imported file build.xml" > > > > This means that the current file is *not* imported twice... how do > > yo

Re: circular s

On Wed, 17 Sep 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote: > Wait, you said that it prints out: > > "Skipped already imported file build.xml" > > This means that the current file is *not* imported twice... how do > you gather that it executes the import once? ISTR Peter said it would be

Re: circular s

peter reilly wrote: On Wednesday 17 September 2003 14:00, Nicola Ken Barozzi wrote: Stefan Bodewig wrote: ... I'm not sure. Even if you think the current "flat" import rules are correct, (1) should be addressed IMHO. Wait, you said that it prints out: "Skipped already imported file build.xml" This

Re: circular s

On Wednesday 17 September 2003 14:00, Nicola Ken Barozzi wrote: > Stefan Bodewig wrote: > > On Wed, 17 Sep 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote: > >>Stefan Bodewig wrote: > >>>I feel this is wrong for two reasons: > >>>(1) The current build file (the one intially loaded) should be > >

Re: circular s

Stefan Bodewig wrote: On Wed, 17 Sep 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote: Stefan Bodewig wrote: I feel this is wrong for two reasons: (1) The current build file (the one intially loaded) should be added to the list of already imported files implicitly so it doesn't get loaded twice

Re: Should cause an error when used inside a ?

On Wed, 17 Sep 2003, peter reilly <[EMAIL PROTECTED]> wrote: > I think that the use-case is valid. Hmm, maybe - given the timing of Antoine's release plan - we should limit to top-level right now and revisit nesteing import into targets later? > One should also think about an inside a sequenti

Re: circular s

On Wed, 17 Sep 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote: > Stefan Bodewig wrote: >> I feel this is wrong for two reasons: >> (1) The current build file (the one intially loaded) should be >> added to the list of already imported files implicitly so it >> doesn't get loaded twice at all.

Re: Should cause an error when used inside a ?

On Wednesday 17 September 2003 13:06, Stefan Bodewig wrote: > On Wed, 17 Sep 2003, peter reilly <[EMAIL PROTECTED]> wrote: > > On Wednesday 17 September 2003 12:17, Stefan Bodewig wrote: > >> OK, if I nest into a target, something like > >> > >> > >> > >> > >> > >> and this would import a fil

Re: circular s

Stefan Bodewig wrote: Currently a build.xml with will print a warning "Skipped already imported file build.xml" and end as a successful build after executing the import once. Correct. I feel this is wrong for two reasons: (1) The current build file (the one intially loaded) should be added to

Re: Should cause an error when used inside a ?

On Wed, 17 Sep 2003, peter reilly <[EMAIL PROTECTED]> wrote: > On Wednesday 17 September 2003 12:17, Stefan Bodewig wrote: >> OK, if I nest into a target, something like >> >> >> >> >> >> and this would import a file that had only definitions - the >> definitions are platform specific - wil

Re: [VOTE]: Getting 1.6 out the door

On Wed, 17 Sep 2003, peter reilly <[EMAIL PROTECTED]> wrote: > I wrote an Antlib with: > > public void addConfigured(AntlibInterface nestedTask) { > System.out.println("Antlib: addConfigured"); > if (nestedTask instanceof Task) { > setLocation(((Task) nestedTask).g

Re: Should cause an error when used inside a ?

On Wednesday 17 September 2003 12:17, Stefan Bodewig wrote: > On Wed, 17 Sep 2003, peter reilly <[EMAIL PROTECTED]> wrote: > > The javadoc on the import task says that should only > > be used at the top-level. > > OK. > > > This statement is not in the manual. > > Let's fix it ;-) Yes... > > > The

Re: [VOTE]: Getting 1.6 out the door

On Wednesday 17 September 2003 12:22, Stefan Bodewig wrote: > On Wed, 17 Sep 2003, peter reilly <[EMAIL PROTECTED]> wrote: > > > > I have done some more investigation. The reason why using defined > > definitions do not work unless antlib is an taskcontainer is > > UnknownElement#handleChildren. T

cvs commit: ant/xdocs external.xml

bodewig 2003/09/17 04:29:20 Modified:docs external.html xdocsexternal.xml Log: typo Revision ChangesPath 1.135 +1 -1 ant/docs/external.html Index: external.html === RC

Re: [VOTE]: Getting 1.6 out the door

On Wed, 17 Sep 2003, peter reilly <[EMAIL PROTECTED]> wrote: [Stefan writes story about classes being loaded multiple times by the same classloader but via different paths] > Yikes! To be fair, I should add that the implementation doesn't work for class loaders that are not AntClassLoaders, so

Re: Should cause an error when used inside a ?

On Wed, 17 Sep 2003, peter reilly <[EMAIL PROTECTED]> wrote: > The javadoc on the import task says that should only > be used at the top-level. OK. > This statement is not in the manual. Let's fix it ;-) > The code does not check the precondition. Maybe it should? > so it could be said that

Re: Should cause an error when used inside a ?

On Wednesday 17 September 2003 11:02, Stefan Bodewig wrote: > or at least a warning? > > If you nest into a target, it won't be evaluated at parser > time (or will it?) and thus not work as expected - even if the > resulting build file was valid (i.e. the imported file doesn't contain > targets).

Re: [VOTE]: Getting 1.6 out the door

On Wednesday 17 September 2003 10:51, Stefan Bodewig wrote: > On Mon, 15 Sep 2003, peter reilly <[EMAIL PROTECTED]> wrote: > >> In particular, I'm not too fond of the completely undocumented > >> task. > > > > It would be nice to get this fixed. > > I rather opposed to the idea of adding stuff to

new Launcher and CLASSPATH

So far all our documentation more or less states that putting your jar containing custom tasks into ANT_HOME/lib or pointing to it in your CLASSPATH was equivalent. This is no longer true if the new launcher is used. As ant.jar cannot be found on the system classloader anymore, any class loaded f

RE: circular s

> Currently a build.xml with > > > > > > will print a warning "Skipped already imported file build.xml" and end > as a successful build after executing the import once. > > I feel this is wrong for two reasons: > > (1) The current build file (the one intially loaded) should be added > to t

Should cause an error when used inside a ?

or at least a warning? If you nest into a target, it won't be evaluated at parser time (or will it?) and thus not work as expected - even if the resulting build file was valid (i.e. the imported file doesn't contain targets). Stefan --

circular s

Currently a build.xml with will print a warning "Skipped already imported file build.xml" and end as a successful build after executing the import once. I feel this is wrong for two reasons: (1) The current build file (the one intially loaded) should be added to the list of already importe

Re: [VOTE]: Getting 1.6 out the door

On Mon, 15 Sep 2003, peter reilly <[EMAIL PROTECTED]> wrote: >> In particular, I'm not too fond of the completely undocumented >> task. > > It would be nice to get this fixed. I rather opposed to the idea of adding stuff to a class loader that has been used before - especially for the system cl

DO NOT REPLY [Bug 22446] - uses the "inputstring" only first time

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://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 22446] - uses the "inputstring" only first time

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://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 22446] - uses the "inputstring" only first time

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://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 23090] - AbstractFileSet copy-constructor makes shallow copy

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://nagoya.apache.org/bugzilla/show_bu

cvs commit: ant/src/main/org/apache/tools/ant/types AbstractFileSet.java PatternSet.java

bodewig 2003/09/17 02:20:38 Modified:src/main/org/apache/tools/ant/types AbstractFileSet.java PatternSet.java Log: Create a deep (well, deeper) clone in AbstractFileSet#clone PR: 23090 Make PatternSet Clonable. Revision ChangesPath 1.29

RE: cvs commit: ant/src/testcases/org/apache/tools/ant/types/sele ctors ModifiedSelectorTest.java

> bodewig 2003/09/17 01:50:22 > > Modified:src/testcases/org/apache/tools/ant/types/selectors > ModifiedSelectorTest.java > Log: > JDK 1.3- compatibility > > -java.io.FileWriter out = new > java.io.FileWriter(file, true); > +

cvs commit: ant/src/testcases/org/apache/tools/ant/types/selectors ModifiedSelectorTest.java

bodewig 2003/09/17 01:50:22 Modified:src/testcases/org/apache/tools/ant/types/selectors ModifiedSelectorTest.java Log: JDK 1.3- compatibility Revision ChangesPath 1.2 +3 -2 ant/src/testcases/org/apache/tools/ant/types/selectors/Modified

Execute#getExitCode doesn't work as advertised

Martijn Kruithof raised this issue in his patch for PR 23150. The javadocs say * @return the exit value, 1 if the process was killed, but in fact, it doesn't do anything special for a killed process. Rather than "fixing" this method, I'd like to remove the comment. For two reasons (1) Ex

DO NOT REPLY [Bug 23150] - [Patch] JUnitTask does not mark timed out tests as failed when forked

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://nagoya.apache.org/bugzilla/show_bu

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/junit JUnitTask.java

bodewig 2003/09/17 01:30:30 Modified:src/main/org/apache/tools/ant/taskdefs/optional/junit JUnitTask.java Log: A test that has timed out must be considered an error, PR 23150 Revision ChangesPath 1.82 +5 -3 ant/src/main/org/apache/tools/

DO NOT REPLY [Bug 23160] - [PATCH] JUnit, no summary for timeout testcases.

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://nagoya.apache.org/bugzilla/show_bu

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/junit JUnitTask.java

bodewig 2003/09/17 01:22:50 Modified:src/main/org/apache/tools/ant/taskdefs/optional/junit JUnitTask.java Log: Drop JDK 1.1 compatibility in favor of improved error handling, submitted by Martijn Kruithof Revision ChangesPath 1.81 +2 -2

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/junit JUnitTask.java

bodewig 2003/09/17 01:20:54 Modified:src/main/org/apache/tools/ant/taskdefs/optional/junit JUnitTask.java Log: Log tests that have timed out in the summary as well. PR: 23160 Submitted by: Martijn Kruithof Revision ChangesPath 1.80 +28

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

Conor MacNeill wrote: On Sat, 13 Sep 2003 12:04 am, [EMAIL PROTECTED] wrote: conor 2003/09/12 07:04:46 Modified:src/main/org/apache/tools/ant/taskdefs Ant.java Log: Mark entry and exit of and PR:22718 Submitted by: Jesse Glick This gives a message on entry and exit to a sub-b