DO NOT REPLY [Bug 22567] New: - Enhance includes and excludes attributes for StarTeam Tasks to support by folder
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22567. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22567 Enhance includes and excludes attributes for StarTeam Tasks to support by folder Summary: Enhance includes and excludes attributes for StarTeam Tasks to support by folder Product: Ant Version: 1.5.4 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Enhancement Priority: Other Component: Optional Tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Currently, the includes and excludes attributes for StarTeam Tasks function differently than other tasks in Ant. Inclusion/exclusion by folder is NOT supported. This enhancement request is to ask that inclusion/exclusion by folder is become supported for StarTeam tasks, especially STCheckout. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22543] - Available shows a deprecated message when changing a property
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22543. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22543 Available shows a deprecated message when changing a property --- Additional Comments From [EMAIL PROTECTED] 2003-08-19 14:13 --- That's just it though! Properties are *not* variables!!! Properties are immutable, and there was a bug in available, that's being left on purpose for backward compatibility. conditions and everything else in Ant is correct in *not* overriding existing properties. Just change your mindset to think with immutable properties. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22544] - ConditionTask doesn't allow to change an existing property
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22544. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22544 ConditionTask doesn't allow to change an existing property --- Additional Comments From [EMAIL PROTECTED] 2003-08-19 14:14 --- Need I say more? ;-) Properties *are* immutable, and thus cannot be treated as variables!!! --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javac-task and mapper
On Mon, 18 Aug 2003, Dominique Devienne [EMAIL PROTECTED] wrote: All you need to do is: javac destdir=build src path=src/team1 / src path=src/team2 / /javac No need for a mapper. Works like a charm ;-) --DD This is true - as long as you know the names and the number of the teams. My wish is to create a single build.xml-file that is usable for all projects - no matter which teams are envolved. Ulf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22560] New: - Touch doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22560. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22560 Touch doesn't work Summary: Touch doesn't work Product: Ant Version: 1.5.4 Platform: PC OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Touch doesn't work for me. It doesn't apply the timestamp specified as datetime argument. The argument is ignored and the file has 1 Jan 1970 time, as if time in millis was 0. I am running ant 1.5.4 on Debian unstable. See forthcoming attachments for test cases. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22569] New: - PL/SQL Extensions to SQL task to be included in standard release
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22569. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22569 PL/SQL Extensions to SQL task to be included in standard release Summary: PL/SQL Extensions to SQL task to be included in standard release Product: Ant Version: 1.1 Platform: Other OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Johan Adelow has done some custom mods to the SQL task to allow it to cope with Oracle PL/SQL and SQL*Plus scripts. It all seems to work seemlessly and has been around for quite a while. Is there any chance of getting the mods included in the standard release? (Or has this already been done?) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22560] - Touch doesn't work on Debian unstable Java1.4.2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22560. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22560 Touch doesn't work on Debian unstable Java1.4.2 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Touch doesn't work |Touch doesn't work on Debian ||unstable Java1.4.2 --- Additional Comments From [EMAIL PROTECTED] 2003-08-19 23:53 --- Works for me on rh9/Java1.4.2 too, though I had to remove the full path from the touch command. What might be useful would be extra logging info on touch, so we could find out what the second value it was planning to set. It may be something subtle like a string parsing/i18n defect. What locale are you running? Norway? -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22521] - java.endorsed.dirs sysproperty not passed to in-process java task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22521. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22521 java.endorsed.dirs sysproperty not passed to in-process java task --- Additional Comments From [EMAIL PROTECTED] 2003-08-19 23:55 --- On this subject, we may want to have ant.bat/sh to make ANT_HOME/lib endorsed, as I seem to be running against crimson on Java1.4.2+linux, against my implicit 'here is a copy of xerces' wishes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22560] - Touch doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22560.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22560
Touch doesn't work
--- Additional Comments From [EMAIL PROTECTED] 2003-08-19 21:01 ---
I have other JDKs installed, but 1.4.2 is first on the PATH.
Second JAVA_HOME is set to 1.4.2 and if I had
echo message=Run under ${java.version} /
to the build, it prints 1.4.2.
Should I investigate more possible JDK conflict?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22570] New: - A little tutorial How to write Tasks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22570. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22570 A little tutorial How to write Tasks Summary: A little tutorial How to write Tasks Product: Ant Version: 1.6Alpha (nightly) Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A step by step tutorial for writing and testing tasks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22570] - A little tutorial How to write Tasks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22570. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22570 A little tutorial How to write Tasks --- Additional Comments From [EMAIL PROTECTED] 2003-08-20 05:50 --- Created an attachment (id=7894) ZIP: tutorial, example sources, buildfiles, needed library, junitreport - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22572] New: - fileset/ tag is not listed in the ant tasks.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22572. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22572 fileset/ tag is not listed in the ant tasks. Summary: fileset/ tag is not listed in the ant tasks. Product: Ant Version: 1.5.3 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] fileset/ XML tag is not listed in the left side pane of the ANT tasks. we need to take a round about to see the documentation of fileset/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22572] - fileset/ tag is not listed in the ant tasks.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22572. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22572 fileset/ tag is not listed in the ant tasks. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1484] - Request additional flexibility in AntOn task for Ant2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1484. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1484 Request additional flexibility in AntOn task for Ant2 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-08-20 09:40 --- Eli Handel 2003-03-10 23:10 wrote that it seems to be enough to him, the rest of the discussion does not add any new insights. Steve wrote probably never, so I hope noone gets angry with me if I resolve the bug to WORKSFORME (as the requested enhancement already works be it via ant-contrib foreach) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20103] - FileSet horrible performance when dir has huge number of subdirs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20103. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20103 FileSet horrible performance when dir has huge number of subdirs --- Additional Comments From [EMAIL PROTECTED] 2003-08-20 11:05 --- Created an attachment (id=7897) patch for FTP.java and FTPTest.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22582] New: - noSuchMethodError
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22582. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22582 noSuchMethodError Summary: noSuchMethodError Product: Ant Version: 1.5.2 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Build Process AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22583] New: - noSuchMethodError
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22583. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22583 noSuchMethodError Summary: noSuchMethodError Product: Ant Version: 1.5.2 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20103] - FileSet horrible performance when dir has huge number of subdirs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20103. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20103 FileSet horrible performance when dir has huge number of subdirs --- Additional Comments From [EMAIL PROTECTED] 2003-08-20 11:24 --- I have prepared a fix (attached) for the FTP task or more precisely for the FTPDirectoryScanner. This fix passes the current FTP test suite. Concerning speed, the patch brings an improvement when include patterns point to specific files or directories and that the remote system is case sensitive. I will send more details on the development list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22583] - noSuchMethodError
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22583. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22583 noSuchMethodError [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bug #20103 - performance of FTPDirectoryScanner
I am attaching an improved patch on http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20103. This patch speeds up FTP scanning against case sensitive file systems (when followsymlinks = true) when the include patterns are of the type some/very/long/path. The code autodetects whether the remote system is case sensitive. The way it is done is that if the system encounters a subdirectory called alpha and there is no subdirectory called ALPHA in the same path, it will attempt to cd to ALPHA. If this fails, the code will draw the conclusion that the remote system is case sensitive. If the user did not set followsymlinks=false, then there is no reason to scan each path component of some/very/long/path to check the spelling. Trying to go directly to some/very/long/path will tell immediately if this path exists or not. I will commit my patch in the next days if there are no comments. Here are some results : 1 scan src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java 2 scan src/main/**/*.java (figures in milliseconds to run a scan) system Windows - hummingbird FTP server 1-old2063 1-new 2163 2-old29573 2-new 29523 UNIX (cvs.apache.org) 1-old 197 1-new 48 2-old 1590 2-new 1443 Cheers, Antoine
RE: [new tasks] presetdef and macrodef
Dominique,
As its name indicates macrodef/ is a MACRO. And macros are macros are
macros
and they are suppose to be textually replaces at the point on
invocation.
So the fact that properties are substituted at the expansion point is
what anyone understanding that it is a MACRO would expect.
My point with allowing for a way to expand inline, (which I am not even
sure
gives any advantage, since properties are inmutable) is trying to
address
the fact that in many MACRO languages there is some way to evaluate some
things
at definition time and fix the value then. some sort of eval.
Maybe one can acomplish this with some sort of property interceptor: So
a syntax like:
${macroinline:x} will cause the property x to be substituted
at definition time
while ${x} will get substituted at expansion time.
-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: 19 August 2003 21:24
To: 'Ant Developers List'
Subject: RE: [new tasks] presetdef and macrodef
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 19, 2003 12:47 PM
To: Ant Developers List
Subject: RE: [new tasks] presetdef and macrodef
What I am saying is that even with a different notation for
attributes, normal property resolution will take place in the
context of the user of the macro, and not when the macro
is defined.
This is a consequence of the way macrodef/ is implemented, in
particualar to support embedded elements.
Now that you explained this, I would really like to have a way of
defining properties that are expanded at definition time. I do not
know if it can be done with the syntax we already have or we need
something diferent. Probably we do, since we would need a way to
distinguish between inlined (replace during definition) and not
inlined (replaced during evaluation) properties.
I stopped arguing this point, as I was the only one concerned
apparently, but since Jose Alberto brings it up again...
Having ${NAME} not evaluate to the value, if any, of the NAME
property, at the time the task it's used in (macrodef is
this case) is executed, is REALLY REALLY BAD in my sincere
opinion. Maybe foreach does it, but that doesn't make it
any better. Properties should *always* be evaluated at the
place where they are defined.
If I'm not mistaken, and ${NAME} is evaluated as the time the
defined Macro is used, rather than defined, then is becomes
some kind of implicit attribute of that Macro, and it's much
better to explicitly define it as an attribute.
OTOH, if it behaves 'normally', as in what Ant does today, it
is simply a way to customize the way the macro itself (its
implementation if you will).
It seems that so far, my point has either not been well
understood, or dismissed (which is troubling to me, given the
huge confusion that would result IMHO). --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Nested elements
I have a task called uni-d
target name=UniDTask
taskdef name=uni-d
classname=be.unid.generate.AntTask
classpath=${unid.dir}/uni-d.jar
classpathref=task.path
/
/target
and here i use it:
target name=task depends=UniDTask
uni-d
appdir=D:\Work\Uni-D\test\src\uni-d
definition=test1.xml
outputdir=../../build/src
spackage=be.unid.test.om
template=xejb
config
name=extra
attribute name=datasource value=java:/ICtraceDS/
attribute jndi=IC-trace/
/config
/uni-d
This task add's the values for attributes:
appdir; definition; outputdir; spackage; template in the
config section of a ini file. The problem is that i have to create another
section in the ini file named extra and add the values for the parameters
datasource and jndi in the extra section of ini file. For this purpose i
must use the sintax in as you can se above:
config
name=extra
attribute name=datasource value=java:/ICtraceDS/
attribute jndi=IC-trace/
/config
How can i do that?
Andrei
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
Well, I must be stupid then... Unlike you, I don't consider macrodef a
MACRO at all. It has nothing to do with *textual* replacement. The
non-existent include, and XML entity includes *are* textual replacement.
macrodef certainly is NOT. macrodef is a TASK, which happens to define
and the same time it implement a(nother) new TASK, using Ant's native XML
syntax rather than Java code. It could as much be called taskimpl, and the
feeble link to MACRO would then be even more tenuous that it already is!
It turns out that when you write the implementation of that new task, you
*ARE* using Ant's syntax to 'code' it, and thus Ant normal behavior of
expanding properties *AS USUAL* should be respected.
It's a huge leap to say the least to consider macrodef defining a textual
MACRO. I myself am very aware of Ant's introspection and property expansion
rules, which is why I *expect* them to be applied everywhere in Ant.
So I repeat: I'm -1 to macrodef with non-standard expansion of Ant
properties. This is non-bidding of course, as I am not a committer... --DD
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2003 7:34 AM
To: Ant Developers List
Subject: RE: [new tasks] presetdef and macrodef
Dominique,
As its name indicates macrodef/ is a MACRO. And macros are macros are
macros
and they are suppose to be textually replaces at the point on
invocation.
So the fact that properties are substituted at the expansion point is
what anyone understanding that it is a MACRO would expect.
My point with allowing for a way to expand inline, (which I am not even
sure
gives any advantage, since properties are inmutable) is trying to
address
the fact that in many MACRO languages there is some way to evaluate some
things
at definition time and fix the value then. some sort of eval.
Maybe one can acomplish this with some sort of property interceptor: So
a syntax like:
${macroinline:x} will cause the property x to be substituted
at definition time
while ${x} will get substituted at expansion time.
-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: 19 August 2003 21:24
To: 'Ant Developers List'
Subject: RE: [new tasks] presetdef and macrodef
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 19, 2003 12:47 PM
To: Ant Developers List
Subject: RE: [new tasks] presetdef and macrodef
What I am saying is that even with a different notation for
attributes, normal property resolution will take place in the
context of the user of the macro, and not when the macro
is defined.
This is a consequence of the way macrodef/ is implemented, in
particualar to support embedded elements.
Now that you explained this, I would really like to have a way of
defining properties that are expanded at definition time. I do not
know if it can be done with the syntax we already have or we need
something diferent. Probably we do, since we would need a way to
distinguish between inlined (replace during definition) and not
inlined (replaced during evaluation) properties.
I stopped arguing this point, as I was the only one concerned
apparently, but since Jose Alberto brings it up again...
Having ${NAME} not evaluate to the value, if any, of the NAME
property, at the time the task it's used in (macrodef is
this case) is executed, is REALLY REALLY BAD in my sincere
opinion. Maybe foreach does it, but that doesn't make it
any better. Properties should *always* be evaluated at the
place where they are defined.
If I'm not mistaken, and ${NAME} is evaluated as the time the
defined Macro is used, rather than defined, then is becomes
some kind of implicit attribute of that Macro, and it's much
better to explicitly define it as an attribute.
OTOH, if it behaves 'normally', as in what Ant does today, it
is simply a way to customize the way the macro itself (its
implementation if you will).
It seems that so far, my point has either not been well
understood, or dismissed (which is troubling to me, given the
huge confusion that would result IMHO). --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: javac-task and mapper
Have you tried it? I haven't, but somehow I doubt it will work... That's just a guess though. --DD -Original Message- From: didge [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 7:14 PM To: Ant Developers List Subject: RE: javac-task and mapper How about this? path id=sources dirset dir=src include name=team*/ /dirset /path javac ... src refid=sources/ /javac didge -Original Message- From: Ulf Caspers [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: RE: javac-task and mapper On Mon, 18 Aug 2003, Dominique Devienne [EMAIL PROTECTED] wrote: All you need to do is: javac destdir=build src path=src/team1 / src path=src/team2 / /javac No need for a mapper. Works like a charm ;-) --DD This is true - as long as you know the names and the number of the teams. My wish is to create a single build.xml-file that is usable for all projects - no matter which teams are envolved. Ulf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
I stopped arguing this point, as I was the only one concerned apparently,
but since Jose Alberto brings it up again...
Having ${NAME} not evaluate to the value, if any, of the NAME property, at
the time the task it's used in (macrodef is this case) is executed, is
REALLY REALLY BAD in my sincere opinion. Maybe foreach does it, but that
I agree with you on this... I had to use foreach for the first time
recently and was astounded that it had been written that way. It
completely confuses the issue of property immutability, and makes the
parameter hard to find. You need to know what the argument is before you
look for it. Think about explaining property imutability to someone...
${foo.bar} can never change... exept when it isn't a property... how do
I know it isn't a property? they ask... The answer would be you just
have to know the tasks where ${foo.bar} might not be a property, and
check what the parameter name is. At that point the person you are
explaining this to rolls their eyes and says Ugh. That is annoying :)
I think macrodef should not duplicate this problem and if foreach ever
came into ant it should have a namechange and new parameter system.
-Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
Jose Alberto Fernandez wrote:
Dominique,
As its name indicates macrodef/ is a MACRO. And macros are macros are
macros
and they are suppose to be textually replaces at the point on
invocation.
Of course the parameters need to be replaced. The point is they
shouldn't look like properties. This way they can't be confused with
properties. An alternate form to ${foo} is all that is needed. Just
search for a diferent pattern... [EMAIL PROTECTED] or (@foo) or @{foo} or %{foo} or
$[foo] or really anything that isn't ${foo}. Dominique did also point
out that (@foo) and [EMAIL PROTECTED] are already commonly used in other contexts
that build authors will be familliar with.
-Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nested elements
You should ask help from the person who wrote the uni-d task.
The source code of uni-d task should have an addConfig method.
There should be a datatype config corresponding to what you have in the
config section.
The source code for config should have an addAttribute method
There should also be a datatype attribute.
You also need to do typedefs for attribute and config so that ant
understands these special datatypes.
Cheers,
Antoine
- Original Message -
From: Andrei [EMAIL PROTECTED]
To: Ant Developers List [EMAIL PROTECTED]
Sent: Wednesday, August 20, 2003 3:53 PM
Subject: Nested elements
I have a task called uni-d
target name=UniDTask
taskdef name=uni-d
classname=be.unid.generate.AntTask
classpath=${unid.dir}/uni-d.jar
classpathref=task.path
/
/target
and here i use it:
target name=task depends=UniDTask
uni-d
appdir=D:\Work\Uni-D\test\src\uni-d
definition=test1.xml
outputdir=../../build/src
spackage=be.unid.test.om
template=xejb
config
name=extra
attribute name=datasource value=java:/ICtraceDS/
attribute jndi=IC-trace/
/config
/uni-d
This task add's the values for attributes:
appdir; definition; outputdir; spackage; template in the
config section of a ini file. The problem is that i have to create
another
section in the ini file named extra and add the values for the parameters
datasource and jndi in the extra section of ini file. For this purpose i
must use the sintax in as you can se above:
config
name=extra
attribute name=datasource value=java:/ICtraceDS/
attribute jndi=IC-trace/
/config
How can i do that?
Andrei
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/xdocs faq.xml
antoine 2003/08/20 09:07:48 Modified:docs faq.html xdocsfaq.xml Log: Added information about how to configure Winzip to see better what is in a war file Submitted by: Neil Pitman (neil dot pitman at sympatico dot ca) Revision ChangesPath 1.77 +4 -0 ant/docs/faq.html Index: faq.html === RCS file: /home/cvs/ant/docs/faq.html,v retrieving revision 1.76 retrieving revision 1.77 diff -u -r1.76 -r1.77 --- faq.html 14 Aug 2003 16:16:20 - 1.76 +++ faq.html 20 Aug 2003 16:07:48 - 1.77 @@ -974,6 +974,10 @@ all lower-case for you./p pIf you extract (or just check) the archive with jar, you will see that the names have the correct case./p +pWith WinZIP (version 8.1 at least), this can be corrected in the +configuration. In the Options/Configuration menu, in the View tab, General +section, check the Allow all upper case files names box. The META-INF and +WEB-INF will look correct./p p class=faq a name=integration/a Is Ant supported by my IDE/Editor? 1.38 +5 -0 ant/xdocs/faq.xml Index: faq.xml === RCS file: /home/cvs/ant/xdocs/faq.xml,v retrieving revision 1.37 retrieving revision 1.38 diff -u -r1.37 -r1.38 --- faq.xml 14 Aug 2003 16:16:21 - 1.37 +++ faq.xml 20 Aug 2003 16:07:48 - 1.38 @@ -688,6 +688,11 @@ pIf you extract (or just check) the archive with jar, you will see that the names have the correct case./p + +pWith WinZIP (version 8.1 at least), this can be corrected in the +configuration. In the Options/Configuration menu, in the View tab, General +section, check the Allow all upper case files names box. The META-INF and +WEB-INF will look correct./p /answer /faq /faqsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javac-task and mapper
Have you tried it? I haven't, but somehow I doubt it will work... That's
just a guess though. --DD
It works, but I actually use a very different version in practice to achieve
something similar to Ulf's original wish: a way in which projects can
inherit common project behavior and yet still allow for optional extensions
or overrides.
First, some background: My projects generally have a single src subdirectory
where all .java files go. However, some projects use additional
subdirectories to contain the output of code generators. (I don't like to
mix source and generated code because it gets to annoying to figure out
which is which when they are colocated in the same directory.)
Therefore, I needed a way for a project to specify its source directories,
but I wanted to use a common set of targets for building. Let me tell you,
this was not easy to figure out. In much more than just a nutshell, this is
what I do:
Each project contains a build.xml minimally containing the target 'init'
which initializes a number of properties unique to the project: javadoc
name, jar name, version and a couple of other things. In addition, the
'init' target may also specify extensions to the default source and class
paths. By default, projects get default source and class paths of 'src' and
'build/classes:lib/*.jar:lib/*.zip'. For a project that wants to extend its
source path, to include 'gen' for example, then its 'init' target must
initialize a property containing the extended path.
This is achieved by constructing a path, called 'javac.sourcepath', composed
of the default source path (usually just 'src') and an extended source path,
if any.
This gets complicated, but essentially I have an XML fragment called
buildTargets.xml that defines my regular build targets and properties. This
fragment is included (via XML) into each project's build.xml that wants to
use it.
Here are the relevant portions of buildTargets.xml and a project's
build.xml, with an explanation following so you can get an idea how this
works:
buildTargets.xml:
target
name=buildTargets.setDefaultExtendedCompileSourcepath
unless=buildTargets.extended.javac.sourcepath
property name=buildTargets.extended.javac.sourcepath value=/
/target
target name=buildTargets.init
depends=init,
buildTargets.setDefaultExtendedCompileSourcepath
path id=javac.sourcepath
pathelement location=${builtTargets.javac.src.dir}/
pathelement path=${builtTargets.extended.javac.sourcepath}/
/path
/target
target name=compile depends=buildTargets.init
javac ...
src refid=buildTargets.javac.sourcepath/
/javac
/target
And here is an clip from one of my project build.xml files showing the
'init' and XML include:
!DOCTYPE project [
!ENTITY buildTargets SYSTEM file:../../ant/script/buildTargets.xml
]
target name=init
pathconvert
property=buildTargets.extended.javac.sourcepath
pathsep=${path.separator} dirsep=${file.separator}
path
pathelement location=gen/
/path
/pathconvert
/target
buildTargets;
How it works: Issuing the 'ant compile' command, results in the following
sequence of target being executed:
init
buildTargets.setDefaultExtendedCompileSourcepath
buildTargets.init
compile
As you can see, 'init' defines the extended sourcepath, and the next target
does nothing since the extended sourcepath was defined. 'buildTargets.init'
then merges the default sourcepath and the extended sourcepath into a single
property, ('javac.sourcepath') and 'compile' uses it. It is hopefully clear
then that if 'init' does not define an extension, then only the default
source path is used by 'compile'. (Note that it was necessary to ensure that
'buildTargets.extended.javac.sourcepath' is defined before
'buildTargets.init' is executed otherwise the path used to construct
'javac.sourcepath' can choke on an undefined property if the project does
not define an extended sourcepath.)
I've simplified things here a bunch to keep this as brief as possible and on
topic. However, there are a couple of other interesting features that my
scripts do as well:
1. Projects can override any target specified in buildTargets.xml, eg.
compile, clean, build, javadoc, etc. using indirect target references.
2. JDK specific classpaths and build tools are specifiable. This allows me
to easily build the same source against multiple JDK versions that may
require different sets of 3rd party libraries due to incompatibilities with
particular JDK versions.
I'd be happy to share more as people express interest.
didge
-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2003 6:57 AM
To: 'Ant Developers List'
Subject: RE: javac-task and mapper
-Original Message-
From: didge [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 19, 2003 7:14 PM
To: Ant Developers List
Subject: RE: javac-task and
