Re: beating the dead Ant 1.6 horse
Conor MacNeill wrote: The others are antlib/namespace/polymorph stuff. I'm wondering if we can get to the point where the ant optional tasks are packaged as antlibs and potentially not added to the root loader if their supporting libraries are not also available to the root loader. This would allow them to be taskdef'd in later in a build. What's the status on that ? Any decision on how to deal with the loaders ? I'll have some time next week, I wanted to finish the classloader task - is it still usefull ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] namespace and antlib
peter reilly wrote: On Tuesday 12 August 2003 13:24, Stefan Bodewig wrote: On Tue, 12 Aug 2003, peter reilly [EMAIL PROTECTED] wrote: On Tuesday 12 August 2003 12:36, Stefan Bodewig wrote: On Fri, 1 Aug 2003, peter reilly [EMAIL PROTECTED] wrote: typedef resource=net/sf/antcontrib/antlib.xml uri=antlib:net.sf.antcontrib classpath=/tmp/ant-contrib.jar/ wouldn't the resource attribute be redundant in that case? Not in this case. The automatic lookup of uri=antlib:net.sf.antcontrib to net/sf/antcontrib/antlib.xml resource currently is done once when the ns prefix is encountered the first time - it does not take place at the typedef/ task. The obvious question would be: Why not? The code handles build scripts like: project xmlns:ac=antlib:net.sf.antcontrib (1) ac:shellscript shell=bash (2) echo helloworld /ac:shellscript typedef uri=antlib:net.sf.antcontrib (3) name=shellscript classpath=testing.classes classname=net.sf.antcontrib.pending.ShellScriptNew/ ac:shellscript shell=bash (4) echo helloword from test shellscript /ac:shellscript /project (1) will associate the ns prefix ac with the uri antlib:net.sf.antcontrib (2) ComponentHelper#createComponent will call #checknamespace for antlib:net.sf.antcontrib and maps it to the net/sf/antcontrib/antlib.xml resource. It then creates a typedef task, and sets the uri and resource to antlib:... and net/sf... and sets the onerror parameter to ignore, this will make available the antcontrib's definitions. ComponentHelper stores the fact that it has implicitly loaded in these definitions so that it does not do this again. 3) This will override the antcontribs' uris definition of shellscript. 4) This will execute the new definition. All this overriding may create some bad maintaince problems. I wish we wouldn't support this feature... Costin I have changed this to ant:*, Hmm, what will be the replacement for antlib:*? Users are allowed to use antlib:*. The restricted uri's are uris that users are not allowed to use in typedef/. as I found when testing that the current code reserves antcontrib: and antelope: Sure, I don't see a problem, though. This makes sense, but would involve some messing with classloaders and scanning of the jar files in ANT_HOME/antlibs. I know. Each time I look at classloaders, my head melts down You are not alone ;-) Seriously, once you've started to really look into classloaders they are not that bad. Only hard to do right (I'm not sure whether I've ever done so 8-). There are sure a lot of things to keep in mind, junit support, classpath delagate, antclassloader, project#setCoreLoader() (not used??) etc ;-) Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Dominique Devienne wrote, On 12/08/2003 15.37: I'm also interested PropertyHelper, and in particular Costin's experimental XPath based one. I'd like to be able to define functions (defined as part of an AntLib) to operate directly on property values, kind of like XPath functions, and it sounds like property helper is the way to get this!?!? --DD Yes. PropertyHelper is a property interceptor, and it simply rocks. In essence, you register a helper with Ant. Then, at each request for a property, each registered helper is asked for the property value in turn; the first one that has it, returns it. A typical one is the xpath one, as you say, that resolves the request as an xpath in the Ant Project, if the property starts with xpath:. Centipede has been using it for a long time, basically to read an xml file as a property in a more powerful way than simply using xmlproperty. Now we are doing our own helper that reads the Gump descriptor, the Maven one, etc and makes them all accessible as a single virtual descriptor. In this way Ant users can have any descriptor they want and use that to gather properties and infos for the project. Just an example of the usage of PropertyHelper. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/dotnet DotnetCompile.java
bodewig 2003/08/14 00:02:34
Modified:src/main/org/apache/tools/ant/taskdefs/optional/dotnet
DotnetCompile.java
Log:
make definitions work for Mono
Revision ChangesPath
1.14 +6 -2
ant/src/main/org/apache/tools/ant/taskdefs/optional/dotnet/DotnetCompile.java
Index: DotnetCompile.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/dotnet/DotnetCompile.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- DotnetCompile.java8 Aug 2003 00:11:05 - 1.13
+++ DotnetCompile.java14 Aug 2003 07:02:34 - 1.14
@@ -720,19 +720,23 @@
protected String getDefinitionsParameter() throws BuildException {
StringBuffer defines = new StringBuffer();
Enumeration defEnum = definitionList.elements();
+boolean firstDefinition = true;
while (defEnum.hasMoreElements()) {
//loop through all definitions
DotnetDefine define = (DotnetDefine) defEnum.nextElement();
if (define.isSet(this)) {
//add those that are set, and a delimiter
+if (!firstDefinition) {
+defines.append(getDefinitionsDelimiter());
+}
defines.append(define.getValue(this));
-defines.append(getDefinitionsDelimiter());
+firstDefinition = false;
}
}
if (defines.length() == 0) {
return null;
} else {
-return /D: + defines;
+return /d: + defines;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/util/facade FacadeTaskHelper.java
bodewig 2003/08/14 00:04:41 Modified:src/main/org/apache/tools/ant/taskdefs/cvslib ChangeLogParser.java src/main/org/apache/tools/ant/taskdefs/optional NetRexxC.java src/main/org/apache/tools/ant/taskdefs/optional/j2ee ServerDeploy.java src/main/org/apache/tools/ant/taskdefs/optional/jsp/compilers DefaultJspCompilerAdapter.java src/main/org/apache/tools/ant/taskdefs/optional/junit JUnitTest.java src/main/org/apache/tools/ant/taskdefs/optional/sitraka XMLReport.java src/main/org/apache/tools/ant/taskdefs/optional/sitraka/bytecode ClassPathLoader.java src/main/org/apache/tools/ant/util Watchdog.java src/main/org/apache/tools/ant/util/facade FacadeTaskHelper.java Log: 2003 Revision ChangesPath 1.21 +2 -2 ant/src/main/org/apache/tools/ant/taskdefs/cvslib/ChangeLogParser.java Index: ChangeLogParser.java === RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/cvslib/ChangeLogParser.java,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- ChangeLogParser.java 13 Aug 2003 15:02:28 - 1.20 +++ ChangeLogParser.java 14 Aug 2003 07:04:40 - 1.21 @@ -1,7 +1,7 @@ /* * The Apache Software License, Version 1.1 * - * Copyright (c) 2002 The Apache Software Foundation. All rights + * Copyright (c) 2002-2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without 1.27 +1 -1 ant/src/main/org/apache/tools/ant/taskdefs/optional/NetRexxC.java Index: NetRexxC.java === RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/NetRexxC.java,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- NetRexxC.java 13 Aug 2003 15:02:28 - 1.26 +++ NetRexxC.java 14 Aug 2003 07:04:40 - 1.27 @@ -1,7 +1,7 @@ /* * The Apache Software License, Version 1.1 * - * Copyright (c) 2000-2002 The Apache Software Foundation. All rights + * Copyright (c) 2000-2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without 1.12 +1 -1 ant/src/main/org/apache/tools/ant/taskdefs/optional/j2ee/ServerDeploy.java Index: ServerDeploy.java === RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/j2ee/ServerDeploy.java,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- ServerDeploy.java 13 Aug 2003 15:02:28 - 1.11 +++ ServerDeploy.java 14 Aug 2003 07:04:41 - 1.12 @@ -1,7 +1,7 @@ /* * The Apache Software License, Version 1.1 * - * Copyright (c) 2002 The Apache Software Foundation. All rights + * Copyright (c) 2002-2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without 1.11 +1 -1 ant/src/main/org/apache/tools/ant/taskdefs/optional/jsp/compilers/DefaultJspCompilerAdapter.java Index: DefaultJspCompilerAdapter.java === RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/jsp/compilers/DefaultJspCompilerAdapter.java,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- DefaultJspCompilerAdapter.java13 Aug 2003 15:02:28 - 1.10 +++ DefaultJspCompilerAdapter.java14 Aug 2003 07:04:41 - 1.11 @@ -1,7 +1,7 @@ /* * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2002 The Apache Software Foundation. All rights + * Copyright (c) 2001-2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without 1.19 +1 -1 ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTest.java Index: JUnitTest.java === RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTest.java,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- JUnitTest.java13 Aug 2003 15:19:34 - 1.18 +++ JUnitTest.java14 Aug 2003 07:04:41 - 1.19 @@ -1,7 +1,7 @@ /* * The Apache Software License, Version 1.1 * - *
DO NOT REPLY [Bug 22345] - In J2SDK 1.5.0 (Tiger) enum is a keyword
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=22345. 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=22345 In J2SDK 1.5.0 (Tiger) enum is a keyword --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 08:20 --- I tried it - and javac returned a warning but compiled successfully. But this does not mean, that it will compile without errors in future builds of J2SDK 1.5. -- javac -target 1.5 bla/enum/test/Test.java bla/enum/test/Test.java:1: warning: as of release 1.5, enum is a keyword, and may not be used as an identifier package bla.enum.test; ^ 1 warning -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/util/facade FacadeTaskHelper.java
Opps, sorry about the year in the enum update yesterday. Peter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] namespace and antlib
On Thursday 14 August 2003 06:45, Costin Manolache wrote: peter reilly wrote: On Tuesday 12 August 2003 13:24, Stefan Bodewig wrote: On Tue, 12 Aug 2003, peter reilly [EMAIL PROTECTED] wrote: On Tuesday 12 August 2003 12:36, Stefan Bodewig wrote: On Fri, 1 Aug 2003, peter reilly [EMAIL PROTECTED] wrote: typedef resource=net/sf/antcontrib/antlib.xml uri=antlib:net.sf.antcontrib classpath=/tmp/ant-contrib.jar/ wouldn't the resource attribute be redundant in that case? Not in this case. The automatic lookup of uri=antlib:net.sf.antcontrib to net/sf/antcontrib/antlib.xml resource currently is done once when the ns prefix is encountered the first time - it does not take place at the typedef/ task. The obvious question would be: Why not? The code handles build scripts like: project xmlns:ac=antlib:net.sf.antcontrib (1) ac:shellscript shell=bash (2) echo helloworld /ac:shellscript typedef uri=antlib:net.sf.antcontrib (3) name=shellscript classpath=testing.classes classname=net.sf.antcontrib.pending.ShellScriptNew/ ac:shellscript shell=bash (4) echo helloword from test shellscript /ac:shellscript /project (1) will associate the ns prefix ac with the uri antlib:net.sf.antcontrib (2) ComponentHelper#createComponent will call #checknamespace for antlib:net.sf.antcontrib and maps it to the net/sf/antcontrib/antlib.xml resource. It then creates a typedef task, and sets the uri and resource to antlib:... and net/sf... and sets the onerror parameter to ignore, this will make available the antcontrib's definitions. ComponentHelper stores the fact that it has implicitly loaded in these definitions so that it does not do this again. 3) This will override the antcontribs' uris definition of shellscript. 4) This will execute the new definition. All this overriding may create some bad maintaince problems. I wish we wouldn't support this feature... This is for backward's compatiblity - taskdef/ and typedef/ have always worked this way. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: beating the dead Ant 1.6 horse
On Thursday 14 August 2003 06:38, Costin Manolache wrote: Conor MacNeill wrote: The others are antlib/namespace/polymorph stuff. I'm wondering if we can get to the point where the ant optional tasks are packaged as antlibs and potentially not added to the root loader if their supporting libraries are not also available to the root loader. This would allow them to be taskdef'd in later in a build. What's the status on that ? Any decision on how to deal with the loaders ? I'll have some time next week, I wanted to finish the classloader task - is it still usefull ? Most definitely. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[new tasks] presetdef and macrodef
Hi,
I have written a couple of tasks to enable definition of new tasks
in ant.
presetdef (formally known as extendtype)
this defines a new task or type based on a current ant task or type, with
attributes or elements preset.
example useage:
presetdef name=my.javac
javac debug=${debug} deprecation=${deprecation}/
/presetdef
my.javac may now be used as a task in the same way as javac
but the attribute debug and deprecation will be preset.
macrodef
this defines a new task in the same way as scriptdef except it
uses a sequential as a defintion of the task. The macrodef
task has nested elements - param and element to allow the
user to specify attributes and elements of the new task. These
get substituted into the sequential when the new task is
run.
example: (from a current project)
macrodef name=call-cc
param name=target/
param name=link/
param name=target.dir/
element name=cc-elements/
sequential
mkdir dir=${obj.dir}/${target}/
mkdir dir=${target.dir}/
cc link=${link} objdir=${obj.dir}/${target}
outfile=${target.dir}/${target}
compiler refid=compiler.options/
cc-elements/
/cc
/sequential
/macrodef
macrodef name=compile-exec
param name=program/
element name=cc-files/
sequential
call-cc target=${program} link=executable
target.dir=${build.bin.dir}
cc-elements
includepath location=${gen.dir}/
includepath location=test/
cc-files/
linker refid=linker-libs/
/cc-elements
/call-cc
/sequential
/macrodef
compile-exec program=unittests
cc-files
fileset dir=test/unittest includes = **/*.cpp/
fileset dir=${gen.dir} includes = *.cpp/
/cc-files
/compile-exec
Will I place these tasks in ant or ant-contrib ?
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
Cool. I think these should go in Ant :-) As you know I had thought about macrodef but I'm happy to see you've done it. I think there is a slight property scoping issue for the nested params. I had thought about a different syntax for macro params (e.g. $[target]), perhaps hooked into a specific property helper used for the macro scope. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
On Thursday 14 August 2003 10:31, Conor MacNeill wrote:
Cool.
I think these should go in Ant :-)
Excellent.
As you know I had thought about macrodef but I'm happy to
see you've done it. I think there is a slight property scoping issue
for the nested params. I had thought about a different syntax for
macro params (e.g. $[target]), perhaps hooked into a specific property
helper used for the macro scope.
Initially I used $(target) but changed back to using
${target} as this is what people (including me) are used to.
The substitution is done by the task itself and does not
use the ant property infrastructure. The effect of this is to
have a macro textual scope for the parameters (which look like
properties).
I had looked at having a task scope for properties, but this
looked difficult to achieve.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs DefBase.java
peterreilly2003/08/14 02:45:39 Modified:src/main/org/apache/tools/ant/taskdefs DefBase.java Log: fix head as DefBase.java is a new file Revision ChangesPath 1.3 +1 -1 ant/src/main/org/apache/tools/ant/taskdefs/DefBase.java Index: DefBase.java === RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/DefBase.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- DefBase.java 13 Aug 2003 13:36:36 - 1.2 +++ DefBase.java 14 Aug 2003 09:45:39 - 1.3 @@ -1,7 +1,7 @@ /* * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights + * Copyright (c) 2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : [new tasks] presetdef and macrodef
-Message d'origine- De : peter reilly [mailto:[EMAIL PROTECTED] Envoyé : jeudi 14 août 2003 11:21 À : [EMAIL PROTECTED] Objet : [new tasks] presetdef and macrodef Hi, I have written a couple of tasks to enable definition of new tasks in ant. presetdef (formally known as extendtype) [snip/] macrodef this defines a new task in the same way as scriptdef except it uses a sequential as a defintion of the task. The macrodef task has nested elements - param and element to allow the user to specify attributes and elements of the new task. These get substituted into the sequential when the new task is run. [snip/] Hi, I was looking to this kind of features when I started my build file developement. I solved my need by doing dirty antcall. I am very happy to see this in ant core now, and I will adapt my build file as soon as possible ! :)) And it should solve some of my properties issues. Thanks, it is a good job! (Like everybody's one) I am using Ant for two years and i never find real blocker issues, or already closed in cvs. This kind of new features give me the desire for taking an active part. Thanks everybody! Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Sounds great!
In anticipation of this feature I have used a few namespaced properties for
my custom tasks. And since Ant 1.5 doesn't have any value for these, I've
just made the tasks resolve them explicitly.
This raises a question: Are properties whose values are resolved by custom
PropertyHelpers always converted to Strings? I see that the return type of
PropertyHelper#getPropertyHook(String, String, boolean) has Object as the
return type. But if that's always converted to a String then my custom
PropertyHelper will need to make sure that this is done correctly, i.e. that
the Object yields a meaningful String representation.
But for tasks which have a setXXX(Object) method it would maybe make sense
to preserve the property value as an Object instance, if that's what's
actually in the buildfile. E.g.
foo xxx=${my:bar}/
would not convert the ${my:bar} property to a String.
Cheers,
--
knut
Nicola Ken Barozzi [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Dominique Devienne wrote, On 12/08/2003 15.37:
I'm also interested PropertyHelper, and in particular Costin's
experimental XPath based one. I'd like to be able to define
functions (defined as part of an AntLib) to operate directly on
property values, kind of like XPath functions, and it sounds like
property helper is the way to get this!?!? --DD
Yes. PropertyHelper is a property interceptor, and it simply rocks.
In essence, you register a helper with Ant. Then, at each request for a
property, each registered helper is asked for the property value in
turn; the first one that has it, returns it.
A typical one is the xpath one, as you say, that resolves the request as
an xpath in the Ant Project, if the property starts with xpath:.
Centipede has been using it for a long time, basically to read an xml
file as a property in a more powerful way than simply using xmlproperty.
Now we are doing our own helper that reads the Gump descriptor, the
Maven one, etc and makes them all accessible as a single virtual
descriptor. In this way Ant users can have any descriptor they want and
use that to gather properties and infos for the project.
Just an example of the usage of PropertyHelper.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
On Thu, 14 Aug 2003, peter reilly [EMAIL PROTECTED] wrote: Will I place these tasks in ant or ant-contrib ? Ant, they sound very useful. presetdef is a wonderful way to plug in user preferences. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
This looks excellent! It makes Ant a lot more flexible, but at the same
time also more compilcated to use. Buildfiles with (possibly nested)
macrodef/s and include/s could be a lot harder to understand and
maintain. But if used correctly, probably easier!
A question: is macrodef a special task in the sense that it seems to be
able to suppress Ant from resolving properties for it when the task is
evaluated? Is there a mechanism which allows this to be done in custom
tasks as well?
--
knut
peter reilly [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Thursday 14 August 2003 10:31, Conor MacNeill wrote:
Cool.
I think these should go in Ant :-)
Excellent.
As you know I had thought about macrodef but I'm happy to
see you've done it. I think there is a slight property scoping issue
for the nested params. I had thought about a different syntax for
macro params (e.g. $[target]), perhaps hooked into a specific property
helper used for the macro scope.
Initially I used $(target) but changed back to using
${target} as this is what people (including me) are used to.
The substitution is done by the task itself and does not
use the ant property infrastructure. The effect of this is to
have a macro textual scope for the parameters (which look like
properties).
I had looked at having a task scope for properties, but this
looked difficult to achieve.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
User preferences - nice scenario. - define your preferences with presetdef and macrodef in %user.home%/.ant/preferences.xml - include that file with include in your actual buildfile So: +1 for placing in Ant Jan -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 1:28 PM To: [EMAIL PROTECTED] Subject: Re: [new tasks] presetdef and macrodef On Thu, 14 Aug 2003, peter reilly [EMAIL PROTECTED] wrote: Will I place these tasks in ant or ant-contrib ? Ant, they sound very useful. presetdef is a wonderful way to plug in user preferences. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
antoine 2003/08/14 04:37:36
Modified:src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
Log:
files which are pointed to by symbolic links should be excluded if
followsymlinks=false
Revision ChangesPath
1.46 +4 -3
ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java
Index: FTP.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- FTP.java 7 Aug 2003 22:23:35 - 1.45
+++ FTP.java 14 Aug 2003 11:37:36 - 1.46
@@ -290,9 +290,10 @@
name + File.separator, fast);
}
} else {
-if (isFunctioningAsFile(ftp, dir, file)) {
-String name = vpath + file.getName();
-
+String name = vpath + file.getName();
+if (!isFollowSymlinks()
file.isSymbolicLink()) {
+dirsExcluded.addElement(name);
+} else if (isFunctioningAsFile(ftp, dir, file)) {
if (isIncluded(name)) {
if (!isExcluded(name)) {
filesIncluded.addElement(name);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
On Thursday 14 August 2003 12:28, Knut Wannheden wrote: A question: is macrodef a special task in the sense that it seems to be able to suppress Ant from resolving properties for it when the task is evaluated? Is there a mechanism which allows this to be done in custom tasks as well? The trick is that MacroDef uses TaskContainer in a nested element. This is given UnknownElements before they are executed. MacroInstance then copies and walks the tree of unknownelements, modifing attribute values and text values. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
The following tasks will be an excellent addition for the use Centipede
does of Ant, so it's a big thumbs up!
Presetdef can be used to redefine the most used Ant tasks adding the
defaults taken from the descriptor we use.
macrodef can make us finally create real macros that are not only
targets, as instead has been done till now, so we can really make
libraries of tasks defined through Ant buildfiles and not have them
necessarily as targets.
:-D
peter reilly wrote, On 14/08/2003 11.20:
Hi,
I have written a couple of tasks to enable definition of new tasks
in ant.
presetdef (formally known as extendtype)
this defines a new task or type based on a current ant task or type, with
attributes or elements preset.
example useage:
presetdef name=my.javac
javac debug=${debug} deprecation=${deprecation}/
/presetdef
my.javac may now be used as a task in the same way as javac
but the attribute debug and deprecation will be preset.
macrodef
this defines a new task in the same way as scriptdef except it
uses a sequential as a defintion of the task. The macrodef
task has nested elements - param and element to allow the
user to specify attributes and elements of the new task. These
get substituted into the sequential when the new task is
run.
example: (from a current project)
macrodef name=call-cc
param name=target/
param name=link/
param name=target.dir/
element name=cc-elements/
sequential
mkdir dir=${obj.dir}/${target}/
mkdir dir=${target.dir}/
cc link=${link} objdir=${obj.dir}/${target}
outfile=${target.dir}/${target}
compiler refid=compiler.options/
cc-elements/
/cc
/sequential
/macrodef
macrodef name=compile-exec
param name=program/
element name=cc-files/
sequential
call-cc target=${program} link=executable
target.dir=${build.bin.dir}
cc-elements
includepath location=${gen.dir}/
includepath location=test/
cc-files/
linker refid=linker-libs/
/cc-elements
/call-cc
/sequential
/macrodef
compile-exec program=unittests
cc-files
fileset dir=test/unittest includes = **/*.cpp/
fileset dir=${gen.dir} includes = *.cpp/
/cc-files
/compile-exec
Will I place these tasks in ant or ant-contrib ?
Peter
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs MacroDef.java MacroInstance.java PreSetDef.java defaults.properties
peterreilly2003/08/14 05:46:02
Modified:src/main/org/apache/tools/ant/taskdefs defaults.properties
Added: src/main/org/apache/tools/ant/taskdefs MacroDef.java
MacroInstance.java PreSetDef.java
Log:
Adding tasks presetdef and macrodef
Revision ChangesPath
1.152 +2 -0
ant/src/main/org/apache/tools/ant/taskdefs/defaults.properties
Index: defaults.properties
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/defaults.properties,v
retrieving revision 1.151
retrieving revision 1.152
diff -u -r1.151 -r1.152
--- defaults.properties 23 Jul 2003 14:12:12 - 1.151
+++ defaults.properties 14 Aug 2003 12:46:01 - 1.152
@@ -76,6 +76,8 @@
subant=org.apache.tools.ant.taskdefs.SubAnt
sync=org.apache.tools.ant.taskdefs.Sync
defaultexcludes=org.apache.tools.ant.taskdefs.DefaultExcludes
+presetdef=org.apache.tools.ant.taskdefs.PreSetDef
+macrodef=org.apache.tools.ant.taskdefs.MacroDef
# optional tasks
image=org.apache.tools.ant.taskdefs.optional.image.Image
1.1 ant/src/main/org/apache/tools/ant/taskdefs/MacroDef.java
Index: MacroDef.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names Ant and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package org.apache.tools.ant.taskdefs;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import java.util.HashMap;
import org.apache.tools.ant.AntTypeDefinition;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.ComponentHelper;
import org.apache.tools.ant.Project;
import org.apache.tools.ant.ProjectHelper;
import org.apache.tools.ant.Task;
import org.apache.tools.ant.TaskContainer;
import org.apache.tools.ant.UnknownElement;
/**
* Describe class codeMacroDef/code here.
*
* @author Peter Reilly
*/
public class MacroDef extends Task implements AntlibInterface, TaskContainer {
private UnknownElement nestedTask;
private String name;
private String componentName;
private List params = new ArrayList();
private Mapelements = new HashMap();
private String uri;
/**
* Name of the definition
* @param name the
cvs commit: ant/docs/manual/CoreTasks presetdef.html macrodef.html
peterreilly2003/08/14 05:48:10
Modified:docs/manual coretasklist.html
Added: docs/manual/CoreTasks presetdef.html macrodef.html
Log:
adding doc for presetdef and macrodef
Revision ChangesPath
1.50 +2 -0 ant/docs/manual/coretasklist.html
Index: coretasklist.html
===
RCS file: /home/cvs/ant/docs/manual/coretasklist.html,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- coretasklist.html 9 Jul 2003 16:24:35 - 1.49
+++ coretasklist.html 14 Aug 2003 12:48:10 - 1.50
@@ -60,12 +60,14 @@
a href=CoreTasks/loadfile.htmlLoadFile/abr
a href=CoreTasks/loadproperties.htmlLoadProperties/abr
a href=CoreTasks/mail.htmlMail/abr
+a href=CoreTasks/macrodef.htmlMacroDef/abr
a href=CoreTasks/manifest.htmlManifest/abr
a href=CoreTasks/mkdir.htmlMkdir/abr
a href=CoreTasks/move.htmlMove/abr
a href=CoreTasks/parallel.htmlParallel/abr
a href=CoreTasks/patch.htmlPatch/abr
a href=CoreTasks/pathconvert.htmlPathConvert/abr
+a href=CoreTasks/presetdef.htmlPreSetDef/abr
a href=CoreTasks/property.htmlProperty/abr
a href=CoreTasks/recorder.htmlRecord/abr
a href=CoreTasks/rename.htmliRename/i/abr
1.1 ant/docs/manual/CoreTasks/presetdef.html
Index: presetdef.html
===
html
head
meta http-equiv=Content-Language content=en-us/meta
titlePreSetDef Task/title
/head
body
h2a name=presetdefPreSetDef/a/h2
h3Description/h3
p
The preset definition generates a new definition
based on a current definition with some attributes
or elements preset.
/p
p
Introduced in ant1.6 font color=redExperimental/font.
/p
h3Parameters/h3
table border=1 cellpadding=2 cellspacing=0
tr
td valign=topbAttribute/b/td
td valign=topbDescription/b/td
td align=center valign=topbRequired/b/td
/tr
tr
td valign=topname/td
td valign=topthe name of the new definition/td
td valign=top align=centerYes/td
/tr
tr
td valign=topuri/td
td valign=top
The uri that this definition should live in.
/td
td valign=top align=centerNo/td
/tr
/table
h3Parameters specified as nested elements/h3
h4another type with attributes or elements set/h4
pThe lt;presetdefgt; task takes one nested element as a parameter.
This nested element can be any other type or task. The attributes
and elements that need to be preset are placed here.
/p
h3Examples/h3
p
The following fragment defines a javac task with the debug and
deprecation
attributes set. It also has a src element to source files from a
generated
directory.
/p
blockquote
pre
lt;presetdef name=my.javacgt;
lt;javac debug=${debug} deprecation=${deprecation}gt;
lt;src path=${gen.dir}/gt;
lt;/javacgt;
lt;/presetdefgt;
/pre
/blockquote
p
This can be used as a normal javac task - example:
/p
blockquote
pre
lt;my.javac src=${src.dir} destdir=${classes.dir}/gt;
/pre
/blockquote
hr
p align=centerCopyright copy; 2003 Apache Software
Foundation. All rights Reserved./p
/body
/html
1.1 ant/docs/manual/CoreTasks/macrodef.html
Index: macrodef.html
===
html
head
meta http-equiv=Content-Language content=en-us/meta
titleMacroDef Task/title
/head
body
h2a name=macrodefMacroDef/a/h2
h3Description/h3
p
This defines a new task using a lt;sequentialgt; or lt;parallelgt;
nested task as a template. Nested elements lt;paramgt; and
lt;elementgt; are used to specify attributes and elements of
the new task. These get substituted into the lt;sequentialgt;
or lt;parallelgt; task when the new task is run.
/p
p
Introduced in ant1.6 font color=redExperimental/font.
/p
h3Parameters/h3
table border=1 cellpadding=2 cellspacing=0
tr
td valign=topbAttribute/b/td
td valign=topbDescription/b/td
td align=center valign=topbRequired/b/td
/tr
tr
td valign=topname/td
td valign=topthe name of the new definition/td
td valign=top align=centerYes/td
/tr
tr
td valign=topuri/td
td valign=top
The uri that this definition should live in.
/td
td valign=top align=centerNo/td
/tr
/table
h3Parameters specified as
Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs MacroDef.java MacroInstance.java PreSetDef.java defaults.properties
Could please @since 1.6 tags be added to the code? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs PreSetDefTest.java MacroDefTest.java
peterreilly2003/08/14 06:17:26
Added: src/etc/testcases/taskdefs presetdef.xml macrodef.xml
src/testcases/org/apache/tools/ant/taskdefs
PreSetDefTest.java MacroDefTest.java
Log:
some unittests for presetdef and macrodef
Revision ChangesPath
1.1 ant/src/etc/testcases/taskdefs/presetdef.xml
Index: presetdef.xml
===
project
target name=simple
presetdef name=my.echo
echo message=Hello world/
/presetdef
my.echo/
/target
target name=text
presetdef name=my.echo
echoInner Text/echo
/presetdef
my.echo/
/target
target name=uri
presetdef name=echo uri=abc
echo message=Hello world/
/presetdef
x:echo xmlns:x=abc/
/target
/project
1.1 ant/src/etc/testcases/taskdefs/macrodef.xml
Index: macrodef.xml
===
project
target name=simple
macrodef name=my.echo
param name=text/
sequential
echo message=${text}/
/sequential
/macrodef
my.echo text=Hello World/
/target
target name=text
macrodef name=my.echo
param name=text/
sequential
echo${text}/echo
/sequential
/macrodef
my.echo text=Inner Text/
/target
target name=uri
macrodef name=echo uri=abc
param name=text/
sequential
echo message=${text}/
/sequential
/macrodef
x:echo xmlns:x=abc text=Hello World/
/target
target name=nested
macrodef name=nested
element name=nested/
sequential
nested/
/sequential
/macrodef
nested
nested
echoA nested element/echo
/nested
/nested
/target
/project
1.1
ant/src/testcases/org/apache/tools/ant/taskdefs/PreSetDefTest.java
Index: PreSetDefTest.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names Ant and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package org.apache.tools.ant.taskdefs;
import org.apache.tools.ant.BuildFileTest;
import org.apache.tools.ant.Project;
import org.apache.tools.ant.Task;
/**
*
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs PreSetDef.java MacroDef.java MacroInstance.java
peterreilly2003/08/14 06:22:25
Modified:src/main/org/apache/tools/ant/taskdefs PreSetDef.java
MacroDef.java MacroInstance.java
Log:
Add in Ant 1.6 javadocs for presetdef and macrodef
Revision ChangesPath
1.2 +1 -0 ant/src/main/org/apache/tools/ant/taskdefs/PreSetDef.java
Index: PreSetDef.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/PreSetDef.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PreSetDef.java14 Aug 2003 12:46:01 - 1.1
+++ PreSetDef.java14 Aug 2003 13:22:24 - 1.2
@@ -75,6 +75,7 @@
* /pre
*
* @author Peter Reilly
+ * @since Ant 1.6
*/
public class PreSetDef extends Task implements AntlibInterface,
TaskContainer {
private UnknownElement nestedTask;
1.2 +1 -0 ant/src/main/org/apache/tools/ant/taskdefs/MacroDef.java
Index: MacroDef.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/MacroDef.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MacroDef.java 14 Aug 2003 12:46:01 - 1.1
+++ MacroDef.java 14 Aug 2003 13:22:24 - 1.2
@@ -72,6 +72,7 @@
* Describe class codeMacroDef/code here.
*
* @author Peter Reilly
+ * @since Ant 1.6
*/
public class MacroDef extends Task implements AntlibInterface, TaskContainer
{
private UnknownElement nestedTask;
1.2 +1 -0
ant/src/main/org/apache/tools/ant/taskdefs/MacroInstance.java
Index: MacroInstance.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/MacroInstance.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MacroInstance.java14 Aug 2003 12:46:01 - 1.1
+++ MacroInstance.java14 Aug 2003 13:22:24 - 1.2
@@ -77,6 +77,7 @@
* and makes a copy of the unknown element, substituting
* the the parameter values in attributes and text.
* @author Peter Reilly
+ * @since Ant 1.6
*/
public class MacroInstance extends Task implements DynamicConfigurator {
private MacroDef template;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs MacroDef.java MacroInstance.java PreSetDef.java defaults.properties
Tis done. Peter On Thursday 14 August 2003 14:04, Martijn Kruithof wrote: Could please @since 1.6 tags be added to the code? - 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]
DO NOT REPLY [Bug 22417] New: - add an owner, group, and umask to the war 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=22417. 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=22417 add an owner, group, and umask to the war task Summary: add an owner, group, and umask to the war task Product: Ant Version: 1.5.3 Platform: Other URL: http://ant.apache.org/manual/CoreTasks/war.html OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] One use of this is for example when deploying to a tomcat webserver via the destfile attribute (see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22405). The war file should only be owned e.g. by the user/group tomcat and have the permission 7*0 (or as umask 00*7) Obviously, an implementation of this would only be able to downgrade the rights, i.e. if root (/sudo) is running the build.xml, user tomcat can be set. If user developer with umask 0022 runs it, the user cannot be changed, but the permissions for example could be set to 750 or 644. I suggest this for war, but obviously equal results can be achieved if it were available for copy or move. P.S.: See also the complementary RFE to just passively test whether the environment is set up all right from a security perspective: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22370 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22417] - add an owner, group, and umask to the war 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=22417. 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=22417 add an owner, group, and umask to the war task --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 13:48 --- I would understand better a request to set owner and group for the entries of the war file, rather than the war file itself. Maybe it is better to create chgrp, chown, chmod tasks in ant, but ant is going to be huge if in the end we wrap all UNIX commands which can possibly be run in installation or application management scripts (ldd, nm, ...). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: can subant reuse Projects?
No, this is currently not possible. subant uses ant behind the scene's, and doesn't access the created project. Now, I've also hacked antreturn that works for my own purpose, and does indeed get access to the child project thru devious means, so in theory it could cache the child projects, so I just don't think it's very advisable... On the other hand, my goal with antreturn was to get back properties and references from the child build, so you could get back up a property set in a.xml, and feed it back down to c.xml and later to a.xml to avoid reprocessing something. My own version of subant allows passing down a propertyset, but I guess one could also have a return propertyset by merging the antreturn functionality. All this sounds very hackish though, even to me ;-) Even my current use of antReturn I find hackish, but without the ability to use Ant's own digester-like XML to Java engine, I find easier to call another Project and extract what I need out of it, rather than coding from scratch the info I need about of a separate non-Ant (data-type) file. I hope I'm not too off base vis-à-vis your question. --DD -Original Message- From: Knut Wannheden [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 6:40 AM To: [EMAIL PROTECTED] Subject: can subant reuse Projects? Hi, Up until now I've been using my own subant like task. But now that Ant 1.6 doesn't seem too distant anymore I'd like to integrate with subant. There's one thing I'm wondering about: Can subant reuse the same Project object corresponding to a buildfile in multiple calls? The reason that I'm askin this is that I think it would be nice if a target's dependencies were only resolved once. Consider the following case: a.xml ^ / \ b.xmlc.xml ^ ^ \/ d.xml where I in b.xml and c.xml use subant to invoke a target i a.xml. And in d.xml i use subant to invoke a target in b.xml and c.xml. Now if both b.xml and c.xml invoke the same target foo in a.xml, then I'd only want the dependencies of a:foo to be resolved once. Is this currently possible with subant or would it be possible to add this behaviour? -- knut - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: can subant reuse Projects?
Dominique, Even my current use of antReturn I find hackish, but without the ability to use Ant's own digester-like XML to Java engine, I find easier to call another Project and extract what I need out of it, rather than coding from scratch the info I need about of a separate non-Ant (data-type) file. Maybe the xpath PropertyHelper would help you in this case. My version of subant (not based on it (yet)) does what I suggested, but not by reusing Projects, because it's also internally using ant :-) Rather I have a static Map which tells me what targets I've already run on what buildfiles. Of course it's not always desirable to run a target only exactly once. But IMO, if the buildfiles are well organized, this should be the case. At least for project inter-dependencies. And I can of course always get around this optimization by using ant instead. Also my subant has a onlyonce attribute to control this. I found that I can significantly lower my build times with this behaviour. Also the log is more readable. I think I will continue using my own subant. But if someone thinks this is a good idea I could write a patch which would add a onlyonce attribute to Ant's subant. -- knut I hope I'm not too off base vis-à-vis your question. --DD -Original Message- From: Knut Wannheden [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 6:40 AM To: [EMAIL PROTECTED] Subject: can subant reuse Projects? Hi, Up until now I've been using my own subant like task. But now that Ant 1.6 doesn't seem too distant anymore I'd like to integrate with subant. There's one thing I'm wondering about: Can subant reuse the same Project object corresponding to a buildfile in multiple calls? The reason that I'm askin this is that I think it would be nice if a target's dependencies were only resolved once. Consider the following case: a.xml ^ / \ b.xmlc.xml ^ ^ \/ d.xml where I in b.xml and c.xml use subant to invoke a target i a.xml. And in d.xml i use subant to invoke a target in b.xml and c.xml. Now if both b.xml and c.xml invoke the same target foo in a.xml, then I'd only want the dependencies of a:foo to be resolved once. Is this currently possible with subant or would it be possible to add this behaviour? -- knut - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22370] - enhance available to test for owner, group and permissions - security feature
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=22370. 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=22370 enhance available to test for owner, group and permissions - security feature --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 14:10 --- How to do this in Java - (not being a Java expert), it appears that the neccesary classes do exist as per http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22405 . For the complement to this passive/get approach - see the suggestion for the set approach in http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22417 . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Yes. PropertyHelper is a property interceptor, and it simply rocks.
In essence, you register a helper with Ant. Then, at each request for
a property, each registered helper is asked for the property value in
turn; the first one that has it, returns it.
Completely not following this property helper discussion up to this
point so I may be repeating something, (forgive me if I am) but this
sounds like the results of the request for a property could change if a
new property helper gets added... Does this break immutability? It may
be that the value of a property object never changes, but if the value
of ${foo} is one thing and then becomes another when a helper is
added I suspect whatever you have done is not going to cause this,
but what about someone writing a custom task that intentionally adds and
removes property helpers. What happens if someone writes a setproperty
task built on this idea? what happens if the property helper intercepts
built in things like ${basedir}? Sounds like the basis for a possible
chdir task :). Sounds highly abusable to me...
If you have set it up so ant doesn't accept new property helpers after
it starts executing the file, then this probably isn't an issue...
Just curious,
-Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Knut Wannheden wrote:
Sounds great!
In anticipation of this feature I have used a few namespaced properties
for
my custom tasks. And since Ant 1.5 doesn't have any value for these, I've
just made the tasks resolve them explicitly.
This raises a question: Are properties whose values are resolved by custom
PropertyHelpers always converted to Strings? I see that the return type
of PropertyHelper#getPropertyHook(String, String, boolean) has Object as
the
return type. But if that's always converted to a String then my custom
PropertyHelper will need to make sure that this is done correctly, i.e.
that the Object yields a meaningful String representation.
But for tasks which have a setXXX(Object) method it would maybe make sense
to preserve the property value as an Object instance, if that's what's
actually in the buildfile. E.g.
foo xxx=${my:bar}/
would not convert the ${my:bar} property to a String.
If you read the comments on top of PropertyHelper - that was one of the
goals, but I don't think it is implemented yet. The return value for the
property interceptors is already an object, but the code that does property
replacement doesn't know how to deal with ${prop}.
Costin
Cheers,
--
knut
Nicola Ken Barozzi [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Dominique Devienne wrote, On 12/08/2003 15.37:
I'm also interested PropertyHelper, and in particular Costin's
experimental XPath based one. I'd like to be able to define
functions (defined as part of an AntLib) to operate directly on
property values, kind of like XPath functions, and it sounds like
property helper is the way to get this!?!? --DD
Yes. PropertyHelper is a property interceptor, and it simply rocks.
In essence, you register a helper with Ant. Then, at each request for a
property, each registered helper is asked for the property value in
turn; the first one that has it, returns it.
A typical one is the xpath one, as you say, that resolves the request as
an xpath in the Ant Project, if the property starts with xpath:.
Centipede has been using it for a long time, basically to read an xml
file as a property in a more powerful way than simply using xmlproperty.
Now we are doing our own helper that reads the Gump descriptor, the
Maven one, etc and makes them all accessible as a single virtual
descriptor. In this way Ant users can have any descriptor they want and
use that to gather properties and infos for the project.
Just an example of the usage of PropertyHelper.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
After all the praises, I hope my post doesn't sound too negative. I also
think it's a great addition Peter, I just have a few reservations ;-)
See below... --DD
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
presetdef (formally known as extendtype)
this defines a new task or type based on a current ant task or type,
with attributes or elements preset.
example useage:
presetdef name=my.javac
javac debug=${debug} deprecation=${deprecation}/
/presetdef
my.javac may now be used as a task in the same way as javac
but the attribute debug and deprecation will be preset.
I'll start by neat picking ;-) What presetdef does is binding a given
value to a task attribute. In the C++ world, the method to do that are call
bind, which is IMHO better that preset.
Also, this kind of static attribute-binding is useful indeed (I've actually
asked for it a few times), but is hardly a definition, and it's bad that it
forces you to rewrite the task name. I don't want to modify all my builds to
use my.javac just to take advantage of that feature.
Finally, presetdef, in term of functionality and not implementation, is
just a subset of macrodef in my opinion, and doesn't deserve Task status.
Much more useful IMO was be the ability to bind (or preset) values using
XPath expressions, to follow your example:
//javac/@debug = ${debug}
//javac/@deprecation = ${deprecation}
To just do it for an instance of Javac inside a particular target, do
//[EMAIL PROTECTED]'compile']/javac/@debug = true
I've always been annoyed to having to explicitly declare a bunch of task
attributes taking properties when sensible default values just to be able to
maybe override them.
So in conclusion, I'm +1 to the ability to bind values to task/type
attributes, but without requiring task name changes, and possibly with
requiring a task. I'm -0 to presetdef as it is.
A middle ground would be to have something like this, closer to your current
design:
bind-attributes
delete quiet=true /
javac debug=${debug} deprecation=${deprecation} /
exec failonerror=true /
/bind-attributes
So it yields no task rename, work for any valid tasks, and is more explicit.
macrodef
this defines a new task in the same way as scriptdef except it
uses a sequential as a defintion of the task. The macrodef
task has nested elements - param and element to allow the
user to specify attributes and elements of the new task. These
get substituted into the sequential when the new task is
run.
example: (from a current project)
macrodef name=call-cc
param name=target/
param name=link/
param name=target.dir/
element name=cc-elements/
sequential
mkdir dir=${obj.dir}/${target}/
mkdir dir=${target.dir}/
cc link=${link} objdir=${obj.dir}/${target}
outfile=${target.dir}/${target}
compiler refid=compiler.options/
cc-elements/
/cc
/sequential
/macrodef
macrodef name=compile-exec
param name=program/
element name=cc-files/
sequential
call-cc target=${program} link=executable
target.dir=${build.bin.dir}
cc-elements
includepath location=${gen.dir}/
includepath location=test/
cc-files/
linker refid=linker-libs/
/cc-elements
/call-cc
/sequential
/macrodef
compile-exec program=unittests
cc-files
fileset dir=test/unittest includes = **/*.cpp/
fileset dir=${gen.dir} includes = *.cpp/
/cc-files
/compile-exec
macrodef I have much less problem with, but I concur with others that
overloading the behavior of ${name} is not good. This will be confusing to
me and other users that property expansion will not happen as usual at
definition time, but later on. I think we need another syntax for the macro
param/attributes, and keep the ${} working as usual.
I propose to use either:
* the XSL syntax (@name)
* or a Javadoc-like syntax [EMAIL PROTECTED] name}
Another advantage of the second form is that one would not need to
pre-declare the macro params (making it scripting-language-like), but on the
other hand, pre-declaring makes it more explicitly when reading the macro
what parameters it takes. If we force pre-declaration, we can then fail on
dereference to non-declared macro-param.
Should param be renamed attribute? macrodef, from the build writer point
of view, creates a new tasks, and we always speak of attributes and nested
elements, not params and nesting elements.
I'm -1 to macrodef if it keep the ${...} expansion form for
params/attributes.
I'm +1 to macrodef using nested attributes and elements, with (@name)
expansion.
Will I place these
cvs commit: ant/xdocs external.xml
bodewig 2003/08/14 07:29:47 Modified:docs external.html xdocsexternal.xml Log: Update AntRunner info, submitted by Dirk Schnelle Revision ChangesPath 1.131 +4 -3 ant/docs/external.html Index: external.html === RCS file: /home/cvs/ant/docs/external.html,v retrieving revision 1.130 retrieving revision 1.131 diff -u -r1.130 -r1.131 --- external.html 6 Aug 2003 11:56:57 - 1.130 +++ external.html 14 Aug 2003 14:29:47 - 1.131 @@ -3518,7 +3518,8 @@ a name=AntRunner/a AntRunner /h4 -pAn OpenTool that integrates Ant into the JBuilder IDE./p +pAn OpenTool that integrates Ant into the JBuilder IDE +(version 5 and later)./p table class=externals cellspacing=1 cellpadding=4 tr th colspan=1 rowspan=1 @@ -3527,7 +3528,7 @@ /th td colspan=1 rowspan=1 valign=top align=left - Ant 1.2 and 1.3 + Ant 1.2 and later /td /tr tr @@ -3547,7 +3548,7 @@ /th td colspan=1 rowspan=1 valign=top align=left - a href=mailto:[EMAIL PROTECTED]Dieter Bogdoll/a + a href=mailto:[EMAIL PROTECTED]Dirk Schnelle/a /td /tr tr 1.95 +4 -3 ant/xdocs/external.xml Index: external.xml === RCS file: /home/cvs/ant/xdocs/external.xml,v retrieving revision 1.94 retrieving revision 1.95 diff -u -r1.94 -r1.95 --- external.xml 6 Aug 2003 11:56:57 - 1.94 +++ external.xml 14 Aug 2003 14:29:47 - 1.95 @@ -1871,12 +1871,13 @@ subsection name=AntRunner -pAn OpenTool that integrates Ant into the JBuilder IDE./p +pAn OpenTool that integrates Ant into the JBuilder IDE +(version 5 and later)./p table class=externals tr thCompatibility:/th -tdAnt 1.2 and 1.3/td +tdAnt 1.2 and later/td /tr tr thURL:/th @@ -1884,7 +1885,7 @@ /tr tr thContact:/th -tda href=mailto:[EMAIL PROTECTED]Dieter Bogdoll/a/td +tda href=mailto:[EMAIL PROTECTED]Dirk Schnelle/a/td /tr tr thLicense:/th - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/docs/manual/CoreTasks javac.html
bodewig 2003/08/14 07:37:07 Modified:docs/manual/CoreTasks javac.html Log: Record default for javac's verbose attribute, submitted by Larry Shatzer Revision ChangesPath 1.41 +2 -1 ant/docs/manual/CoreTasks/javac.html Index: javac.html === RCS file: /home/cvs/ant/docs/manual/CoreTasks/javac.html,v retrieving revision 1.40 retrieving revision 1.41 diff -u -r1.40 -r1.41 --- javac.html15 May 2003 12:44:00 - 1.40 +++ javac.html14 Aug 2003 14:37:07 - 1.41 @@ -243,7 +243,8 @@ /tr tr td valign=topverbose/td -td valign=topAsks the compiler for verbose output./td +td valign=topAsks the compiler for verbose output; defaults to + codeno/code./td td align=center valign=topNo/td /tr tr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21436] - [PATCH] Docs for ImportTask
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=21436. 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=21436 [PATCH] Docs for ImportTask [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/etc/testcases/taskdefs/optional/net ftp.xml
I have just done some changes to the ftp task because I realized that the
task was not really supporting symbolic links, only the FTPDirectoryScanner
did.
There is a small problem :
ftp action=get
server=${ftp.host}
userid=${ftp.user}
password=${ftp.password}
remotedir=${tmp.dir}
fileset dir=foo/bar includes=**/*.java /
/ftp
used not to follow symbolic links (in ant 1.5.3 and before)
now, it will follow symbolic links because the default for filesets is to
follow symbolic links.
Is this OK or do I need to change this and how ?
the only possibility I see is to add a flag in AbstractFileSet to find out
whether followsymlinks has been *** explicitly *** set.
Makes the code fatter but would maintain compatibility of behavior between
ant 1.5.3 and ant 1.6
Or can we say that the non following of symbolic links by the ftp task was a
bug, and that the users who do not want to fetch the symbolic links can
alter their build files and set followsymlinks=false in their fileset
definitions ?
Cheers,
Antoine
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, August 14, 2003 4:47 PM
Subject: cvs commit: ant/src/etc/testcases/taskdefs/optional/net ftp.xml
antoine 2003/08/14 07:47:54
Modified:src/main/org/apache/tools/ant/types AbstractFileSet.java
src/main/org/apache/tools/ant/taskdefs/optional/net
FTP.java
src/testcases/org/apache/tools/ant/taskdefs/optional/net
FTPTest.java
src/etc/testcases/taskdefs/optional/net ftp.xml
Log:
Go on working on the followsymlinks support in the FTP task.
The scanner was working previously, but the retrieving of links was not
working
because the followsymlinks attribute was not passed through.
Revision ChangesPath
1.26 +15 -0
ant/src/main/org/apache/tools/ant/types/AbstractFileSet.java
Index: AbstractFileSet.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/types/AbstractFileSet.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- AbstractFileSet.java 13 Aug 2003 15:14:31 - 1.25
+++ AbstractFileSet.java 14 Aug 2003 14:47:54 - 1.26
@@ -330,6 +330,21 @@
}
/**
+ * find out if the fileset wants to follow symbolic links
+ *
+ * @return flag indicating whether or not symbolic links should be
followed
+ *
+ * @since ant 1.6
+ */
+public boolean isFollowSymlinks() {
+if (isReference()) {
+return getRef(getProject()).isFollowSymlinks();
+} else {
+return followSymlinks;
+}
+}
+
+/**
* sets the name used for this datatype instance.
*/
protected String getDataTypeName() {
1.47 +2 -2
ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java
Index: FTP.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- FTP.java 14 Aug 2003 11:37:36 - 1.46
+++ FTP.java 14 Aug 2003 14:47:54 - 1.47
@@ -248,7 +248,6 @@
ftp.changeToParentDirectory();
return;
}
-
for (int i = 0; i newfiles.length; i++) {
FTPFile file = newfiles[i];
if (!file.getName().equals(.)
@@ -662,7 +661,7 @@
*/
protected int transferFiles(FTPClient ftp, FileSet fs)
throws IOException, BuildException {
-FileScanner ds;
+DirectoryScanner ds;
if (action == SEND_FILES) {
ds = fs.getDirectoryScanner(getProject());
@@ -674,6 +673,7 @@
}
ds = new FTPDirectoryScanner(ftp);
fs.setupDirectoryScanner(ds, getProject());
+ds.setFollowSymlinks(fs.isFollowSymlinks());
ds.scan();
}
1.6 +34 -0
ant/src/testcases/org/apache/tools/ant/taskdefs/optional/net/FTPTest.java
Index: FTPTest.java
===
RCS file:
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/optional/net/FTPTe
st.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- FTPTest.java 6 Aug 2003 12:24:42 - 1.5
+++ FTPTest.java 14 Aug 2003 14:47:54 - 1.6
@@ -226,6 +226,40 @@
dsSource.scan();
compareFiles(dsSource, sortedDestinationFiles,
sortedDestinationDirectories);
}
+public void testGetFollowSymlinksTrue() {
+if (!supportsSymlinks) {
DO NOT REPLY [Bug 21526] - Enhancement JavaCC, JJTree and JJDoc [update]
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=21526. 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=21526 Enhancement JavaCC, JJTree and JJDoc [update] [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 15:04 --- OK, patches are in. One note though. You don't need to set -OUTPUT-DIR if the user doesn't set one as you could always invoke Execute#setDir with the basedir before running jjtree. This would ensure that current working directory (for jjtree) and the project's basedir are the same. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/etc/testcases/taskdefs/optional/net ftp.xml
On Thu, 14 Aug 2003, Antoine Levy-Lambert [EMAIL PROTECTED]
wrote:
There is a small problem :
ftp action=get
server=${ftp.host}
userid=${ftp.user}
password=${ftp.password}
remotedir=${tmp.dir}
fileset dir=foo/bar includes=**/*.java /
/ftp
used not to follow symbolic links (in ant 1.5.3 and before)
symlinks on the remote side?
now, it will follow symbolic links because the default for filesets
is to follow symbolic links.
Is this OK
Not sure.
the only possibility I see is to add a flag in AbstractFileSet to
find out whether followsymlinks has been *** explicitly *** set.
Makes the code fatter but would maintain compatibility of behavior
between ant 1.5.3 and ant 1.6
An alternative (although a hacky one) invoke setFollowSymlinks with
false in FTP#addFileset(). As it is addXYZ and not addConfiguredXYZ
any explicitly set attribute would override it (as the attributes will
get set after the invocation of add). Hmm, wait, you only want to
change the followsymlinks attribute if the fileset is a remote one,
right? You probably don't know that by the time addFileset gets
invoked.
Or can we say that the non following of symbolic links by the ftp
task was a bug,
+0, I'm not really sure and I don't really know what the expected
behavior would be. I'd probably expect put and get to behave the same
way, so the 1.5.x behavior would be wrong.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] namespace and antlib
On Tue, 12 Aug 2003, peter reilly [EMAIL PROTECTED] wrote: Users are allowed to use antlib:*. The restricted uri's are uris that users are not allowed to use in typedef/. Does that as a corrolary mean users can't override built-in tasks. It seems a bit wierd to say you must not use uri=ant:* and make ant:core its default value. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] namespace and antlib
On Wed, 13 Aug 2003, Costin Manolache [EMAIL PROTECTED] wrote: All this overriding may create some bad maintaince problems. I agree for overriding in arbitrary namespaces, but we have to keep supporting it for the default namespace. We've added support for task overloading when Ant added a task with the name manifest and FOP's build broke as they had a manifest task of their own. Without overriding, each new task in Ant could potentially break build files. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22243] - Changes in JavaCC 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=22243. 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=22243 Changes in JavaCC task [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 15:22 --- Ant's CVS even supports JavaCC 3.1 since about five weeks. *** This bug has been marked as a duplicate of 18664 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18664] - Patch JavaCC/JJTree version changes 3.0 vs 2.1
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=18664. 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=18664 Patch JavaCC/JJTree version changes 3.0 vs 2.1 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 15:22 --- *** Bug 22243 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/etc/testcases/taskdefs/optional/net ftp.xml
Stefan Bodewig wrote
There is a small problem :
ftp action=get
server=${ftp.host}
userid=${ftp.user}
password=${ftp.password}
remotedir=${tmp.dir}
fileset dir=foo/bar includes=**/*.java /
/ftp
used not to follow symbolic links (in ant 1.5.3 and before)
symlinks on the remote side?
now, it will follow symbolic links because the default for filesets
is to follow symbolic links.
Is this OK
Not sure.
the only possibility I see is to add a flag in AbstractFileSet to
find out whether followsymlinks has been *** explicitly *** set.
Makes the code fatter but would maintain compatibility of behavior
between ant 1.5.3 and ant 1.6
An alternative (although a hacky one) invoke setFollowSymlinks with
false in FTP#addFileset(). As it is addXYZ and not addConfiguredXYZ
any explicitly set attribute would override it (as the attributes will
get set after the invocation of add). Hmm, wait, you only want to
change the followsymlinks attribute if the fileset is a remote one,
right? You probably don't know that by the time addFileset gets
invoked.
yes, the followsymlinks problem concerns the cases where the fileset is
remote, so all actions other than put.
Or can we say that the non following of symbolic links by the ftp
task was a bug,
+0, I'm not really sure and I don't really know what the expected
behavior would be. I'd probably expect put and get to behave the same
way, so the 1.5.x behavior would be wrong.
I am going to write in WHATSNEW under the section changes that can break
existing environments :
ftp task : followsymlinks=false in nested fileset definitions is
explicitly required in order to exclude symbolic links.
Cheers,
Antoine
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22323] - Problem with Copy when todir has a space in it
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=22323. 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=22323 Problem with Copy when todir has a space in it --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 15:23 --- What exactly is the problem? Seems to work fine for me. Which OS are you using? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22244] - Javadoc Task.. Don't use the JAVADOC exceutable from running VM
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=22244. 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=22244 Javadoc Task.. Don't use the JAVADOC exceutable from running VM [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 15:39 --- Currently it is hardcoded to use the javadoc executable of the VM Ant is running in. The easy fix would be to simply add an executable attribute to the task and you'd supply the full path of the executable you want to run. Unfortunately things are not that easy as this tasks has tons of conditional code that adds or not adds attributes based on the javadoc version it is going to run - and all these conditionals use the current VM to determine which arguments to support. In your case, you wouldn't be able to use -1.1 for example as Ant would say Javadoc 1.4 doesn't support the -1.1 switch anymore - even though you intend to use a 1.3 version of javadoc. I don't say it's not doable, but a bit more tricky than it seems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22427] New: - javac task to compile files independently
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=22427. 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=22427 javac task to compile files independently Summary: javac task to compile files independently Product: Ant Version: 1.5.3 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Problem description: I have a lot of .java files in src/ directory and they form a logical groups which I would like to compile separately. Of course I could move the files into group1/src, group2/src, but that would mean that I loose CVS history of each file (we have horrible relation with our CVS server maintainer). That is why I decided to convince javac to compile the files separatelly even the sources share the same root. Surprisingly it is possible - one just does not specify -sourcepath, only names all the files to compile with full name and javac does not try to search for files not explicitly enumerated as arguments. I have tried to do the same with Ant javac task, but it seems there is no way to *not* specify the sourcepath and just enumerate the files (I understand, there would be no way to check whether the files are already compiled or not). Let say that I would like to do something like this: !-- compile group1 -- javac destdir=group1/dest include name=src/org/group1/**/*.java / /javac !-- compile group2 -- javac destdir=group2/dest include name=src/org/group2/**/*.java / /javac and be sure that if by a chance file in group2 references file in group1 that the second compilation fails. Request: I would like the javac task to allow compilation without specifying the sourcepath. Then the above described behaviour of javac could be used and my separation could work. Workaround: Actually there is a workaround of this problem. But it relies on the srcdirnote: http://ant.apache.org/manual/CoreTasks/javac.html#srcdirnote and I am affraid it could be broken with future version of ant. The trick is based on specification of wrong sourcepath (src/org instead of src) and then moving the compiled classes at right location. See it at: http://www.netbeans.org/source/browse/openide/build.xml.diff?r1=1.148.4.16r2=1.148.4.17 I would be glad if we could remove this hack in some version of ant with improved javac. Regards. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
antoine 2003/08/14 08:47:37
Modified:src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
Log:
mistake found ... oops ... corrected
Revision ChangesPath
1.48 +1 -1
ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java
Index: FTP.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- FTP.java 14 Aug 2003 14:47:54 - 1.47
+++ FTP.java 14 Aug 2003 15:47:37 - 1.48
@@ -291,7 +291,7 @@
} else {
String name = vpath + file.getName();
if (!isFollowSymlinks()
file.isSymbolicLink()) {
-dirsExcluded.addElement(name);
+filesExcluded.addElement(name);
} else if (isFunctioningAsFile(ftp, dir, file)) {
if (isIncluded(name)) {
if (!isExcluded(name)) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22428] New: - PATCH - option to run tasks in a loop
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=22428. 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=22428 PATCH - option to run tasks in a loop Summary: PATCH - option to run tasks in a loop Product: Ant Version: 1.5.4 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I'm submitting a quick patch that enable ant to run in a loop mode (through the parameter -loop). In this mode, once the tasks are finished, ant will wait for the user to press Enter to run the tasks again or q to quit. This is pretty useful in situations where a task must be performed many times in a short period of time - like redeploying modified JSP pages to a web container. Usually the task itself is almost instantaneous, but it takes about 5-6 seconds using the regular ant - this overhead is caused mostly by the JVM invocation. With this patch, the new tasks are executed pretty fast, asshown below: ant -loop copy_web_oc4j Buildfile: build.xml copy_web_oc4j: [copy] Copying 1 file to /home/felipeal/eInquiry/build/deploy/oc4j/CSNAPP BUILD SUCCESSFUL Total time: 2 seconds // first evocation, took 2 seconds Press Enter to continue or q + Enter to quit copy_web_oc4j: [copy] Copying 1 file to /home/felipeal/eInquiry/build/deploy/oc4j/CSNAPP BUILD SUCCESSFUL Total time: 0 seconds // sub-sequent iterations: 0 seconds Press Enter to continue or q + Enter to quit I'm submitting 2 patches: 1 for ant 1.5.4 and other for the main branch, but I couldn't test the 2nd one - my guess is that the main build is broken at the moment... Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22428] - PATCH - option to run tasks in a loop
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=22428. 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=22428 PATCH - option to run tasks in a loop --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 15:52 --- Created an attachment (id=7822) Path for ant-1.5.4 (latest stable release) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22428] - PATCH - option to run tasks in a loop
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=22428. 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=22428 PATCH - option to run tasks in a loop --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 15:53 --- Created an attachment (id=7823) Path for main branch on CVS (not tested, as build is broken) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22427] - javac task to compile files independently
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=22427. 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=22427 javac task to compile files independently --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 15:54 --- Whaooo, I *strongly* support this request!!! I never realized one could actually *not* specify the sourcepath. I developped a complex XSL based system to compile groups of files in a single src/ directory to keep circular dependencies between the groups in check, and could completely scrap it and replace it with simple javacs would this enhancement make it thru. This ability to compile only a subset of files from a source tree without Javac automatically finding the dependent source files in the same tree would be tremendously useful IMHO!!! --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22428] - PATCH - option to run tasks inside a loop
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=22428. 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=22428 PATCH - option to run tasks inside a loop [EMAIL PROTECTED] changed: What|Removed |Added Summary|PATCH - option to run tasks |PATCH - option to run tasks |in a loop |inside a loop --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 15:54 --- (changed description) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22427] - javac task to compile files independently
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=22427. 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=22427 javac task to compile files independently [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Target Milestone|--- |1.5.2 Version|1.5.3 |1.4.1 --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:03 --- javac sourcepath=/ should do (Thu Feb 14 17:34:19 2002 UTC ;-) *** This bug has been marked as a duplicate of 5268 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5268] - Should allow execution of javac with no sourcepath set
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=5268. 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=5268 Should allow execution of javac with no sourcepath set [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:03 --- *** Bug 22427 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22417] - add an owner, group, and umask to the war 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=22417. 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=22417 add an owner, group, and umask to the war task [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:07 --- Use chmod - and with CVS HEAD of Ant chown and chgrp to do what you need. We already have tasks that do that, no need to add it to war as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22088] - Patch for MailMessage.java
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=22088. 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=22088 Patch for MailMessage.java [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:08 --- I am going to work on this issue. Michael, you did not answer the question : in ant1.6alpha, a charset attribute has been introduced for the emailtask and the message nested element. Is there overlapping / complementarity between charset and encoding ? The charset attribute is supported by the JavaMail based implementation of the mail task. If your new attribute is the same (for plain mail) then it should also be called charset ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22370] - enhance available to test for owner, group and permissions - security feature
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=22370. 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=22370 enhance available to test for owner, group and permissions - security feature --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:11 --- What Steve tried to say - there is no way to do what you want without either (1) using native code or (2) parse the output of an external executable like ls -l The later is not without precedent as we do something similar to access environment variables. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
On Thursday 14 August 2003 15:23, Dominique Devienne wrote:
After all the praises, I hope my post doesn't sound too negative.
No problem.
I also
think it's a great addition Peter, I just have a few reservations ;-)
See below... --DD
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
presetdef (formally known as extendtype)
this defines a new task or type based on a current ant task or type,
with attributes or elements preset.
example useage:
presetdef name=my.javac
javac debug=${debug} deprecation=${deprecation}/
/presetdef
my.javac may now be used as a task in the same way as javac
but the attribute debug and deprecation will be preset.
I'll start by neat picking ;-) What presetdef does is binding a given
value to a task attribute. In the C++ world, the method to do that are call
bind, which is IMHO better that preset.
presetdef/ also allows nested elements to be predefined - or bound.
Also, this kind of static attribute-binding is useful indeed (I've actually
asked for it a few times), but is hardly a definition, and it's bad that it
forces you to rewrite the task name. I don't want to modify all my builds
to use my.javac just to take advantage of that feature.
Finally, presetdef, in term of functionality and not implementation, is
just a subset of macrodef in my opinion, and doesn't deserve Task status.
It is not a sub-set of macrodef/. But there is a lot of overlap of
functionality. In fact after I got embeded elements to work for macrodef/,
I replaced most uses of presetdef/ with macrodef/.
I think however that there is a place for presetdef/ For example
if you look at the current code of TaskDef, all it consists of is
setting two properties. This can be expressed using presetdef/ as
presetdef name=taskdef
typedef adaptor=org.apache.tools.ant.task.TaskAdaptor
adaptto=org.apache.tools.ant.task.Task/
/presetdef
When (if) roles are introducted, one implementation would be
to add a role or restrict attribute to typedef.
typedef name=or
classname=org.apache.tools.ant.taskdefs.conditions.Or
restrict=org.apache.tools.ant.taskdefs.conditions.Condition/
typedef name=or
classname=org.apache.tools.ant.types.selectors.Or
restrict=org.apache.tools.ant.types.selectors.FileSelector/
one could use presetdef/ as
presetdef name=conditiondef
typedef
restrict=org.apache.tools.ant.taskdefs.conditions.Condition/
/presetdef
and define:
conditiondef name=or
classname=org.apache.tools.ant.taskdefs.conditions.Or/
Much more useful IMO was be the ability to bind (or preset) values using
XPath expressions, to follow your example:
//javac/@debug = ${debug}
//javac/@deprecation = ${deprecation}
To just do it for an instance of Javac inside a particular target, do
//[EMAIL PROTECTED]'compile']/javac/@debug = true
I've always been annoyed to having to explicitly declare a bunch of task
attributes taking properties when sensible default values just to be able
to maybe override them.
So in conclusion, I'm +1 to the ability to bind values to task/type
attributes, but without requiring task name changes, and possibly with
requiring a task. I'm -0 to presetdef as it is.
A middle ground would be to have something like this, closer to your
current design:
bind-attributes
delete quiet=true /
javac debug=${debug} deprecation=${deprecation} /
exec failonerror=true /
/bind-attributes
So it yields no task rename, work for any valid tasks, and is more
explicit.
True but not easy to implement (I think, although.) and does
something different to presetdef/.
macrodef
/compile-exec
macrodef I have much less problem with, but I concur with others that
overloading the behavior of ${name} is not good. This will be confusing to
me and other users that property expansion will not happen as usual at
definition time, but later on.
All of the expansions happen later on. If the macro is used in a different
project to the project it is defined in, the properties in use will be of
the project that the macro is used in*. However, I can see
that there can be issues with using the same notation for the macro
expansion of attributes and then normal expansion of properties.
I am loath however to adding new rules for indicating variables.
However if ant people want a different encoded for the macro variables,
I would have no objection.
* This is different to expandtype where the project of the definer
is used to evaluate the preset attributes and elements.
This is a reason I called the second task macrodef/, one
should consider it a lump of xml to be placed in at the current
location with substitutions of attributes and elements.
I think we need another syntax for the macro
param/attributes, and keep the ${} working as usual.
I propose to use either:
* the XSL syntax
cvs commit: ant/xdocs faq.xml
bodewig 2003/08/14 09:16:21 Modified:docs faq.html xdocsfaq.xml Log: Avoid useless use of cat award by using a real world example. Revision ChangesPath 1.76 +10 -9 ant/docs/faq.html Index: faq.html === RCS file: /home/cvs/ant/docs/faq.html,v retrieving revision 1.75 retrieving revision 1.76 diff -u -r1.75 -r1.76 --- faq.html 13 Aug 2003 06:11:58 - 1.75 +++ faq.html 14 Aug 2003 16:16:20 - 1.76 @@ -673,26 +673,27 @@ How do I redirect standard input or standard output in the codelt;execgt;/code task? /p - pSay you want to redirect the standard input stream of the -codecat/code command to read from a file, something + pSay you want to redirect the standard output stream of the +codem4/code command to write to a file, something like:/p pre class=code -shell-promptgt; cat lt; foo +shell-promptgt; m4 foo.m4 gt; foo /pre pand try to translate it into/p pre class=code -lt;exec executable=quot;catquot;gt; - lt;arg value=quot;amp;lt;quot; /gt; - lt;arg value=quot;fooquot; /gt; +lt;exec executable=quot;m4quot;gt; + lt;arg value=quot;foo.m4quot;/gt; + lt;arg value=quot;amp;gt;quot;/gt; + lt;arg value=quot;fooquot;/gt; lt;/execgt; /pre -pThis will not do what you expect. The input redirection is +pThis will not do what you expect. The output redirection is performed by your shell, not the command itself, so this should read:/p pre class=code lt;exec executable=quot;/bin/shquot;gt; lt;arg value=quot;-cquot; /gt; - lt;arg value=quot;cat amp;lt; fooquot; /gt; + lt;arg value=quot;m4 foo.m4 amp;gt; fooquot; /gt; lt;/execgt; /pre pNote that you must use the codevalue/code attribute of @@ -701,7 +702,7 @@ you can use:/p pre class=code lt;exec executable=quot;/bin/shquot;gt; - lt;arg line='-c quot;cat amp;lt; fooquot;'/gt; + lt;arg line='-c quot;m4 foo.m4 amp;gt; fooquot;'/gt; lt;/execgt; /pre pNote the double-quotes nested inside the single-quotes./p 1.37 +10 -9 ant/xdocs/faq.xml Index: faq.xml === RCS file: /home/cvs/ant/xdocs/faq.xml,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- faq.xml 13 Aug 2003 06:11:58 - 1.36 +++ faq.xml 14 Aug 2003 16:16:21 - 1.37 @@ -313,31 +313,32 @@ questionHow do I redirect standard input or standard output in the codelt;execgt;/code task?/question answer -pSay you want to redirect the standard input stream of the -codecat/code command to read from a file, something +pSay you want to redirect the standard output stream of the +codem4/code command to write to a file, something like:/p source![CDATA[ -shell-prompt cat foo +shell-prompt m4 foo.m4 foo ]]/source pand try to translate it into/p source![CDATA[ -exec executable=cat - arg value=lt; / - arg value=foo / +exec executable=m4 + arg value=foo.m4/ + arg value=gt;/ + arg value=foo/ /exec ]]/source -pThis will not do what you expect. The input redirection is +pThis will not do what you expect. The output redirection is performed by your shell, not the command itself, so this should read:/p source![CDATA[ exec executable=/bin/sh arg value=-c / - arg value=cat lt; foo / + arg value=m4 foo.m4 gt; foo / /exec ]]/source @@ -347,7 +348,7 @@ you can use:/p source![CDATA[ exec executable=/bin/sh - arg line='-c cat lt; foo'/ + arg line='-c m4 foo.m4 gt; foo'/ /exec ]]/source - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22315] - cat foo is questionable example of redirection
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=22315. 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=22315 cat foo is questionable example of redirection [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:19 --- Now uses m4 as example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22361] - Copy with glob mapper maps AND copies originals
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=22361. 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=22361 Copy with glob mapper maps AND copies originals [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:25 --- You were right -- sorry. There was another copy elsewhere that picked up those files with a **/* and incorrect excludes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22088] - Patch for MailMessage.java
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=22088. 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=22088 Patch for MailMessage.java --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:26 --- Sorry, let me be more precise. The new attribute does perform the same function, but for MailMessage (and therefore for PlainMailer and UUMailer). It may be perferable to change the attribute name to charset from encoding (Java calls it encoding). If you prefer not to manually change the attirbute name after the patch is applied and before committing, I would be happy to submit a replacement patch with 'charset' as the attribute name instead of 'encoding'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/types Path.java
bodewig 2003/08/14 09:25:52
Modified:src/main/org/apache/tools/ant/types Path.java
Log:
Newer versions of Kaffe have a filesystem layout similar to Sun's VMs,
don't exclude rt.jar and friends.
PR: 22297
Revision ChangesPath
1.57 +14 -8 ant/src/main/org/apache/tools/ant/types/Path.java
Index: Path.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/types/Path.java,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -r1.56 -r1.57
--- Path.java 13 Aug 2003 15:14:31 - 1.56
+++ Path.java 14 Aug 2003 16:25:52 - 1.57
@@ -603,6 +603,20 @@
* Add the Java Runtime classes to this Path instance.
*/
public void addJavaRuntime() {
+if (Kaffe.equals(System.getProperty(java.vm.name))) {
+// newer versions of Kaffe (1.1.1+) won't have this,
+// but this will be sorted by FileSet anyway.
+File kaffeShare = new File(System.getProperty(java.home)
+ + File.separator + share
+ + File.separator + kaffe);
+if (kaffeShare.isDirectory()) {
+FileSet kaffeJarFiles = new FileSet();
+kaffeJarFiles.setDir(kaffeShare);
+kaffeJarFiles.setIncludes(*.jar);
+addFileset(kaffeJarFiles);
+}
+}
+
if
(System.getProperty(java.vendor).toLowerCase(Locale.US).indexOf(microsoft)
= 0) {
// Pull in *.zip from packages directory
FileSet msZipFiles = new FileSet();
@@ -610,14 +624,6 @@
+ File.separator + Packages));
msZipFiles.setIncludes(*.ZIP);
addFileset(msZipFiles);
-} else if (Kaffe.equals(System.getProperty(java.vm.name))) {
-FileSet kaffeJarFiles = new FileSet();
-kaffeJarFiles.setDir(new File(System.getProperty(java.home)
- + File.separator + share
- + File.separator + kaffe));
-
-kaffeJarFiles.setIncludes(*.jar);
-addFileset(kaffeJarFiles);
} else if (JavaEnvUtils.isJavaVersion(JavaEnvUtils.JAVA_1_1)) {
addExisting(new Path(null,
System.getProperty(java.home)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22297] - Patch for new version of Kaffe
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=22297. 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=22297 Patch for new version of Kaffe [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:28 --- According to Dalibor Topic Kaffe used to be able to run Ant, let's try to keep it that way, even if chances are slim that anybody would want to do that (i.e. run a brand new version of Ant on an old Kaffe installation). I've committed a version that should work for older and newer versions of Kaffe. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22370] - enhance available to test for owner, group and permissions - security feature
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=22370. 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=22370 enhance available to test for owner, group and permissions - security feature --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:29 --- well, to be precise, I was implying without third party native code. I am sure that java.io goes native at some point, it merely does so without providing any access to any permission bits other than readonly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] namespace and antlib
On Thursday 14 August 2003 16:13, Stefan Bodewig wrote: On Tue, 12 Aug 2003, peter reilly [EMAIL PROTECTED] wrote: Users are allowed to use antlib:*. The restricted uri's are uris that users are not allowed to use in typedef/. Does that as a corrolary mean users can't override built-in tasks. It seems a bit wierd to say you must not use uri=ant:* and make ant:core its default value. Is true, but I did not say that (I think). I said that they cannot use ant:* except for ant:core. The history is that I wanted to only allow users to have definitions in antlib:* or ant:core, but some (ok most) people wanted to have arbitarty uris. So the core now allows this except for ant:* minus ant:core. Where ant:* is reserved for future use by ant. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: RE: beating the dead Ant 1.6 horse
---BeginMessage---
...Hi, I kind of hear, that you are discussing, what kind of appears to be
in the domain of taskdef and its classpath-attribute and how classes are
loaded? Am I wrong here?
I have some examples with what could be called local
classpath/classloader-use - I can make it work with the somewhat complex
Jegustator - had a chat with the author - but not with JDepend, which
requires global modification of ${ant.home}/lib...
Something one of you care to discuss? -See two examples of mine?
Does some kind of textual explanation of classloading in Ant X.X.X/Ant 1.6
exist?
Regards,
Morten Sabroe Mortensen
-Original Message-
From: peter reilly
To: Ant Developers List
Sent: 14-08-03 10:36
Subject: Re: beating the dead Ant 1.6 horse
On Thursday 14 August 2003 06:38, Costin Manolache wrote:
Conor MacNeill wrote:
The others are antlib/namespace/polymorph stuff. I'm wondering if we
can
get to the point where the ant optional tasks are packaged as
antlibs and
potentially not added to the root loader if their supporting
libraries
are not also available to the root loader. This would allow them to
be
taskdef'd in later in a build.
What's the status on that ? Any decision on how to deal with the
loaders ?
I'll have some time next week, I wanted to finish the classloader task
- is
it still usefull ?
Most definitely.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---End Message---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22088] - Patch for MailMessage.java
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=22088. 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=22088 Patch for MailMessage.java --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:35 --- I now have a patch for PlainMailer that will set the character set of MailMessage correctly and I am working on a testcase for EmailTaskTest. I'll attach them to this bug if/when my MailMessage patch is committed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 14, 2003 11:22 AM
To: Ant Developers List
Subject: Re: [new tasks] presetdef and macrodef
It is not a sub-set of macrodef/. But there is a lot of overlap of
functionality. In fact after I got embeded elements to work for
macrodef/,
I replaced most uses of presetdef/ with macrodef/.
I think however that there is a place for presetdef/ For example
if you look at the current code of TaskDef, all it consists of is
setting two properties. This can be expressed using presetdef/ as
presetdef name=taskdef
typedef adaptor=org.apache.tools.ant.task.TaskAdaptor
adaptto=org.apache.tools.ant.task.Task/
/presetdef
When (if) roles are introducted, one implementation would be
to add a role or restrict attribute to typedef.
typedef name=or
classname=org.apache.tools.ant.taskdefs.conditions.Or
restrict=org.apache.tools.ant.taskdefs.conditions.Condition/
typedef name=or
classname=org.apache.tools.ant.types.selectors.Or
restrict=org.apache.tools.ant.types.selectors.FileSelector/
one could use presetdef/ as
presetdef name=conditiondef
typedef
restrict=org.apache.tools.ant.taskdefs.conditions.Condition/
/presetdef
and define:
conditiondef name=or
classname=org.apache.tools.ant.taskdefs.conditions.Or/
OK, I clearly misunderstood presetdef... But then, you can also write:
macrodef name=conditiondef
typedef restrict=org.apache.tools.ant.taskdefs.conditions.Condition/
/macrodef
and still do,
conditiondef name=or
classname=org.apache.tools.ant.taskdefs.conditions.Or/
Can't you? So what's exactly the difference between presetdef and
macrodef??? I still don't get it I'm afraid...
A middle ground would be to have something like this, closer to your
current design:
bind-attributes
delete quiet=true /
javac debug=${debug} deprecation=${deprecation} /
exec failonerror=true /
/bind-attributes
So it yields no task rename, work for any valid tasks, and is more
explicit.
True but not easy to implement (I think, although.) and does
something different to presetdef/.
I thought it was the goal of presetdef, but I was wrong of course.
macrodef
/compile-exec
macrodef I have much less problem with, but I concur with others that
overloading the behavior of ${name} is not good. This will be confusing
to me and other users that property expansion will not happen as usual
at definition time, but later on.
All of the expansions happen later on. If the macro is used in a
different project to the project it is defined in, the properties
in use will be of the project that the macro is used in*.
Which is exactly why I don't like using the same syntax, which until now
*always* expanded as if at the place of definition/use!!!
However, I can see
that there can be issues with using the same notation for the macro
expansion of attributes and then normal expansion of properties.
So we're you planning on refusing 'normal' property expansion in macrodef?
If two different syntax are used, it's obvious what's what.
I am loath however to adding new rules for indicating variables.
However if ant people want a different encoded for the macro variables,
I would have no objection.
OK, let's see:
1) Introduce a new syntax (@name) for a new feature,
thus keeping the existing syntax ${name} its only behavior
2) Overloading the existing ${name} syntax to behave differently
in macrodef
It's a no brainer to me. I clearly vote for (1).
Another advantage of the second form is that one would not need to
pre-declare the macro params (making it scripting-language-like), but on
the other hand, pre-declaring makes it more explicitly when reading the
macro what parameters it takes. If we force pre-declaration, we can then
fail on dereference to non-declared macro-param.
Yes, The current code does these checks.
So how do you distinguish between regular properties dereference and
macrodef attribute dereference again?
Should param be renamed attribute? macrodef, from the build writer
point of view, creates a new tasks, and we always speak of attributes
and nested elements, not params and nesting elements.
I picked param, as some other tasks use param (foreach*,
antcall) for something similar.
No, it's not something similar IMHO! You are implicitly creating a new task
at runtime, whereas foreach and antcall are tasks that use parameters
during their runtime. It's two different things, and again the meaning
should not be overloaded.
Please consider using attribute instead of param, re-enforcing this idea
that macrodef create a new task, as the same time that (@name)
re-enforcement the fact that it's not a regular property dereference.
Thanks, --D
DO NOT REPLY [Bug 22433] New: - Checking out files with a paticular version hangs thru ant
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=22433. 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=22433 Checking out files with a paticular version hangs thru ant Summary: Checking out files with a paticular version hangs thru ant Product: Ant Version: 1.5.3 Platform: All OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I'm trying to checkout a bunch of files each with a different version through ant. It checksout some of them and hangs without any error message. The output is as follows.. [CreateMiniBuild] Output line abc.xsl [CreateMiniBuild] Output line [CreateMiniBuild] Output line The ' characters around the executable and argumen ts are [CreateMiniBuild] Output line not part of the command. [CreateMiniBuild] Output line [CreateMiniBuild] Output line [cvs] - main loop with CVSROOT=/repository /cvsroot/ [CreateMiniBuild] Output line [cvs] - do_module (abc.xsl, Updating, , ) [CreateMiniBuild] Output line [cvs] - rename(CVS/Entries.Backup,CVS/Entr ies) [CreateMiniBuild] Output line [cvs] - unlink_file(CVS/Entries.Log) [CreateMiniBuild] Output line [cvs] - Register(abc.xsl, 1.5, Initial abc.xsl, , 1.5 ) [CreateMiniBuild] Output line [cvs] - rename(CVS/Entries.Backup,CVS/Entr ies) [CreateMiniBuild] Output line [cvs] - unlink_file(CVS/Entries.Log) [CreateMiniBuild] Output line [cvs] - fopen(/repository/cvsroot//CVSROOT /history,a) [CreateMiniBuild] Output line [cvs] - Reader_Lock (/repository/cvsroot/config) [CreateMiniBuild] Output line [cvs] - unlink_file_dir(CVS/,,abc.xsl) [CreateMiniBuild] Output line [cvs] - RCS_checkout (/repository/cvsroot/ config/abc.xsl,v, 1.5, 1.5, , NFRequestEventQuery.xsl) [CreateMiniBuild] Output line [cvs] - chmod(abc.xsl,1006 44) [CreateMiniBuild] Output line [cvs] - Register(abc.xsl, 1.5, Fri Apr 19 22:21:20 2002, , 1.5 ) [CreateMiniBuild] Output line [cvs] - Lock_Cleanup() [CreateMiniBuild] Output line [cvs] - rename(CVS/Entries.Backup,CVS/Entr ies) [CreateMiniBuild] Output line [cvs] - unlink_file(CVS/Entries.Log) [CreateMiniBuild] Output line [cvs] - Lock_Cleanup() [CreateMiniBuild] Output line [cvs] retCode=0 [CreateMiniBuild] Output line [cvs] Executing 'cvs' with arguments: [CreateMiniBuild] Output line [cvs] '-d/repository/cvsroot/' [CreateMiniBuild] Output line [cvs] '-t' [CreateMiniBuild] Output line [cvs] 'co' [CreateMiniBuild] Output line [cvs] '-r' [CreateMiniBuild] Output line [cvs] '1.3' [CreateMiniBuild] Output line [cvs] 'config/data/xyz.xml' [CreateMiniBuild] Output line [cvs] [CreateMiniBuild] Output line [cvs] The ' characters around the executable and arguments are [CreateMiniBuild] Output line [cvs] not part of the command. [CreateMiniBuild] Output line Execute:Java13CommandLauncher: Executing 'cvs' wit h arguments: [CreateMiniBuild] Output line '-d/repository/cvsroot/' [CreateMiniBuild] Output line '-t' [CreateMiniBuild] Output line 'co' [CreateMiniBuild] Output line '-r' [CreateMiniBuild] Output line '1.3' [CreateMiniBuild] Output line 'config/data/xyz.xml' [CreateMiniBuild] Output line [CreateMiniBuild] Output line The ' characters around the executable and argumen ts are [CreateMiniBuild] Output line not part of the command. [CreateMiniBuild] Output line 4935,1Botn It hangs there forever. Any suggestions? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/etc/testcases/taskdefs/optional/net ftp.xml
antoine 2003/08/14 10:23:22
Modified:src/etc/testcases/taskdefs/optional/net ftp.xml
Log:
removed useless property environment=env/
Revision ChangesPath
1.5 +0 -1 ant/src/etc/testcases/taskdefs/optional/net/ftp.xml
Index: ftp.xml
===
RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/optional/net/ftp.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ftp.xml 14 Aug 2003 14:47:54 - 1.4
+++ ftp.xml 14 Aug 2003 17:23:22 - 1.5
@@ -1,6 +1,5 @@
project name=ftp-test basedir=.
property file=../../../../../../ftp.properties/
-property environment=env/
property name=ftp.user value=${user.name}/
property name=ftp.host value=localhost/
property name=ftp.port value=21 /
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [new tasks] presetdef and macrodef
I think this is fantastic work.
As per Dominique's reservations, here are some observations that may
make things easier.
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
From: peter reilly [mailto:[EMAIL PROTECTED]
presetdef (formally known as extendtype)
this defines a new task or type based on a current ant
task or type,
with attributes or elements preset.
example useage:
presetdef name=my.javac
javac debug=${debug} deprecation=${deprecation}/
/presetdef
my.javac may now be used as a task in the same way as javac
but the attribute debug and deprecation will be preset.
Also, this kind of static attribute-binding is useful indeed
(I've actually
asked for it a few times), but is hardly a definition, and
it's bad that it
forces you to rewrite the task name. I don't want to modify
all my builds to
use my.javac just to take advantage of that feature.
One thing you could do here is redefine javac itself
by doing something like:
taskdef name=orig.javac classname=org.ant.Javac/
presetdef name=javac
orig.javac debug=${debug} deprecation=${deprecation}/
/presetdef
which would realize your desired effect. This could be done internally
by presetdef/ when for example no name attribute is given.
Finally, presetdef, in term of functionality and not
implementation, is
just a subset of macrodef in my opinion, and doesn't
deserve Task status.
I disagree here, IIUC, macrodef's templates must have ALL the
content and parameters of the tasks inside, while presetdef/
only sites some sort of default values.
It would be interesting to know what would happen if I write:
my.javac debug=true ... /my.javac
would it use the value given in presetdef or that given in the actual task?
If the later, it means that the values given in presetdef would be
default values for the task, which sounds much better.
Maybe we could rename it defaultdef/. :-)
Much more useful IMO was be the ability to bind (or preset)
values using
XPath expressions, to follow your example:
//javac/@debug = ${debug}
//javac/@deprecation = ${deprecation}
To just do it for an instance of Javac inside a particular target, do
//[EMAIL PROTECTED]'compile']/javac/@debug = true
This sounds like global file transformations, since you are applying
the xpath all over, seems like something for a ProjectHelper like to do.
A middle ground would be to have something like this, closer
to your current
design:
bind-attributes
delete quiet=true /
javac debug=${debug} deprecation=${deprecation} /
exec failonerror=true /
/bind-attributes
So it yields no task rename, work for any valid tasks, and is
more explicit.
More in the middle is something like the notation I proposed above,
which allows the user to decide whether he wants diferent flavours
(different names) or just globally apply the change.
macrodef
this defines a new task in the same way as scriptdef except it
uses a sequential as a defintion of the task. The macrodef
task has nested elements - param and element to allow the
user to specify attributes and elements of the new task. These
get substituted into the sequential when the new task is
run.
example: (from a current project)
macrodef name=call-cc
param name=target/
param name=link/
param name=target.dir/
element name=cc-elements/
sequential
mkdir dir=${obj.dir}/${target}/
mkdir dir=${target.dir}/
cc link=${link} objdir=${obj.dir}/${target}
outfile=${target.dir}/${target}
compiler refid=compiler.options/
cc-elements/
/cc
/sequential
/macrodef
macrodef name=compile-exec
param name=program/
element name=cc-files/
sequential
call-cc target=${program} link=executable
target.dir=${build.bin.dir}
cc-elements
includepath location=${gen.dir}/
includepath location=test/
cc-files/
linker refid=linker-libs/
/cc-elements
/call-cc
/sequential
/macrodef
compile-exec program=unittests
cc-files
fileset dir=test/unittest includes = **/*.cpp/
fileset dir=${gen.dir} includes = *.cpp/
/cc-files
/compile-exec
macrodef I have much less problem with, but I concur with
others that
overloading the behavior of ${name} is not good. This will be
confusing to
me and other users that property expansion will not happen as usual at
definition time, but later on. I think we need another syntax
for the macro
param/attributes, and keep the ${} working as usual.
I really do not see what is so confusing,
RE: [new tasks] presetdef and macrodef
Jose Alberto answered that one indirectly. I know understand that the macrodef I had does not declare a 'name' or 'classname' attribute, and thus could not be used as I wrote it, whereas presetdef keeps access to all attributes of the preset'd type. Sorry for being so slow ;-) --DD -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 11:44 AM To: 'Ant Developers List' Subject: RE: [new tasks] presetdef and macrodef -Original Message- From: peter reilly [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 11:22 AM To: Ant Developers List Subject: Re: [new tasks] presetdef and macrodef It is not a sub-set of macrodef/. But there is a lot of overlap of functionality. In fact after I got embeded elements to work for macrodef/, I replaced most uses of presetdef/ with macrodef/. I think however that there is a place for presetdef/ For example if you look at the current code of TaskDef, all it consists of is setting two properties. This can be expressed using presetdef/ as presetdef name=taskdef typedef adaptor=org.apache.tools.ant.task.TaskAdaptor adaptto=org.apache.tools.ant.task.Task/ /presetdef When (if) roles are introducted, one implementation would be to add a role or restrict attribute to typedef. typedef name=or classname=org.apache.tools.ant.taskdefs.conditions.Or restrict=org.apache.tools.ant.taskdefs.conditions.Condition/ typedef name=or classname=org.apache.tools.ant.types.selectors.Or restrict=org.apache.tools.ant.types.selectors.FileSelector/ one could use presetdef/ as presetdef name=conditiondef typedef restrict=org.apache.tools.ant.taskdefs.conditions.Condition/ /presetdef and define: conditiondef name=or classname=org.apache.tools.ant.taskdefs.conditions.Or/ OK, I clearly misunderstood presetdef... But then, you can also write: macrodef name=conditiondef typedef restrict=org.apache.tools.ant.taskdefs.conditions.Condition/ /macrodef and still do, conditiondef name=or classname=org.apache.tools.ant.taskdefs.conditions.Or/ Can't you? So what's exactly the difference between presetdef and macrodef??? I still don't get it I'm afraid... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
Dominique Devienne wrote, On 14/08/2003 20.16:
Jose Alberto answered that one indirectly. I know understand that the
macrodef I had does not declare a 'name' or 'classname' attribute, and
thus could not be used as I wrote it, whereas presetdef keeps access to
all attributes of the preset'd type. Sorry for being so slow ;-) --DD
While the tasks themselves are wonderful, it's possible that the current
naming can confuse users, and DD is quite a knowledgebale (how the heck
do you write it!?) one.
I'm not a naming wizard (usually quite the opposite), but how about:
presetdef name=my.javac
javac debug=${debug} deprecation=${deprecation}/
/presetdef
becomes
taskdef name=javac
classname=whatever
attribute name=debug value=${debug}/
attribute name=deprecation value=${deprecation}/
/taskdef
or
taskdef name=javac
classname=whatever
template
javac debug=${debug} deprecation=${deprecation}/
/template
/taskdef
or
taskdef name=javac
classname=whatever
defaults
javac debug=${debug} deprecation=${deprecation}/
/defaults
/taskdef
And
macrodef - scriptdef language=ant
scriptdef language=javascript
scriptdef language=ant
or
macrodef - taskdef language=ant
taskdef language=javascript
taskdef language=ant
BTW, any name is fine for me as long as it's put in Ant 1.6 ;-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/docs/manual/OptionalTasks ftp.html
antoine 2003/08/14 14:01:43
Modified:.WHATSNEW
src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
docs/manual/OptionalTasks ftp.html
Log:
Add two new attributes timediffmillis and timediffauto for the ftp task
so that the newer attribute can take into account time differences between
local
machine and remote server.
PR: 19358
Revision ChangesPath
1.484 +5 -0 ant/WHATSNEW
Index: WHATSNEW
===
RCS file: /home/cvs/ant/WHATSNEW,v
retrieving revision 1.483
retrieving revision 1.484
diff -u -r1.483 -r1.484
--- WHATSNEW 14 Aug 2003 15:24:55 - 1.483
+++ WHATSNEW 14 Aug 2003 21:01:43 - 1.484
@@ -265,6 +265,11 @@
* new rmdir action for ftp that removes directories from a fileset.
+* ftp has attributes timediffauto and timediffmillis to use together
+ with the newer attribute to tell ant to take into account a time difference
+ between client and remote side.
+ Bugzilla Report 19358.
+
* The SOS and VSS tasks will no longer unconditionally prepend a $ to
vsspath or projectpath.
1.49 +105 -5
ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java
Index: FTP.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- FTP.java 14 Aug 2003 15:47:37 - 1.48
+++ FTP.java 14 Aug 2003 21:01:43 - 1.49
@@ -71,9 +71,9 @@
import java.util.Vector;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.DirectoryScanner;
-import org.apache.tools.ant.FileScanner;
import org.apache.tools.ant.Project;
import org.apache.tools.ant.Task;
+import org.apache.tools.ant.taskdefs.Delete;
import org.apache.tools.ant.types.EnumeratedAttribute;
import org.apache.tools.ant.types.FileSet;
import org.apache.tools.ant.util.FileUtils;
@@ -128,6 +128,8 @@
private boolean passive = false;
private boolean verbose = false;
private boolean newerOnly = false;
+private long timeDiffMillis = 0;
+private boolean timeDiffAuto = false;
private int action = SEND_FILES;
private Vector filesets = new Vector();
private Vector dirCache = new Vector();
@@ -467,12 +469,42 @@
* A synonym for ttdepends/tt. Set to true to transmit only new
* or changed files.
*
+ * See the related attributes timediffmillis and timediffauto.
+ *
* @param newer if true only transfer newer files.
*/
public void setNewer(boolean newer) {
this.newerOnly = newer;
}
+/**
+ * number of milliseconds to add to the time on the remote machine
+ * to get the time on the local machine.
+ *
+ * use in conjunction with codenewer/code
+ *
+ * @param timeDiffMillis number of milliseconds
+ *
+ * @since ant 1.6
+ */
+public void setTimeDiffMillis(long timeDiffMillis) {
+this.timeDiffMillis = timeDiffMillis;
+}
+
+/**
+ * quot;truequot; to find out automatically the time difference
+ * between local and remote machine.
+ *
+ * This requires right to create
+ * and delete a temporary file in the remote directory.
+ *
+ * @param timeDiffAuto true = find automatically the time diff
+ *
+ * @since ant 1.6
+ */
+public void setTimeDiffAuto(boolean timeDiffAuto) {
+this.timeDiffAuto = timeDiffAuto;
+}
/**
* Set to true to preserve modification times for gotten files.
@@ -862,8 +894,71 @@
ftp.changeWorkingDirectory(cwd);
}
}
-
-
+/**
+ * auto find the time difference between local and remote
+ * @param ftp handle to ftp client
+ * @return number of millis to add to remote time to make it comparable
to local time
+ * @since ant 1.6
+ */
+private long getTimeDiff(FTPClient ftp) {
+long returnValue = 0;
+File tempFile = findFileName(ftp);
+try {
+// create a local temporary file
+fileUtils.createNewFile(tempFile);
+long localTimeStamp = tempFile.lastModified();
+BufferedInputStream instream = new BufferedInputStream(new
FileInputStream(tempFile));
+ftp.storeFile(tempFile.getName(), instream);
+instream.close();
+boolean success =
FTPReply.isPositiveCompletion(ftp.getReplyCode());
+if (success) {
+FTPFile [] ftpFiles = ftp.listFiles(tempFile.getName());
+if (ftpFiles.length == 1) {
+long remoteTimeStamp
DO NOT REPLY [Bug 19358] - Add timezone to FTP
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=19358. 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=19358 Add timezone to FTP [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 21:05 --- OK. I have prepared an implementation of this report. There are 2 new attributes, timeDiffAuto and timeDiffMillis If you set timeDiffAuto to true, the ant ftp task will automatically find out the time difference between local and remote. timeDiffMillis is the number of milliseconds of time difference. timeDiffAuto is better (except if the time difference has changed and you know for a fact that you want to use another time difference than the current - or if you do not have write access to the remote directory. You will be able to download the nightly build 2003-07-15 or later from http: //cvs.apache.org/builds/ant/nightly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
