DO NOT REPLY [Bug 20014] - Ability to collect properties into one TASK/reference to load into 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=20014. 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=20014 Ability to collect properties into one TASK/reference to load into Java [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-05-19 06:32 --- Pick up a recent nightly build. It contains a new data-type named propertyset and java supports a nested syspropertyset that can take a reference to an existing set.
Re: antlib / proposal of Peter Reilly
Hi Costin,
I will reply to these e-mails separately, if this is ok.
On Saturday 17 May 2003 19:59, Costin Manolache wrote:
Sorry for the late reply, I had almost no acces to internet ( or time )
last week.
My main concern is the same as Conor's - having this decoupled and done
in few steps.
peter reilly wrote:
On Thursday 15 May 2003 07:56, Conor MacNeill wrote:
I would prefer to use the XML schema attribute for this.
Mmmm, this would be confusing as the XML schema attribute
has an associated URI http://www.w3.org/2001/XMLSchema; which
implies a lot more that a reference to an ant type.
Schema-style attributes - maybe. XMLShema itself is one of the worst
things in XML (IMO), I would preffer we stay as far away as possible - but
I'm ok with using some ideas.
I have done a quick review of you proposal. I wonder if we can split
this into smaller chunks to make it easier to understand and review. For
example, the onError stuff could be split out, as could the URL handling
code for separate consideration. Smaller chunks are easier to handle.
This is true, but difficult to do. Some of the implementations of the
different features change/improve if other features are present. For
example the implementation of onerror uses the new anttypedefintion
class. The implementation of the psuedo task antlib uses the add(Type)
mechanism rather than explicity stating addTypedef and addTaskdef, this
allowed other tasks that extend Definer to used in the antlib task (for
example a definer that wraps Runnable objects as ant tasks, or
a future implemation of roles).
That means you have to start with add(Type), then anttypdef, then onerror.
I could do this, but it would take a little time... The implementation
of add(Type) has been different after each of my updates...
One reason I combined them all together was to get a feeling on the
solution when all the pieces were in place.
Also from a practical point of view, I find it difficult to maintain
multiple patched ant versions.
I think we are talking about the main branch - so there is no
patched ant version to maintain. From a practical point of view, it
is much easier to review and accept smaller chunks.
Anyway, it seems to me that you have combined the namespace URI and
element names in certain places. Examples: In component helper changes,
for method createComponent, you say
the name of the component, if
the component is in a namespace, the
name is prefixed withe the namespace uri
dropping the antlib: and adding :.
Why not pass the URI and local name to the component helper and not have
to parse it out in componentHelper. Your approach also precludes URIs
that contain ':' (I know you disallow these elsewhere but I don't see
any reason to combine these, anyway)
Initially I was going to do this, but here is a lot of places in the code
that assume that a task/type is mapped from a string and not from the
tuple
{ns uri, local name}.
J.Pietschmann suggested in
http://marc.theaimsgroup.com/?l=ant-devm=105233644225128w=2
that one can use a mapping of {uri, name} to a string ns-uri+^+name
when migrating a project to namespaced XML.
I agree using a combined NS + Element may be simpler.
I would suggest ns-uri:name ( i.e. : instead of ^ ). It is easy to extract
the name with lastIndexOf(). It's just cosmetic, of course.
This is exactly what my patch on friday does :-).
My current mapping is not good as it drops the antlib: prefix and thus
excludes other uri prefixes, so I will change this. The current code does
exclude URI that contain :, this is a combination of a bug and by
design. The bug is that I should have used lastindexof and the design is
that the code only deals with NS URIs that start with antlib: for
type/task definitions. The code for the mapping should be done in one
place (maybe as a static method in ProjectHelper).
In any case, antlib: or any prefix should _never_ be used in resolutions.
Only the URI. The prefix is just a syntactic shortcut, the URI is the one
that matters.
I'm not sure where TaskAdapter went. createNewTask seems to return null
if the class is not a Task - probably handled somewhere else.
This is by design and for BC reasons. If the type class is not a Task,
and the type does not have an Adapter to a Task class, the
CM#createNewTask() will not create the class. taskdef/ will does this
(for example the condition task), and the unit tests contain an adapter
for Runnable objects. The code in CM does not treat TaskAdapter as a
special case.
I think taskdef should be treated as a special typedef with TaskAdapter
as adapter.
( i.e. use typedef as the main definition mechanism, and taskdef as
a shortcut for types with optional TaskAdapter adapters ).
This is exacty what taskdef is in the patch :-). It derives
from typedef and sets the adapterClass to TaskAdapter, and the adaptoClass
to Task. The
Re: antlib / proposal of Peter Reilly
On Saturday 17 May 2003 20:13, Costin Manolache wrote: peter reilly wrote: for example: typedef resource=org/acme/mydefinitions.xml classpath=classes/ to allow loading of tasks/types from different 3rd party with some tasks haveing the same name, I have added a prefix attribute. taskdef resource=net/sf/antcontrib/antcontrib.properties prefix=antcontrib./ taskdef resource=.../antelope.properties prefix=antelope/ What is the prefix doing ? Is it related with NS, or are you using it with non-namespaces ant ? I don't think it's a good idea to try to support both NS and prefix.element notation. For simple antfiles, just place all elements in the default NS ( i.e. no ns is used ). If name conflicts - use the standard mechanism to resolve name conflicts, which in XML is the namespaces. It would be confusing to have another way to solve name conflicts. +1 After playing with the code, I have found that the build script visible prefix is not needed and it is not a good idea (i.e. confusing). My current code has removed the prefix and antlib attributes to typedef. The uri attribute is left to allow the build script author to place the definitions in a different XML NS if required. Peter
RE: antlib / proposal of Peter Reilly
From: peter reilly [mailto:[EMAIL PROTECTED] On Saturday 17 May 2003 19:59, Costin Manolache wrote: I think taskdef should be treated as a special typedef with TaskAdapter as adapter. ( i.e. use typedef as the main definition mechanism, and taskdef as a shortcut for types with optional TaskAdapter adapters ). This is exacty what taskdef is in the patch :-). It derives from typedef and sets the adapterClass to TaskAdapter, and the adaptoClass to Task. The html page for taskdef in the friday patch makes this explicit. I have some WorkInProgress code to allow this to be specified in a buildfile. extendtype name=taskdef typedef adapter=org.apache.tools.ant.TaskAdapter adaptto=org.apache.tools.ant.Task/ /extendtype extendtype is a WIP name for a cut-down templating feature, it defines new types from other types with some attributes pre set. Well I am glad, you guys are rediscovering role definitions one feature at the time. :-) Jose Alberto
Re: antlib / proposal of Peter Reilly
On Saturday 17 May 2003 20:16, Costin Manolache wrote: Antoine Levy-Lambert wrote: I am having a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19897 This proposal seems to address most of the points discussed in this mailing list concerning the antlib thread of discussion. I was thinking maybe we do not need to look further and we could commit this contribution ? I would be glad to hear your comments concerning : 1) the functionality provided by the contribution 2) the implementation I am quoting Peter Reilly here : This patch adds 4 new features (the code is interrelated, but may be split). * adapter attribute added to typedef +1 * add(Type) method added to introspection rules +1 * typedef can read an xml defintion file +1 - but I need further review of the XML DTD ( and maybe some changes ) * namespace support for xml defintions (antlib:) So one can do project xmlns:acme=org.acme.anttasks acme:hello path path=build.xml/ /acme:hello /project +1 We should also support the antlib classpath=cp resource=... uri=NSURI The above should be typedef classpath=cp resource=.. uri=NSURI/. The antlib task in my proposal is not meant to be used in a build script. acme:hellp xmlns:acme=NSURI This would allow arbitrary NSURIs ( for people who like meaning-free URIs) and allow the classpath association. I do not want meaning-free URIs. I want ant to ignore URIs that it does not understand. At the time of processing the typedef's uri, the parsing has been complete, so my rule is that uri's used in typedef/ have to start with antlib:. typedef classpath=cp resource=.. uri=antlib:arbitarystring/ where arbiratystring is an arbitary string, but the package from is treated specially with first encountered. An example of using other URIs is http://www.w3.org/TR/2003/WD-xhtml2-20030506/xhtml20_relax.html#a_xhtml20_relaxng I include an example in friday's patch: src/etc/testcases/xmlns.xml which is a build file and a html page. Peter
DO NOT REPLY [Bug 17640] - building ant: chmod returned -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=17640. 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=17640 building ant: chmod returned -1 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Target Milestone|--- |1.6
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Chmod.java ExecuteOn.java
bodewig 2003/05/19 05:18:10
Modified:.WHATSNEW build.xml
docs/manual/CoreTasks apply.html chmod.html
src/main/org/apache/tools/ant/taskdefs Chmod.java
ExecuteOn.java
Log:
You can now limit the parallelism of apply and chmod by using the
new maxparallel attribute.
Submitted by: Frank A. Hunleth fhunleth at cs dot wustl dot edu
used in build.xml to fix PR: 17640
With the new addsourcefile attribute, you can make apply ommit the
source file names from the command line.
PR: 13654
apply and chmod now support nested filelists as well.
PR: 15929
apply and chmod will display a summary if you set the new verbose
attribute to true.
PR: 19883
Revision ChangesPath
1.421 +12 -0 ant/WHATSNEW
Index: WHATSNEW
===
RCS file: /home/cvs/ant/WHATSNEW,v
retrieving revision 1.420
retrieving revision 1.421
diff -u -r1.420 -r1.421
--- WHATSNEW 16 May 2003 09:22:28 - 1.420
+++ WHATSNEW 19 May 2003 12:18:07 - 1.421
@@ -346,6 +346,18 @@
that can be used to turn of Microsoft extensions while using the jvc
compiler. Bugzilla Report 19826.
+* You can now limit the parallelism of apply and chmod by using the new
+ maxparallel attribute.
+
+* With the new addsourcefile attribute, you can make apply ommit the
+ source file names from the command line. Bugzilla Report 13654.
+
+* apply and chmod now support nested filelists as well.
+ Bugzilla Report 15929.
+
+* apply and chmod will display a summary if you set the new
+ verbose attribute to true. Bugzilla Report 19883.
+
Changes from Ant 1.5.2 to Ant 1.5.3
===
1.377 +3 -2 ant/build.xml
Index: build.xml
===
RCS file: /home/cvs/ant/build.xml,v
retrieving revision 1.376
retrieving revision 1.377
diff -u -r1.376 -r1.377
--- build.xml 13 May 2003 14:36:59 - 1.376
+++ build.xml 19 May 2003 12:18:07 - 1.377
@@ -26,6 +26,7 @@
property name=debug value=true/
property name=chmod.fail value=true/
+ property name=chmod.maxparallel value=250/
property name=deprecation value=false/
property name=optimize value=true/
property name=javac.target value=1.1/
@@ -963,7 +964,7 @@
chmod perm=ugo+rx dir=${dist.dir} type=dir includes=**
failonerror=${chmod.fail}/
chmod perm=ugo+r dir=${dist.dir} type=file includes=**
- failonerror=${chmod.fail}/
+ failonerror=${chmod.fail} maxparallel=${chmod.maxparallel}/
chmod perm=ugo+x type=file failonerror=${chmod.fail}
fileset dir=${dist.bin}
include name=**/ant/
@@ -1037,7 +1038,7 @@
chmod perm=ugo+rx dir=${dist.dir} type=dir includes=**
failonerror=${chmod.fail}/
chmod perm=ugo+r dir=${dist.dir} type=file includes=**
- failonerror=${chmod.fail}/
+ failonerror=${chmod.fail} maxparallel=${chmod.maxparallel}/
chmod perm=ugo+x type=file failonerror=${chmod.fail}
fileset dir=${dist.bin}
include name=**/ant/
1.21 +33 -5 ant/docs/manual/CoreTasks/apply.html
Index: apply.html
===
RCS file: /home/cvs/ant/docs/manual/CoreTasks/apply.html,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- apply.html27 Mar 2003 13:22:33 - 1.20
+++ apply.html19 May 2003 12:18:08 - 1.21
@@ -15,14 +15,15 @@
the command is only executed when Ant is run on one of the specified
operating
systems./p
pThe files and/or directories of a number of a
-href=../CoreTypes/fileset.htmlFileSet/as are passed as arguments
+href=../CoreTypes/fileset.htmlFileSet/as or a
+href=../CoreTypes/filelist.htmlFileList/as are passed as arguments
to the system command./p
pIf you specify a nested a
href=../CoreTypes/mapper.htmlmapper/a and the idest/i attribute,
the timestamp of each source file is compared to the timestamp of a
target file which is defined by the nested mapper element and searched
for in the given dest./p
-pAt least one fileset is required, and you must not specify more than
+pAt least one fileset or filelist is required, and you must not specify
more than
one mapper./p
h3Parameters/h3
table border=1 cellpadding=2 cellspacing=0
@@ -53,7 +54,7 @@
td valign=toprelative/td
td valign=topwhether the filenames should be passed on the
command line as absolute or relative pathnames (relative to the
- base directory of the corresponding fileset for source files or
+ base directory of the corresponding fileset/list for source files or
DO NOT REPLY [Bug 13654] - RFE: option to suppress srcfile as arg in apply
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=13654. 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=13654 RFE: option to suppress srcfile as arg in apply [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-05-19 12:21 --- implemented as addsourcefile attribute in nightly build 2003-05-20.
DO NOT REPLY [Bug 15929] - apply needs support for filelists
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=15929. 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=15929 apply needs support for filelists [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-05-19 12:21 --- support added in nightly build 2003-05-20.
DO NOT REPLY [Bug 17640] - building ant: chmod returned -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=17640. 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=17640 building ant: chmod returned -1 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-05-19 12:22 --- Supposed to be fixed with nightly build 2003-05-20. At least it works on my Linux box now.
DO NOT REPLY [Bug 19883] - apply should output the number of files/directories handled
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=19883. 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=19883 apply should output the number of files/directories handled [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-05-19 12:22 --- implemented in nightly build 2003-05-20, you need to enable it with the new verbose attribute.
Re: [PATCH] Limit amount of parallelism for apply task
On Mon, 3 Dec 2001, Frank A. Hunleth [EMAIL PROTECTED] wrote: The problem that I ran into was that I was running a program using the apply task. It ran faster if given many files to work on in parallel, but in one situation the number of files passed to it overwhelmned it. Thanks, the patch finally made it into Ant's CVS (almost eighteen months on my TODO list, sorry). Stefan
Re: antlib / proposal of Peter Reilly
On Monday 19 May 2003 11:50, Wannheden, Knut wrote:
Peter,
acme:hellp xmlns:acme=NSURI
This would allow arbitrary NSURIs ( for people who like
meaning-free URIs)
and allow the classpath association.
I do not want meaning-free URIs.
I want ant to ignore URIs that it does not understand.
At the time of processing the typedef's uri, the parsing has
been complete, so
my rule is that uri's used in typedef/ have to start with antlib:.
I don't quite see why it would be impossible to have meaning-free URIs.
Nothing is impossible..., but it is difficult to have meaning-free URIs and to
support (as in ignore) other URIs.
I would like ant to ignore other namespaces so that it is a civilized member
of the xml community.
For example the following specifies which processor deals with which
element tag:
project xmlns:h=http://www.w3.org/1999/xhtml;
xmlns=ant:core
echo message=hello world/
h:html
h:bodyhello world/h:body
/h:html
/project
the above produces hello world as an ant script and hello world in an NS
aware browser.
I
think it makes perfectly sense. Namespaces are to avoid name clashes.
This is not the only reason for XML namespaces. The standard says
that are to allow elements and attributes that are defined for and used
by multiple software modules.
Ant
doesn't either force you to use certain Java package names when
implementing tasks.
Can't the typedef/ task just add another antlib to the Project?
? this is what typedef/ does
typedef classpath=cp resource=.. uri=antlib:arbitarystring/
where arbiratystring is an arbitary string, but the
package from is
treated specially with first encountered.
I think an URI like antlib:arbitarystring is quite confusing as well.
I would agree with you here. Maybe another pattern could be allowed?
I only have a problem with an arbitrary uri ;-)
IMO
an URI starting with antlib: should always mean that the following
denotes a package with that antlib. What would happen if I had a Java
package on the classpath called arbitarystring?
The definitions are appended to the definitions defined in {converted
package}/antlib.xml.
This is the same behaviour as definitions going into the default namespace.
Peter
cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs MoveTest.java
bodewig 2003/05/19 07:05:23
Modified:src/etc/testcases/taskdefs move.xml
src/testcases/org/apache/tools/ant/taskdefs MoveTest.java
Log:
Demonstrate bug 11732
Revision ChangesPath
1.3 +21 -0 ant/src/etc/testcases/taskdefs/move.xml
Index: move.xml
===
RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/move.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- move.xml 6 Mar 2002 03:25:50 - 1.2
+++ move.xml 19 May 2003 14:05:22 - 1.3
@@ -22,9 +22,30 @@
/move
/target
+ !-- Bugzilla Report 11732 --
+ target name=testDirectoryRemoval
+mkdir dir=A/B/
+mkdir dir=A/C/
+mkdir dir=A/D/
+touch file=A/B/1/
+touch file=A/C/2/
+touch file=A/D/3/
+mkdir dir=E/
+move todir=E includeemptydirs=true
+ fileset dir=A
+include name=C/
+include name=D/
+include name=C/**/
+include name=D/**/
+ /fileset
+/move
+ /target
+
target name=cleanup
delete file=move.filterset.tmp/
delete file=move.filterchain.tmp/
+delete dir=A/
+delete dir=E/
/target
/project
1.6 +14 -1
ant/src/testcases/org/apache/tools/ant/taskdefs/MoveTest.java
Index: MoveTest.java
===
RCS file:
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/MoveTest.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- MoveTest.java 10 Feb 2003 14:14:45 - 1.5
+++ MoveTest.java 19 May 2003 14:05:23 - 1.6
@@ -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
@@ -95,5 +95,18 @@
File check = new File(getProjectDir(),
expected/copy.filterset.filtered);
assertTrue(tmp.exists());
assertTrue(fileUtils.contentEquals(tmp, check));
+}
+
+/** Bugzilla Report 11732 */
+public void testDirectoryRemoval() throws IOException {
+executeTarget(testDirectoryRemoval);
+assertTrue(!getProject().resolveFile(E/B/1).exists());
+assertTrue(getProject().resolveFile(E/C/2).exists());
+assertTrue(getProject().resolveFile(E/D/3).exists());
+assertTrue(getProject().resolveFile(A/B/1).exists());
+assertTrue(!getProject().resolveFile(A/C/2).exists());
+assertTrue(!getProject().resolveFile(A/D/3).exists());
+assertTrue(!getProject().resolveFile(A/C).exists());
+assertTrue(!getProject().resolveFile(A/D).exists());
}
}
cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs MoveTest.java
bodewig 2003/05/19 07:11:24
Modified:src/etc/testcases/taskdefs move.xml
src/testcases/org/apache/tools/ant/taskdefs MoveTest.java
Log:
Demonstrate bug 18886
Revision ChangesPath
1.4 +9 -0 ant/src/etc/testcases/taskdefs/move.xml
Index: move.xml
===
RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/move.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- move.xml 19 May 2003 14:05:22 - 1.3
+++ move.xml 19 May 2003 14:11:24 - 1.4
@@ -41,6 +41,15 @@
/move
/target
+ !-- Bugzilla Report 18886 --
+ target name=testDirectoryRetaining
+mkdir dir=A/
+mkdir dir=E/
+move todir=E
+ fileset dir=A/
+/move
+ /target
+
target name=cleanup
delete file=move.filterset.tmp/
delete file=move.filterchain.tmp/
1.7 +7 -0
ant/src/testcases/org/apache/tools/ant/taskdefs/MoveTest.java
Index: MoveTest.java
===
RCS file:
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/MoveTest.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- MoveTest.java 19 May 2003 14:05:23 - 1.6
+++ MoveTest.java 19 May 2003 14:11:24 - 1.7
@@ -109,4 +109,11 @@
assertTrue(!getProject().resolveFile(A/C).exists());
assertTrue(!getProject().resolveFile(A/D).exists());
}
+
+/** Bugzilla Report 18886 */
+public void testDirectoryRetaining() throws IOException {
+executeTarget(testDirectoryRetaining);
+assertTrue(getProject().resolveFile(E).exists());
+assertTrue(getProject().resolveFile(A).exists());
+}
}
cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs MoveTest.java
bodewig 2003/05/19 07:27:43
Modified:src/etc/testcases/taskdefs move.xml
src/testcases/org/apache/tools/ant/taskdefs MoveTest.java
Log:
Actually, the test for 18886 was supposed to work as is, this is a better test
Revision ChangesPath
1.5 +9 -0 ant/src/etc/testcases/taskdefs/move.xml
Index: move.xml
===
RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/move.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- move.xml 19 May 2003 14:11:24 - 1.4
+++ move.xml 19 May 2003 14:27:43 - 1.5
@@ -44,7 +44,16 @@
!-- Bugzilla Report 18886 --
target name=testDirectoryRetaining
mkdir dir=A/
+touch file=A/1/
mkdir dir=E/
+move todir=E includeemptydirs=true
+ fileset dir=A includes=1/
+/move
+ /target
+
+ target name=testCompleteDirectoryMove
+mkdir dir=A/
+touch file=A/1/
move todir=E
fileset dir=A/
/move
1.8 +10 -0
ant/src/testcases/org/apache/tools/ant/taskdefs/MoveTest.java
Index: MoveTest.java
===
RCS file:
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/MoveTest.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- MoveTest.java 19 May 2003 14:11:24 - 1.7
+++ MoveTest.java 19 May 2003 14:27:43 - 1.8
@@ -114,6 +114,16 @@
public void testDirectoryRetaining() throws IOException {
executeTarget(testDirectoryRetaining);
assertTrue(getProject().resolveFile(E).exists());
+assertTrue(getProject().resolveFile(E/1).exists());
+assertTrue(!getProject().resolveFile(A/1).exists());
assertTrue(getProject().resolveFile(A).exists());
+}
+
+public void testCompleteDirectoryMove() throws IOException {
+executeTarget(testCompleteDirectoryMove);
+assertTrue(getProject().resolveFile(E).exists());
+assertTrue(getProject().resolveFile(E/1).exists());
+assertTrue(!getProject().resolveFile(A/1).exists());
+assertTrue(!getProject().resolveFile(A).exists());
}
}
RE: antlib / proposal of Peter Reilly
From: peter reilly [mailto:[EMAIL PROTECTED]
On Monday 19 May 2003 11:50, Wannheden, Knut wrote:
I don't quite see why it would be impossible to have
meaning-free URIs.
Nothing is impossible..., but it is difficult to have
meaning-free URIs and to
support (as in ignore) other URIs.
I would like ant to ignore other namespaces so that it is a
civilized member
of the xml community.
For example the following specifies which processor deals with which
element tag:
project xmlns:h=http://www.w3.org/1999/xhtml;
xmlns=ant:core
echo message=hello world/
h:html
h:bodyhello world/h:body
/h:html
/project
the above produces hello world as an ant script and hello
world in an NS
aware browser.
I really think this is the very worst that we can do to ANT.
The above example is nore than just confusing, it seem to me
quite meaningless. I can see situations where could be valid
for ANT not to interpret another NS but not just plain ignore it.
For example it would be nice if I could write the following:
project xmlns:h=http://www.w3.org/1999/xhtml;
xmlns=ant:core
echo file=out.html
h:html
h:bodyhello world/h:body
/h:html
/echo
/project
with the result being a file out.html containing:
h:html xmlns:h=http://www.w3.org/1999/xhtml;
h:bodyhello world/h:body
/h:html
But in here we are not ignoring the XHTML, instead we are
able to interpret it to be equivalent to TEXT for the purpose
of parsing. Which is not the same.
BTW, this is what things like XSLT do when you use other namespaces.
I
think it makes perfectly sense. Namespaces are to avoid
name clashes.
This is not the only reason for XML namespaces. The standard says
that are to allow elements and attributes that are defined
for and used
by multiple software modules.
Besides of the issue of how to completly ignore things (as you wanted above)
all your different NS that you force people to use (all the diferent antlib:xxx)
are all process by the same software module (i.e., ANT).
The thing I do not like is that it continues forcing us to have a CORE
which has special rules to manage its special NS and any other libraries
which are force to use NS designators.
Moreover, it means that until the end of time we will have to continue
shipping ANT as a monolitic gigantic antlib containing every definition
for CORE and OPTIONAL tasks. Why? Because that is the only way to have
them all using the default namespace.
If instead we use uninterpreted URIs which are only there for collision solving
then we can chop things in reasonable componets and still being able to
use them in a backward compatible manner.
IMO
an URI starting with antlib: should always mean that the following
denotes a package with that antlib. What would happen if I
had a Java
package on the classpath called arbitarystring?
The definitions are appended to the definitions defined in {converted
package}/antlib.xml.
This is the same behaviour as definitions going into the
default namespace.
In your example above you use 'xmlns=ant:core' instead of
'xmlns=antlib:org.apache.tools.ant...'
so it does not seem to be the same behaviour, there is something magical about
CORE.
If you were to tell me that there is some sort of implicit
'xmlns=antlib:' for the core
that I could accept, but I really dislike having some other special notation.
Notice that in Java, the only special thing about the language is the it
provides
an implicit 'import java.lang.*;' that is all, appart from that the language
makes
absolutely no distinctions between Java CORE and any third party libraries.
Everybody plays by exactly the same rules.
That is what I would like to achieve at the end of this exercise.
Jose Alberto
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Copy.java Move.java
bodewig 2003/05/19 07:43:17
Modified:src/main/org/apache/tools/ant/taskdefs Copy.java Move.java
Log:
Don't remove basedirectories of filesets that just happen to be
matched completely.
PR: 18886
Revision ChangesPath
1.56 +3 -2 ant/src/main/org/apache/tools/ant/taskdefs/Copy.java
Index: Copy.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Copy.java,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -r1.55 -r1.56
--- Copy.java 28 Mar 2003 08:06:53 - 1.55
+++ Copy.java 19 May 2003 14:43:17 - 1.56
@@ -391,7 +391,8 @@
String[] srcFiles = ds.getIncludedFiles();
String[] srcDirs = ds.getIncludedDirectories();
-boolean isEverythingIncluded = ds.isEverythingIncluded();
+boolean isEverythingIncluded = ds.isEverythingIncluded()
+ (!fs.hasSelectors() !fs.hasPatterns());
if (isEverythingIncluded
!flatten mapperElement == null) {
completeDirMap.put(fromDir, destDir);
1.34 +1 -66 ant/src/main/org/apache/tools/ant/taskdefs/Move.java
Index: Move.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Move.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- Move.java 27 Mar 2003 16:32:18 - 1.33
+++ Move.java 19 May 2003 14:43:17 - 1.34
@@ -213,71 +213,6 @@
+ destDir.getAbsolutePath());
}
}
-
-if (filesets.size() 0) {
-Enumeration e = filesets.elements();
-while (e.hasMoreElements()) {
-FileSet fs = (FileSet) e.nextElement();
-File dir = fs.getDir(getProject());
-
-if (okToDelete(dir)) {
-deleteDir(dir);
-}
-}
-}
-}
-
-/**
- * Its only ok to delete a directory tree if there are
- * no files in it.
- * @return true if a deletion can go ahead
- */
-protected boolean okToDelete(File d) {
-String[] list = d.list();
-if (list == null) {
-return false;
-} // maybe io error?
-
-for (int i = 0; i list.length; i++) {
-String s = list[i];
-File f = new File(d, s);
-if (f.isDirectory()) {
-if (!okToDelete(f)) {
-return false;
-}
-} else {
-return false; // found a file
-}
-}
-
-return true;
-}
-
-/**
- * Go and delete the directory tree.
- */
-protected void deleteDir(File d) {
-String[] list = d.list();
-if (list == null) {
-return;
-} // on an io error list() can return null
-
-for (int i = 0; i list.length; i++) {
-String s = list[i];
-File f = new File(d, s);
-if (f.isDirectory()) {
-deleteDir(f);
-} else {
-throw new BuildException(UNEXPECTED ERROR - The file
- + f.getAbsolutePath()
- + should not exist!);
-}
-}
-log(Deleting directory + d.getAbsolutePath(), verbosity);
-if (!d.delete()) {
-throw new BuildException(Unable to delete directory
- + d.getAbsolutePath());
-}
}
/**
Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Copy.java Move.java
On 19 May 2003, [EMAIL PROTECTED] wrote: Don't remove basedirectories of filesets that just happen to be matched completely. This introduces a backwards incompatibility and maybe even inconsistency, that's why I haven't closed the bug report yet. I'm asking for feedback here. The bug report complains about this situation: move todir=foo fileset dir=bar includes=baz/ /move will remove the directory bar, if there is no other file but baz in in. If there happens to be a file zyzzy, the directory is retained. The complaint is that Ant could know that you didn't intend to move the whole set - you wouldn't have used includes otherwise. So now the above will retain the bar directory while move todir=foo fileset dir=bar/ /move will remove it. This seems to be consistent with the docs that say , | Move a set of files to a new directory | | move todir=some/new/dir | fileset dir=my/src/dir | include name=**/*.jar/ | exclude name=**/ant.jar/ | /fileset | /move ` and not move a complete directory tree if all files are included. Stefan
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Copy.java Move.java
bodewig 2003/05/19 08:21:15
Modified:.build.xml
src/main/org/apache/tools/ant/taskdefs Copy.java Move.java
Log:
Remove directories explicitly matched with includes.
PR: 11732
Revision ChangesPath
1.379 +0 -1 ant/build.xml
Index: build.xml
===
RCS file: /home/cvs/ant/build.xml,v
retrieving revision 1.378
retrieving revision 1.379
diff -u -r1.378 -r1.379
--- build.xml 19 May 2003 14:12:15 - 1.378
+++ build.xml 19 May 2003 15:21:14 - 1.379
@@ -276,7 +276,6 @@
patternset id=teststhatfail
exclude name=${optional.package}/BeanShellScriptTest.java/
exclude name=${ant.package}/taskdefs/ImportTest.java/
-exclude name=${ant.package}/taskdefs/MoveTest.java/
/patternset
!--
1.57 +0 -0 ant/src/main/org/apache/tools/ant/taskdefs/Copy.java
Index: Copy.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Copy.java,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -r1.56 -r1.57
1.35 +64 -5 ant/src/main/org/apache/tools/ant/taskdefs/Move.java
Index: Move.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Move.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- Move.java 19 May 2003 14:43:17 - 1.34
+++ Move.java 19 May 2003 15:21:15 - 1.35
@@ -194,24 +194,83 @@
}
if (includeEmpty) {
-Enumeration e = dirCopyMap.elements();
+Enumeration e = dirCopyMap.keys();
int count = 0;
while (e.hasMoreElements()) {
-File d = new File((String) e.nextElement());
-if (!d.exists()) {
-if (!d.mkdirs()) {
+String fromDirName = (String) e.nextElement();
+String toDirName = (String) dirCopyMap.get(fromDirName);
+File fromDir = new File(fromDirName);
+File toDir = new File(toDirName);
+if (!toDir.exists()) {
+if (!toDir.mkdirs()) {
log(Unable to create directory
-+ d.getAbsolutePath(), Project.MSG_ERR);
++ toDirName, Project.MSG_ERR);
} else {
count++;
}
}
+if (okToDelete(fromDir)) {
+deleteDir(fromDir);
+}
}
if (count 0) {
log(Moved + count + empty directories to
+ destDir.getAbsolutePath());
}
+}
+}
+
+/**
+ * Its only ok to delete a directory tree if there are
+ * no files in it.
+ * @return true if a deletion can go ahead
+ */
+protected boolean okToDelete(File d) {
+String[] list = d.list();
+if (list == null) {
+return false;
+} // maybe io error?
+
+for (int i = 0; i list.length; i++) {
+String s = list[i];
+File f = new File(d, s);
+if (f.isDirectory()) {
+if (!okToDelete(f)) {
+return false;
+}
+} else {
+return false; // found a file
+}
+}
+
+return true;
+}
+
+/**
+ * Go and delete the directory tree.
+ */
+protected void deleteDir(File d) {
+String[] list = d.list();
+if (list == null) {
+return;
+} // on an io error list() can return null
+
+for (int i = 0; i list.length; i++) {
+String s = list[i];
+File f = new File(d, s);
+if (f.isDirectory()) {
+deleteDir(f);
+} else {
+throw new BuildException(UNEXPECTED ERROR - The file
+ + f.getAbsolutePath()
+ + should not exist!);
+}
+}
+log(Deleting directory + d.getAbsolutePath(), verbosity);
+if (!d.delete()) {
+throw new BuildException(Unable to delete directory
+ + d.getAbsolutePath());
}
}
DO NOT REPLY [Bug 11732] - move task on directories wont always delete original directories
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=11732. 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=11732 move task on directories wont always delete original directories [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-05-19 15:24 --- should be fixed (if you explicitly include C and D and set includeemptydirs to true) in nightly build 2003-05-20.
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Copy.java
bodewig 2003/05/19 08:37:31
Modified:.WHATSNEW
docs/manual/CoreTasks copy.html move.html
src/main/org/apache/tools/ant/taskdefs Copy.java
Log:
Make copy's failonerror attribute swallow exception while copying as
well.
PR: 12999
Revision ChangesPath
1.422 +4 -0 ant/WHATSNEW
Index: WHATSNEW
===
RCS file: /home/cvs/ant/WHATSNEW,v
retrieving revision 1.421
retrieving revision 1.422
diff -u -r1.421 -r1.422
--- WHATSNEW 19 May 2003 12:18:07 - 1.421
+++ WHATSNEW 19 May 2003 15:37:31 - 1.422
@@ -358,6 +358,10 @@
* apply and chmod will display a summary if you set the new
verbose attribute to true. Bugzilla Report 19883.
+* copy/move's failonerror attribute can now also be used to
+ continue the build if an I/O error caused a problem. Bugzilla
+ Report 12999.
+
Changes from Ant 1.5.2 to Ant 1.5.3
===
1.18 +2 -1 ant/docs/manual/CoreTasks/copy.html
Index: copy.html
===
RCS file: /home/cvs/ant/docs/manual/CoreTasks/copy.html,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- copy.html 14 May 2003 11:53:41 - 1.17
+++ copy.html 19 May 2003 15:37:31 - 1.18
@@ -95,7 +95,8 @@
td valign=topfailonerror/td
td valign=topLog a warning message, but do not stop the
build, when the file to copy does not exist or one of the nested
- filesets points to a directory that doesn't exist.
+ filesets points to a directory that doesn't exist or an error occurs
+ while copying.
/td
td valign=top align=centerNo; defaults to true./td
/tr
1.13 +2 -1 ant/docs/manual/CoreTasks/move.html
Index: move.html
===
RCS file: /home/cvs/ant/docs/manual/CoreTasks/move.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- move.html 14 May 2003 11:53:41 - 1.12
+++ move.html 19 May 2003 15:37:31 - 1.13
@@ -80,7 +80,8 @@
td valign=topfailonerror/td
td valign=topLog a warning message, but do not stop the
build, when the file to copy does not exist or one of the nested
- filesets points to a directory that doesn't exist.
+ filesets points to a directory that doesn't exist or an error occurs
+ while moving.
/td
td valign=top align=centerNo; defaults to true./td
/tr
1.58 +56 -48ant/src/main/org/apache/tools/ant/taskdefs/Copy.java
Index: Copy.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Copy.java,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- Copy.java 19 May 2003 15:21:15 - 1.57
+++ Copy.java 19 May 2003 15:37:31 - 1.58
@@ -401,7 +401,15 @@
}
// do all the copy operations now...
-doFileOperations();
+try {
+doFileOperations();
+} catch (BuildException e) {
+if (!failonerror) {
+log(Warning: + e.getMessage(), Project.MSG_ERR);
+} else {
+throw e;
+}
+}
} finally {
// clean up again, so this instance can be used a second
// time
@@ -418,66 +426,66 @@
}
}
-//
-// protected and private methods
-//
-
-/**
- * Ensure we have a consistent and legal set of attributes, and set
- * any internal flags necessary based on different combinations
- * of attributes.
- */
-protected void validateAttributes() throws BuildException {
-if (file == null filesets.size() == 0) {
-throw new BuildException(Specify at least one source
- + - a file or a fileset.);
-}
-
-if (destFile != null destDir != null) {
-throw new BuildException(Only one of tofile and todir
- + may be set.);
-}
+
//
+// protected and private methods
+
//
+
+/**
+ * Ensure we have a consistent and legal set of attributes, and set
+ * any internal flags necessary
DO NOT REPLY [Bug 12999] - failonerror does not work on Copy 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=12999. 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=12999 failonerror does not work on Copy task [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-05-19 15:39 --- fixed with nightly build 2003-05-20.
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Copy.java
bodewig 2003/05/19 08:41:23
Modified:src/main/org/apache/tools/ant/taskdefs Copy.java
Log:
revert funny reformatting accidentially introduced with last commit
Revision ChangesPath
1.59 +50 -50ant/src/main/org/apache/tools/ant/taskdefs/Copy.java
Index: Copy.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Copy.java,v
retrieving revision 1.58
retrieving revision 1.59
diff -u -r1.58 -r1.59
--- Copy.java 19 May 2003 15:37:31 - 1.58
+++ Copy.java 19 May 2003 15:41:22 - 1.59
@@ -426,66 +426,66 @@
}
}
-
//
-// protected and private methods
-
//
-
-/**
- * Ensure we have a consistent and legal set of attributes, and set
- * any internal flags necessary based on different combinations
- * of attributes.
- */
-protected void validateAttributes() throws BuildException {
-if (file == null filesets.size() == 0) {
-throw new BuildException(Specify at least one source
- + - a file or a fileset.);
-}
-
-if (destFile != null destDir != null) {
-throw new BuildException(Only one of tofile and todir
- + may be set.);
-}
-
-if (destFile == null destDir == null) {
-throw new BuildException(One of tofile or todir must be
set.);
-}
-
-if (file != null file.exists() file.isDirectory()) {
-throw new BuildException(Use a fileset to copy
directories.);
-}
+/
+ ** protected and private methods
+
/
+
+/**
+ * Ensure we have a consistent and legal set of attributes, and set
+ * any internal flags necessary based on different combinations
+ * of attributes.
+ */
+protected void validateAttributes() throws BuildException {
+if (file == null filesets.size() == 0) {
+throw new BuildException(Specify at least one source
+ + - a file or a fileset.);
+}
+
+if (destFile != null destDir != null) {
+throw new BuildException(Only one of tofile and todir
+ + may be set.);
+}
+
+if (destFile == null destDir == null) {
+throw new BuildException(One of tofile or todir must be set.);
+}
+
+if (file != null file.exists() file.isDirectory()) {
+throw new BuildException(Use a fileset to copy directories.);
+}
+
+if (destFile != null filesets.size() 0) {
+if (filesets.size() 1) {
+throw new BuildException(
+ Cannot concatenate multiple files
into a single file.);
+} else {
+FileSet fs = (FileSet) filesets.elementAt(0);
+DirectoryScanner ds = fs.getDirectoryScanner(getProject());
+String[] srcFiles = ds.getIncludedFiles();
-if (destFile != null filesets.size() 0) {
-if (filesets.size() 1) {
+if (srcFiles.length == 0) {
throw new BuildException(
- Cannot concatenate multiple
files into a single file.);
-} else {
-FileSet fs = (FileSet) filesets.elementAt(0);
-DirectoryScanner ds =
fs.getDirectoryScanner(getProject());
-String[] srcFiles = ds.getIncludedFiles();
-
-if (srcFiles.length == 0) {
-throw new BuildException(
- Cannot perform operation
from directory to file.);
-} else if (srcFiles.length == 1) {
-if (file == null) {
-file = new File(ds.getBasedir(), srcFiles[0]);
-filesets.removeElementAt(0);
-} else {
-throw new BuildException(Cannot concatenate
multiple
- + files into a single
file.);
-}
+ Cannot perform operation from
directory to file.);
+
cvs commit: ant/src/testcases/org/apache/tools/ant/util FileUtilsTest.java
bodewig 2003/05/19 08:55:23
Modified:src/main/org/apache/tools/ant/util FileUtils.java
src/testcases/org/apache/tools/ant/util FileUtilsTest.java
Log:
removeLeadingPath didn't work as expected when trying to remove a path
from itself.
PR: 19979
Revision ChangesPath
1.42 +8 -4 ant/src/main/org/apache/tools/ant/util/FileUtils.java
Index: FileUtils.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/util/FileUtils.java,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- FileUtils.java22 Apr 2003 18:23:55 - 1.41
+++ FileUtils.java19 May 2003 15:55:22 - 1.42
@@ -988,12 +988,16 @@
* @since Ant 1.5
*/
public String removeLeadingPath(File leading, File path) {
+String l = normalize(leading.getAbsolutePath()).getAbsolutePath();
+String p = normalize(path.getAbsolutePath()).getAbsolutePath();
+if (l.equals(p)) {
+return ;
+}
+
// if leading's path ends with a slash, it will be stripped by
// normalize - we always add one so we never think /foo was a
// parent directory of /foobar
-String l = normalize(leading.getAbsolutePath()).getAbsolutePath()
-+ File.separator;
-String p = normalize(path.getAbsolutePath()).getAbsolutePath();
+l += File.separator;
if (p.startsWith(l)) {
return p.substring(l.length());
} else {
1.16 +10 -1
ant/src/testcases/org/apache/tools/ant/util/FileUtilsTest.java
Index: FileUtilsTest.java
===
RCS file:
/home/cvs/ant/src/testcases/org/apache/tools/ant/util/FileUtilsTest.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- FileUtilsTest.java7 Mar 2003 11:23:14 - 1.15
+++ FileUtilsTest.java19 May 2003 15:55:23 - 1.16
@@ -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
@@ -406,6 +406,15 @@
fu.removeLeadingPath(new File(/foo), new
File(/bar)));
assertEquals(fu.normalize(/foobar).getAbsolutePath(),
fu.removeLeadingPath(new File(/foo), new
File(/foobar)));
+// bugzilla report 19979
+assertEquals(, fu.removeLeadingPath(new File(/foo/bar),
+ new File(/foo/bar)));
+assertEquals(, fu.removeLeadingPath(new File(/foo/bar),
+ new File(/foo/bar/)));
+assertEquals(, fu.removeLeadingPath(new File(/foo/bar/),
+ new File(/foo/bar/)));
+assertEquals(, fu.removeLeadingPath(new File(/foo/bar/),
+ new File(/foo/bar)));
}
/**
DO NOT REPLY [Bug 18128] - filesets don't support sets of absolute filenames
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=18128.
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=18128
filesets don't support sets of absolute filenames
--- Additional Comments From [EMAIL PROTECTED] 2003-05-19 16:48 ---
The new 1.5.3 version breaks my workaround. I can no longer use srcfilelist as
follows:
dependset
srcfilelist dir=/ files=D:/config/env/build.properties /
targetfileset dir=${build.ejb} includes=${messageTempFile} /
/dependset
So my compiles build everything all the time because ant thinks the file
doesn't exist.
I like the proposed option of making dir optional. Another possibility is to
treat files as an absolute path if dir=. Or, implement both options. If
this does get implemented, just make sure it is implemented for fileset,
filelist, srcfileset, srcfilelist, and any other set or list operations that
work the same way.
DO NOT REPLY [Bug 20020] - ANTLR.java invalid command-line argument: -traceTreeWalker;
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=20020. 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=20020 ANTLR.java invalid command-line argument: -traceTreeWalker; --- Additional Comments From [EMAIL PROTECTED] 2003-05-19 16:54 --- antlr.Version class appears to have all the info you may need.
Re: antlib / proposal of Peter Reilly
Yikes!!
There are a number of issues here.
1) are build script authors allowed to specify arbitary
URIs for ant type definitions?
I do not think this is a good idea.
2) what should ant do with URIs that it does not recognize?
a) use current method - unknown elements
b) ignore them
c) explicty say that the ns uri is not supported
d) convert them to Text in task/typedefs (the suggestion below)
I would prefer b) as it allows other processing of the xml content -
say in an xml processing pipeline. d) is also nice.
3) Should all processing outside Project/Target be done by PH2#ElementHandler?
I think one should be able to plug in handlers for different URIs, or URI
patterns. My UnknownUriHandler is an (possibly not very good) example.
On Monday 19 May 2003 15:33, Jose Alberto Fernandez wrote:
From: peter reilly [mailto:[EMAIL PROTECTED]
On Monday 19 May 2003 11:50, Wannheden, Knut wrote:
I don't quite see why it would be impossible to have
meaning-free URIs.
Nothing is impossible..., but it is difficult to have
meaning-free URIs and to
support (as in ignore) other URIs.
I would like ant to ignore other namespaces so that it is a
civilized member
of the xml community.
For example the following specifies which processor deals with which
element tag:
project xmlns:h=http://www.w3.org/1999/xhtml;
xmlns=ant:core
echo message=hello world/
h:html
h:bodyhello world/h:body
/h:html
/project
the above produces hello world as an ant script and hello
world in an NS
aware browser.
I really think this is the very worst that we can do to ANT.
He came, He saw, He destroyed...
Some xml applications ignore content outside its domain, some
do not..
The above example is nore than just confusing, it seem to me
quite meaningless. I can see situations where could be valid
for ANT not to interpret another NS but not just plain ignore it.
For example it would be nice if I could write the following:
project xmlns:h=http://www.w3.org/1999/xhtml;
xmlns=ant:core
echo file=out.html
h:html
h:bodyhello world/h:body
/h:html
/echo
/project
with the result being a file out.html containing:
h:html xmlns:h=http://www.w3.org/1999/xhtml;
h:bodyhello world/h:body
/h:html
But in here we are not ignoring the XHTML, instead we are
able to interpret it to be equivalent to TEXT for the purpose
of parsing. Which is not the same.
BTW, this is what things like XSLT do when you use other namespaces.
I
think it makes perfectly sense. Namespaces are to avoid
name clashes.
This is not the only reason for XML namespaces. The standard says
that are to allow elements and attributes that are defined
for and used
by multiple software modules.
Besides of the issue of how to completly ignore things (as you wanted
above) all your different NS that you force people to use (all the diferent
antlib:xxx) are all process by the same software module (i.e., ANT).
No, I think that URI handlers should be pluggable in and not all
XML should be processed via the ElementHandler / UnknownElement /
IntrospectionHandler and RuntimeConfigurable classes.
XML NS Uri's introducded via antlib/typedef should be processed via
the ANT software module (in my view). But other sources - for example
Mbean support may use a different collection of classes.
The thing I do not like is that it continues forcing us to have a CORE
which has special rules to manage its special NS and any other libraries
which are force to use NS designators.
Moreover, it means that until the end of time we will have to continue
shipping ANT as a monolitic gigantic antlib containing every definition
for CORE and OPTIONAL tasks. Why? Because that is the only way to have
them all using the default namespace.
If instead we use uninterpreted URIs which are only there for collision
solving then we can chop things in reasonable componets and still being
able to use them in a backward compatible manner.
I do not follow your argument here. What difference do uninterpreted URIs
make to the ANT being an gigantic antlib?
IMO
an URI starting with antlib: should always mean that the following
denotes a package with that antlib. What would happen if I
had a Java
package on the classpath called arbitarystring?
The definitions are appended to the definitions defined in {converted
package}/antlib.xml.
This is the same behaviour as definitions going into the
default namespace.
In your example above you use 'xmlns=ant:core' instead of
'xmlns=antlib:org.apache.tools.ant...' so it does not seem to be the same
behaviour, there is something magical about CORE.
Initially I had the default being antlib:org.apache.tools.ant.., but I
dropped that for two reasons:
1) for bc reasons, the definitions defined by typedef or
at start up (copy, concat...)
DO NOT REPLY [Bug 19288] - Add noqualifier attribute to javadoc 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=19288.
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=19288
Add noqualifier attribute to javadoc task
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Additional Comments From [EMAIL PROTECTED] 2003-05-19 18:23 ---
Code which currently reads:
public void setNoqualifier(String noq) {
if (!javadoc4) {
log (-noqualifier option not supported on JavaDoc 1.4,
Project.MSG_VERBOSE);
}
this.noqualifier = noqualifier;
}
should read
this.noqualifier = noq;
or
public void setNoqualifier(String noqualifier) {
Set does not get performed.
DO NOT REPLY [Bug 20043] New: - WebsphereDeploymentTool problem with setNoinform
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=20043.
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=20043
WebsphereDeploymentTool problem with setNoinform
Summary: WebsphereDeploymentTool problem with setNoinform
Product: Ant
Version: 1.5.3
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
public void setNoinform(boolean noinfom) {
this.noinform = noinform;
}
J2EE Deployment Models
This is not an Ant-specific question, but I'm not aware of any general build/deploy/promotion practices e-mail lists, and this is the closest thing to that. If someone does know of such a list/newsgroup, let me know and I redirect my query as appropriate. Our current deployment for J2EE apps is to use an EAR. Inside the EAR's base directory, we have a lib directory, which contains JARs that the EJB JARs may reference in their Class-Path entry (ie, fop.jar, log4j.jar, etc.). Also within the base directory are all the WARs and EJB JARs that make up the EAR. We have a third party source providing us with an EAR that uses a radically different deployment model, and I'd be curious to hear opinions and thoughts on it. Within the EAR the application is split up into three different groupings: presentation, common, and service tiers. Each group is a JAR file, containing within it whatever EJB JARs or WARs fall within that logical grouping. So there are 3 layers of packging that occur - the EJBs and WARs get wrapped up into a generic JAR by group, and then the 3 groups composing the application get wrapped up into an EAR. As build manager and deployer, our build, deploy, and promotion processes (and by that, I mean the automated scripts, including Ant files) would face signifigant change to support this new model. I also have concerns about how standard or non-standard this type of deployment model is. We really try to stick close to the specs for J2EE and avoid anything that ties us to non-standard practices, or vendor lock-in. Thoughts? Thanks, Kyle Adams Developer, Gordon Food Service
