Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

Alexey Solofnenko wrote: We do not support 1.1 any more. Yes, but at that time we were. :) toURL does not properly escape illegal characters (see javadoc) so you end up kind of like my horrible current hack. I just checked jaxp implementation, the current implementation in the main branch (jax

Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

We do not support 1.1 any more. - Alexey. On 5/13/05, Stephane Bailliez <[EMAIL PROTECTED]> wrote: > > Alexey Solofnenko wrote: > > >Another, question - why not to use File.toURL() method instead? > > > > > JDK 1.2+ method. (yeah sounds like it was last century :) > > -- Alexey N. Solofnen

Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

Alexey Solofnenko wrote: Another, question - why not to use File.toURL() method instead? JDK 1.2+ method. (yeah sounds like it was last century :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMA

cvs commit: ant WHATSNEW

stevel 2005/05/13 15:12:29 Modified:.WHATSNEW Log: more changes, plus some corrections to existing reports. Revision ChangesPath 1.821 +15 -5 ant/WHATSNEW Index: WHATSNEW === RCS fil

Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

Another, question - why not to use File.toURL() method instead? - Alexey. On 5/13/05, Stephane Bailliez <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] wrote: > [...] > > - //XXX there seems to be a bug in xerces 1.3.0 that doesn't like file > object > - // will investigate later. It does not

Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

[EMAIL PROTECTED] wrote: [...] -//XXX there seems to be a bug in xerces 1.3.0 that doesn't like file object -// will investigate later. It does not use the given directory but -// the vm dir instead ? Works fine with crimson. -Do

DO NOT REPLY [Bug 34860] - Startupscript must not add empty $CLASSPATH to evaluated command

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 Main.java

stevel 2005/05/13 14:57:23 Modified:src/main/org/apache/tools/ant Main.java Log: added a special case that detects -cp and -lib calls in Main, and tells the caller that they have a probable version mismatch. Revision ChangesPath 1.118 +13 -21ant/src/main/org/apa

cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

stevel 2005/05/13 14:54:14 Modified:src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java Log: and of course the date change. Revision ChangesPath 1.9 +1 -1 ant/src/testcases/org/apache/tools/ant/taskdefs/opti

cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

stevel 2005/05/13 14:42:23 Modified:src/etc/testcases/taskdefs/optional junitreport.xml src/main/org/apache/tools/ant/taskdefs/optional/junit XMLResultAggregator.java src/testcases/org/apache/tools/ant/taskdefs/optional/junit

cvs commit: ant/xdocs resources.xml

stevel 2005/05/13 13:49:10 Modified:xdocsresources.xml Log: 1. new books 2. touched up old books 3. stripped out my old email address. I now know why that alias still get so much virus/spam mail. Revision ChangesPath 1.42 +68 -13ant/xdocs/resources.xml

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/compilers CompilerAdapter.java CompilerAdapterFactory.java Gcj.java Javac12.java Javac13.java JavacExternal.java Jikes.java Jvc.java Kjc.java Sj.

peterreilly2005/05/13 09:58:55 Modified:src/main/org/apache/tools/ant/taskdefs/compilers CompilerAdapter.java CompilerAdapterFactory.java Gcj.java Javac12.java Javac13.java JavacExternal.java Jikes.java Jvc.java Kjc.

Re: [Bug 28444] - Import: Target Handling Bug

Rather than having a specific element, could this not be achieved via a naming convention such as "-target-name" (the leading "-" actually makes the target uninvocable from the command line anyway and therefore pretty good and private from the CLI point-of-view)? Or even a new attribute on target

Re: [Bug 28444] - Import: Target Handling Bug

Jose Alberto Fernandez wrote: Just to put closure in my list of peeves about , I really think we need a way to define "private" targets. +1, one should be able to write an importable build file that has some exported targets - but internally uses targets that do not get overwritten accidently. P

DO NOT REPLY [Bug 34826] - ORA-00600 running SQLExec w/ keepformat="true"

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: Commercial products on the "related products" page?

I had hopes that we'd use the wiki for this sort of stuff in the future, allowing it to be self-serve. The downside is that it's not included in the current distributions, but we could probably do some sort of to pull wiki content into distributions as a snapshot. Erik On May 13, 2005,

RE: [Bug 28444] - Import: Target Handling Bug

Just to put closure in my list of peeves about , I really think we need a way to define "private" targets. Now, for this to work properly, you need: 1) A way to mark a target as private. 2) private targets must be ignored by targets of the same names on other points in the hierarchy. 3) Depends

DO NOT REPLY [Bug 34907] New: - Add Multipart subtype setting to MimeMailer

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: [Bug 28444] - Import: Target Handling Bug

Anyone consider: ... Nicola Ken Barozzi wrote: Jose Alberto Fernandez wrote: Going to the old discussions in how to approach this issues, the thing that bother me most, is that in order to get access to an imported target I need to know the name given to the project on the file that did the impor

Re: [Bug 28444] - Import: Target Handling Bug

Evan Easton wrote: ... Valid point. But isn't the depends list of an imported target something that you'd really like to not muck with in the interests of encapsulation? I agree that it would be really nice to be able to insert into or at the end of the overridden target's dependencies (a la as

Re: DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

Jose Alberto Fernandez wrote: From: Peter Reilly [mailto:[EMAIL PROTECTED] Matt Benson wrote: I can't imagine a scenario where BC would be compromised, but I'd be glad for an example. -Matt I was thinking of the example with multiple import files with the same projectname/targetname

Re: [Bug 28444] - Import: Target Handling Bug

Anyone consider: ... Nicola Ken Barozzi wrote: Jose Alberto Fernandez wrote: Going to the old discussions in how to approach this issues, the thing that bother me most, is that in order to get access to an imported target I need to know the name given to the project on the file that did the impor

Re: [Bug 28444] - Import: Target Handling Bug

Nicola Ken Barozzi wrote: Steve Loughran wrote: Phil Weighill-Smith wrote: I missed the beginning of this thread but just want to say that I personally think that import is the best feature in Ant today (apart from Ant's being in the first place, that is)! I find it hard to work with in a big pr

Re: [Bug 28444] - Import: Target Handling Bug

Stefan Bodewig wrote: On Fri, 13 May 2005, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: Well, alternatively you could overide "setup": Sure, we can certainly play fetch-me-a-rock here. I just need to come up with a more complex scenario and there will be no solution for it in which I

RE: DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

> From: Peter Reilly [mailto:[EMAIL PROTECTED] > > Matt Benson wrote: > > >I can't imagine a scenario where BC would be > >compromised, but I'd be glad for an example. > > > >-Matt > > > > > > > I was thinking of the example with multiple import files with > the same projectname/targetname. >

Re: Commercial products on the "related products" page?

Stefan Bodewig wrote: Hi, Slava Imeshev of Viewtier Systems sent me a private email asking whether it was OK to include links to commercial products on our "related projects" page. The original email - minus the actual patch and Slava's phone number - is reproduced below (with Slava's permission,

Re: DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

Matt Benson wrote: I can't imagine a scenario where BC would be compromised, but I'd be glad for an example. -Matt I was thinking of the example with multiple import files with the same projectname/targetname. example: a.xml a.xml b.xml b.xml c.xml c.xml build.xml In this case, ant 1.

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Peter Reilly <[EMAIL PROTECTED]> wrote: > Stefan Bodewig wrote: >>Do we really need to create a complete clone? Can't we achieve the >>same with a more lazy approach? >> >>Turning Matt's idea around: > > I do not see what that will buy us much in terms of efficeny. Frankly,

RE: [Bug 28444] - Import: Target Handling Bug

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > On Fri, 13 May 2005, Jose Alberto Fernandez > <[EMAIL PROTECTED]> wrote: > > > Well, alternatively you could overide "setup": > > Sure, we can certainly play fetch-me-a-rock here. I just > need to come up with a more complex scenario and t

Re: [Bug 28444] - Import: Target Handling Bug

Stefan Bodewig wrote: On Thu, 12 May 2005, Peter Reilly <[EMAIL PROTECTED]> wrote: The target gets renamed if there another target of the same name, but not otherwise - how can one write a proper reusable import file using the rename feature in this case? I'm strongly +1 for at least provid

AW: Commercial products on the "related products" page?

What - the most important snippet you had forgotten??? :-O Jan > -Ursprüngliche Nachricht- > Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Gesendet am: Freitag, 13. Mai 2005 14:20 > An: dev@ant.apache.org > Betreff: Re: Commercial products on the "related products" page? > > A snippe

Re: Commercial products on the "related products" page?

A snippet I forgot to forward 8-) > Using this chance I'd like to say you guys did really good job with > Ant - I think it is one of the best Java products out there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional co

AW: Commercial products on the "related products" page?

Should be ok. License information is for each entry present. Maybe we should split external&related into free/commercial sections ... if there are more entries. Jan > -Ursprüngliche Nachricht- > Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Gesendet am: Freitag, 13. Mai 2005 14:12 > An:

Commercial products on the "related products" page?

Hi, Slava Imeshev of Viewtier Systems sent me a private email asking whether it was OK to include links to commercial products on our "related projects" page. The original email - minus the actual patch and Slava's phone number - is reproduced below (with Slava's permission, of course). We alrea

DO NOT REPLY [Bug 30706] - Ftp task unable to get or list

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: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: > Well, alternatively you could overide "setup": Sure, we can certainly play fetch-me-a-rock here. I just need to come up with a more complex scenario and there will be no solution for it in which I didn't have to duplicate (

RE: [Bug 28444] - Import: Target Handling Bug

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > On Fri, 13 May 2005, Jose Alberto Fernandez > <[EMAIL PROTECTED]> wrote: > >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > >> Another related problem I have is that you can't add > >> something to the beginning of a target easily. You

Re: [Bug 28444] - Import: Target Handling Bug

Jose Alberto Fernandez wrote: Going to the old discussions in how to approach this issues, the thing that bother me most, is that in order to get access to an imported target I need to know the name given to the project on the file that did the import. This in my opinion contradicts the hidding rul

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] >> Another related problem I have is that you can't add >> something to the beginning of a target easily. You can add >> someting to the end of "foo" by writing your own "fo

RE: [Bug 28444] - Import: Target Handling Bug

> From: Phil Weighill Smith [mailto:[EMAIL PROTECTED] > > On Fri, 2005-05-13 at 11:38 +0100, Jose Alberto Fernandez wrote: > > I would advocate to allow the importer the specify the > aliasing name > > it wants to use for the imported things, so one has something like: > > > > foo.xml > > > >

RE: [Bug 28444] - Import: Target Handling Bug

On Fri, 2005-05-13 at 11:38 +0100, Jose Alberto Fernandez wrote: > I would advocate to allow the importer the specify the aliasing name > it > wants to use for the imported things, so one has something like: > > foo.xml > > ... > > > bar.xml > > > ... > +1 to the 'as=""'. Would we s

RE: [Bug 28444] - Import: Target Handling Bug

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: 13 May 2005 11:10 > To: dev@ant.apache.org > Subject: Re: [Bug 28444] - Import: Target Handling Bug > > > Another related problem I have is that you can't add > something to the beginning of a target easily. You can add > someting to th

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 2005-05-13 at 10:25 +0100, Steve Loughran wrote: > -when you override a target, you dont get access to its dependents. > Workaround: many pseudo-targets that only model dependencies. In fact we have "real" targets that don't have dependencies and it is these that we override. These are al

RE: [Bug 28444] - Import: Target Handling Bug

Going to the old discussions in how to approach this issues, the thing that bother me most, is that in order to get access to an imported target I need to know the name given to the project on the file that did the import. This in my opinion contradicts the hidding rules of OO programming. I shoul

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java

scohen 2005/05/13 03:34:40 Modified:src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java Log: improve clarity of what FTPConfigurator is doing. Revision ChangesPath 1.70 +3 -7 ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java Index:

Re: cvs commit: ant/docs/manual install.html

Stefan Bodewig wrote: On Thu, 12 May 2005, Steve Cohen <[EMAIL PROTECTED]> wrote: I don't know, though, guys. What do you think? Is it really worth it to avoid making the users upgrade? For me it depends on when you wanted to see the new task. If you wanted to include it in 1.6.4 (which is unli

cvs commit: ant/docs/manual install.html

scohen 2005/05/13 03:26:20 Modified:src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java docs/manual install.html Added: src/main/org/apache/tools/ant/taskdefs/optional/net FTPConfigurator.java Log: Add FTPConfigurator class so

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote: > Stefan Bodewig wrote: >> On Thu, 12 May 2005, Dominique Devienne <[EMAIL PROTECTED]> >> wrote: > ... >>>And targets from different imported build files that conflict >>>(multiple inheritance) should raise an error unless explicitl

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Phil Weighill Smith <[EMAIL PROTECTED]> wrote: > On Fri, 2005-05-13 at 09:00 +0200, Stefan Bodewig wrote: > >> > But say the importER explicitly depends on bar.foo . Isn't this >> > still going to pollute the log in the opposite way my >> > implementation would? :) i.e. >> >

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Steve Loughran <[EMAIL PROTECTED]> wrote: > Phil Weighill-Smith wrote: >> I missed the beginning of this thread but just want to say that I >> personally think that import is the best feature in Ant today >> (apart from Ant's being in the first place, that is)! > > I find it h

Re: [Bug 28444] - Import: Target Handling Bug

Steve Loughran wrote: Phil Weighill-Smith wrote: I missed the beginning of this thread but just want to say that I personally think that import is the best feature in Ant today (apart from Ant's being in the first place, that is)! I find it hard to work with in a big project. problems -risk of ad

Re: [Bug 28444] - Import: Target Handling Bug

Phil Weighill-Smith wrote: I missed the beginning of this thread but just want to say that I personally think that import is the best feature in Ant today (apart from Ant's being in the first place, that is)! I find it hard to work with in a big project. problems -risk of adding a new target in an

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 2005-05-13 at 09:00 +0200, Stefan Bodewig wrote: > > But say the importER explicitly depends on bar.foo . Isn't this > > still going to pollute the log in the opposite way my implementation > > would? :) i.e. > > > > [foo]: > > > > [bar.foo]: > > Yes. But this is less likely than havi

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

bodewig 2005/05/13 01:13:50 Modified:src/main/org/apache/tools/ant/taskdefs BUnzip2.java GUnzip.java Log: Use FileUtils.close() Revision ChangesPath 1.18 +5 -28 ant/src/main/org/apache/tools/ant/taskdefs/BUnzip2.java Index: BUnzip2.ja

DO NOT REPLY [Bug 34893] - unzip task input file remains open after exception

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/zip ZipFile.java

bodewig 2005/05/13 01:09:35 Modified:.Tag: ANT_16_BRANCH WHATSNEW src/main/org/apache/tools/ant/taskdefs Tag: ANT_16_BRANCH Untar.java src/main/org/apache/tools/zip Tag: ANT_16_BRANCH ZipFile.java Log

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

bodewig 2005/05/13 01:09:22 Modified:.WHATSNEW src/main/org/apache/tools/ant/taskdefs Untar.java src/main/org/apache/tools/zip ZipFile.java Log: and could leave streams open. PR 34893 Revision ChangesPath 1.820 +3 -0 ant/W

DO NOT REPLY [Bug 34893] - unzip task input file remains open after exception

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: cvs commit: ant/docs/manual install.html

On Thu, 12 May 2005, Steve Cohen <[EMAIL PROTECTED]> wrote: > I don't know, though, guys. What do you think? Is it really worth > it to avoid making the users upgrade? For me it depends on when you wanted to see the new task. If you wanted to include it in 1.6.4 (which is unlikely to happen an

DO NOT REPLY [Bug 34826] - ORA-00600 running SQLExec w/ keepformat="true"

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: [Bug 28444] - Import: Target Handling Bug

On Thu, 12 May 2005, Matt Benson <[EMAIL PROTECTED]> wrote: > You confused me with the "later." I wasn't sure how the target overriding was implemented so wanted to be save. > Our local targets are known before we actually execute a top-level > (target "") import, right? Probably. If you say s