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=29251.
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=27541.
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=27541.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
bodewig 2004/06/02 05:09:46
Modified:.build.xml WHATSNEW
Log:
Xalan2Executor doesn't need Xalan-J 2
Revision ChangesPath
1.422 +1 -7 ant/build.xml
Index: build.xml
===
RCS file:
bodewig 2004/06/02 05:10:59
Modified:.Tag: ANT_16_BRANCH WHATSNEW build.xml
Log:
merge
Revision ChangesPath
No revision
No revision
1.503.2.94 +4 -0 ant/WHATSNEW
Index: WHATSNEW
bodewig 2004/06/02 05:31:18
Modified:docs faq.html
docs/manual/OptionalTasks junitreport.html
src/main/org/apache/tools/ant/taskdefs/optional/junit
XalanExecutor.java
xdocsfaq.xml
Log:
Document the
bodewig 2004/06/02 05:33:21
Modified:docs Tag: ANT_16_BRANCH faq.html
docs/manual/OptionalTasks Tag: ANT_16_BRANCH
junitreport.html
src/main/org/apache/tools/ant/taskdefs/optional/junit Tag:
ANT_16_BRANCH
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=29341.
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=29341.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
if you've followed the bugzilla mails or commits of today, you have
already seen that junitreport doesn't work nicely with JDK 1.5.[1]
The correct route seems to be to replace the stylesheets with
something that does not require Xalan's redirect extensions, but this
is way beyond my XSLT
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=27446.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I added a new target's attribute(named type) so you
cant specify the visibility.
In this case the target is private and you can´t run
it directly but you can call it from another target:
target name=telnetVIP type=private
...
/target
I added a new target's attribute(named type) so you
cant specify the visibility.
In this case the target is private and you can´t run
it directly but you can call it from another target:
target name=telnetVIP type=private
...
/target
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=29344.
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=27541.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Date: 2004-06-02T11:26:57
Editor: 32.102.170.75
Wiki: Ant Wiki
Page: AntOddities
URL: http://wiki.apache.org/ant/AntOddities
Useful macrodef which arose on discussion on user list
Change Log:
--
@@
I was just adding to the Ant Wiki AntOddities page the following macrodef :
!-- Allows you define a new property with a value of ${${a}.${b}} which
can't be done by the Property task alone. --
macrodef name=macro.compose-property
attribute name=name/
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=29347.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
I'd like to introduce the concept of a DispatchTask to Ant. This class may
be subclassed by tasks that perform multiple operations depending upon a
parameter. Currently, the task-writer would be using if...else if...else
constructs. Extending from this class would make it more elegant.
Apologies for reporting the bug to the list. Lost in thought, have now used
issues@
--
Jack J. Woehr # We have gone from the horse and buggy
Senior Consultant # to the moon rocket in one lifetime, but
Purematrix, Inc. # there has not been a corresponding moral
www.purematrix.com # growth
From: Magesh Umasankar [mailto:[EMAIL PROTECTED]
Hi,
I'd like to introduce the concept of a DispatchTask to Ant. This class
may
be subclassed by tasks that perform multiple operations depending upon a
parameter. Currently, the task-writer would be using if...else if...else
constructs.
From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
I wrote a quick counter-example which shows how expansions of properties
in Ant is not recursive:
?xml version=1.0 encoding=UTF-8?
project basedir=. default=all name=changeme
target name=all
property name=a
Subject:RE: DispatchTask
From: Dominique Devienne DDevienne () lgc ! com
Date: 2004-06-02 18:50:53
Hi Magesh. It's been a long time ;-)
:-)
What's the advantage of this other writing different tasks, possibly with
the usual Java code re-use? Especially if different modes
Dominique Devienne wrote:
I believe that ${${a}.${b}} is parsed as:
getProperty(${a) + . + getProperty(b) + }, thus the result. --DD
Well, it sure looks like it is :-)
But is that result reasonable? It looks more to me like an artifact of a coding
strategy
being elevated to a principle.
--
From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
Dominique Devienne wrote:
I believe that ${${a}.${b}} is parsed as:
getProperty(${a) + . + getProperty(b) + }, thus the result. --DD
Well, it sure looks like it is :-)
But is that result reasonable? It looks more to me like an
Dominique Devienne wrote:
From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
Dominique Devienne wrote:
I believe that ${${a}.${b}} is parsed as:
getProperty(${a) + . + getProperty(b) + }, thus the result. --DD
Well, it sure looks like it is :-)
But is that result reasonable?
From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
Second, what's one to do? Ant by contract does not support nested
properties, so what's Ant to do when it sees on opening ${?
Glad you ask.
Ant should behave analagously to m4: recursively expand until it
either hits ground or an
From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
Ant should behave analagously to m4: recursively expand until it
either hits ground or an uninstantiated ${decorated} name.
Oh, and the algorithm should be something like:
1. While argument X contains any ${} expressions {
Dominique Devienne wrote:
From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
Ant should behave analagously to m4: recursively expand until it
either hits ground or an uninstantiated ${decorated} name.
Oh, and the algorithm should be something like:
1. While argument X
From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
But you side stepped the BC issue.
?? Not sure I get you. BC issue?
Backward-compatibility issue. --DD
You can always implement (and test) the
algorithm above, and see if you can get the committers to put it in. --
DD
Sure, but save me
From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
Okay, Alexey wrote:
Just add something like if (project.getProperty(ant.bc)!=null)
...
to make them happier.
Was he speaking abstractly or is there an ant.bc property really?
Can't know for sure, but Alexey might have been
antoine 2004/06/02 13:32:11
Modified:.WHATSNEW CONTRIBUTORS
src/main/org/apache/tools/ant/taskdefs/optional
XMLValidateTask.java
src/testcases/org/apache/tools/ant/taskdefs/optional
Dominique Devienne wrote:
There's no such property, and any new 'magic' property will be a struggle to
get past IMHO. Committers would have to chime in at this point... --DD
It can be a command-line option or a property option. Looks like I can just
implement
In my opinion, the problem reported is a bug, even if for instance JDK
1.4 regexp has a similar bug.
I would go for fixing the bug without BC, in order not to make the code
too complicated.
This is just me though.
Cheers,
Antoine
Jack J. Woehr wrote:
Dominique Devienne wrote:
There's no such
antoine 2004/06/02 14:01:34
Modified:.CONTRIBUTORS
Log:
Accentuated characters had been converted to question marks, now fixed
Revision ChangesPath
1.18 +2 -2 ant/CONTRIBUTORS
Index: CONTRIBUTORS
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=23395.
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=29334.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
From: Antoine Lévy-Lambert [mailto:[EMAIL PROTECTED]
In my opinion, the problem reported is a bug, even if for instance JDK
1.4 regexp has a similar bug.
The JDK regex stuff is a tangent. It's just my own code to do Ant-like
property substitution (or Shell like, or DOS like, as it's
antoine 2004/06/02 14:13:18
Modified:.Tag: ANT_16_BRANCH WHATSNEW CONTRIBUTORS
src/main/org/apache/tools/ant/taskdefs/optional Tag:
ANT_16_BRANCH XMLValidateTask.java
src/testcases/org/apache/tools/ant/taskdefs/optional Tag:
antoine 2004/06/02 14:18:41
Modified:.WHATSNEW
docs/manual install.html
docs/manual/OptionalTasks ftp.html
Log:
Doc fix concerning the library requirements of the ftp task
PR: 29334
Submitted by: Steve Cohen (scohen at apache dot org)
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=29334.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Dominique Devienne wrote:
Cool. Then people wouldn't need ac:propertycopy and/or the macrodef
trick, or the propertyfile trick. Lets see what other committers think.
Should this lowly non-committer play with code or await some kind of consensus
on design?
--
Jack J. Woehr # We have gone
Dominique Devienne wrote:
Code has momentum. Design talk does not. Plat at will. --DD
Okay. I'm going to add one class ..ant.util.RecursivePropertyParser and call it
from ..ant.PropertyHelper.replacePropertiesRecursively()
and add some switch between that method and
Dominique Devienne wrote:
It does to me. Just throw in a test case too. --DD
Okay. Thanks.
--
Jack J. Woehr # We have gone from the horse and buggy
Senior Consultant # to the moon rocket in one lifetime, but
Purematrix, Inc. # there has not been a corresponding moral
www.purematrix.com
44 matches
Mail list logo
