DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33618.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
bodewig 2005/02/21 00:40:16
Modified:.WHATSNEW
src/main/org/apache/tools/ant/taskdefs Zip.java
Log:
On second thought, this seems to be the real fix for
PR: 33412
when updating an archive, we never want to drop files from the
original archive, no
bodewig 2005/02/21 00:44:33
Modified:.Tag: ANT_16_BRANCH WHATSNEW
src/main/org/apache/tools/ant/taskdefs Tag: ANT_16_BRANCH
Zip.java
Log:
merge
Revision ChangesPath
No revision
No
On Fri, 18 Feb 2005, Matt Benson [EMAIL PROTECTED] wrote:
Anyone from ant-contrib want to add a caveat to the
documentation of the for task?
I'd like to volunteer Peter for this ;-)
Being based on macrodefs, for is the only place I know of where this
comes into play: since the @ character
On Fri, 18 Feb 2005, Matt Benson [EMAIL PROTECTED] wrote:
OR it may be that we should detect these conditions as
NOT being absolute pathnames on DOS.
As with most Windows/DOS features I'm pretty much on the fence.
To me it sounds as if marking paths C:foo non-absolute and modify
resolveFile
On Fri, 18 Feb 2005, Matt Benson [EMAIL PROTECTED] wrote:
So we lie. :)
Please fix the docs 8-)
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32745.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32745.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32745.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33433.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33618.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Matt Benson wrote:
Anyone from ant-contrib want to add a caveat to the
documentation of the for task? Being based on
macrodefs, for is the only place I know of where this
comes into play:
Same applies to macros in macros!
since the @ character is escaped
with another (@@) in macrodefs/for,
Martijn Kruithof wrote:
Matt Benson wrote:
FileUtils.resolveFile claims to return absolute files;
however calling FileUtils.resolveFile(null, \\) on
DOS returns the non-absolute File \\. So we lie. :)
-Matt
No file on windows is allowed to have \ in the name, so \\ would not be a
valid file on
Hello,
On Wed, 9 Feb 2005 09:03:33 +0100, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Modified:
src/main/org/apache/tools/ant/taskdefs/optional Rpm.java
Log:
return code checking on rpm. How do we test this?
Using a mock object for rpm? Could return the value of a system parameter
Hi all,
I am about to propose a vote on the Antlib subproject proposal[1],
which hasn't received much attention. Given that our bylaws state it
needs a 2/3 majority of all active committers to get accepted, I'm
more than a bit worried that it is going to fail if only because we'll
miss the
Thomas Schapitz wrote:
Kev Jackson schrieb:
I don't think that this is the major problem. It's very very very
unlikely that anyone would want to tamper with Ant (why bother, a user
can always get teh source and build themselves?). The problem is that
when using Ant to build new code (and to
Hello,
I have proposed a patch for that issue (in fact detected with a @bug comment
in junit-frames.xsl).
Has anyone 10 minutes to review the patch and include it ? Thank you in
advance.
Regards,
--
Yves Martin
-
To
That sub project is ok with me - one step closer to modularization.
But IMO we should have a look at the AntLets [1], too.
Jan
[1] http://wiki.apache.org/ant/Proposals/Antlet
-Ursprüngliche Nachricht-
Von: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Gesendet am: Montag, 21. Februar
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32745.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
On Mon, 21 Feb 2005, Jan Materne [EMAIL PROTECTED] wrote:
But IMO we should have a look at the AntLets [1], too.
My main problem with this was and is, that it is not driven by the Ant
developer community.
Stefan
-
To
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32745.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32745.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
But IMO we should have a look at the AntLets [1], too.
My main problem with this was and is, that it is not driven by the Ant
developer community.
Stefan
Ok - no [EMAIL PROTECTED] support no future. But I think the idea behind that
is not
so bad. Maybe nobody knows that :-)
The original
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33670.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Stefan Bodewig wrote:
Hi all,
I am about to propose a vote on the Antlib subproject proposal[1],
which hasn't received much attention. Given that our bylaws state it
needs a 2/3 majority of all active committers to get accepted, I'm
more than a bit worried that it is going to fail if only because
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33670.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On 18 Feb 2005, [EMAIL PROTECTED] wrote:
I'm tempted to retrofit Task.bindToOwner back to the 1.6.x
codebase, for the benefit of third party tasks; same for the extra
constructors for exec and java.
Dominique Devienne wrote:
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On 18 Feb 2005, [EMAIL PROTECTED] wrote:
I'm tempted to retrofit Task.bindToOwner back to the 1.6.x
codebase, for the benefit of third party tasks; same for the extra
constructors for exec and
From: Steve Loughran [mailto:[EMAIL PROTECTED]
the reason I stuck in the task, is it lets a task add its own
bindToOwner implementation, to do extra binding. If you put it in the
parent, then the bound task doesnt get a look in.
Make sense?
Not really ;-) Do you have any example of such a
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33674.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Steve Loughran wrote:
Stefan Bodewig wrote:
Hi all,
I am about to propose a vote on the Antlib subproject proposal[1],
which hasn't received much attention. Given that our bylaws state it
needs a 2/3 majority of all active committers to get accepted, I'm
more than a bit worried that it is going
31 matches
Mail list logo
