cvs commit: ant/src/script antRun.pl
bodewig 2003/09/01 02:57:01 Modified:src/script antRun.pl Log: Add Copyright lines, PR 22807 Revision ChangesPath 1.2 +5 -1 ant/src/script/antRun.pl Index: antRun.pl === RCS file: /home/cvs/ant/src/script/antRun.pl,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- antRun.pl 15 Nov 2001 08:00:09 - 1.1 +++ antRun.pl 1 Sep 2003 09:57:01 - 1.2 @@ -1,4 +1,8 @@ #!/usr/bin/perl +# +# Copyright (c) 2001,2003 The Apache Software Foundation. All rights +# reserved. +# ### # # antRun.pl @@ -7,7 +11,7 @@ # this is akin to antRun.bat, and antRun the SH script # # created: 2001-10-18 -# last modified: 2001-11-13 +# last modified: $Date$ # author: Jeff Tulley [EMAIL PROTECTED] ### #be fussy about variables - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/testcases/org/apache/tools/ant/util LazyFileOutputStreamTest.java
bodewig 2003/09/01 02:50:05
Modified:src/main/org/apache/tools/ant/taskdefs Redirector.java
Added: src/main/org/apache/tools/ant/util LazyFileOutputStream.java
src/testcases/org/apache/tools/ant/util
LazyFileOutputStreamTest.java
Removed: src/main/org/apache/tools/ant/util
DelayedFileOutputStream.java
Log:
DelayedFileOutputStream - LazyFileOutputStream (thanks, DD).
Add test for LazyFileOutputStream.
Make sure that output files get created, even if they are empty. This
is for backwards compatibility.
Found and removed an attempt to close the same stream twice.
Revision ChangesPath
1.10 +14 -6
ant/src/main/org/apache/tools/ant/taskdefs/Redirector.java
Index: Redirector.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Redirector.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- Redirector.java 27 Aug 2003 10:08:25 - 1.9
+++ Redirector.java 1 Sep 2003 09:50:05 - 1.10
@@ -67,7 +67,7 @@
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.Project;
import org.apache.tools.ant.Task;
-import org.apache.tools.ant.util.DelayedFileOutputStream;
+import org.apache.tools.ant.util.LazyFileOutputStream;
import org.apache.tools.ant.util.StringUtils;
import org.apache.tools.ant.util.TeeOutputStream;
@@ -269,8 +269,7 @@
errorStream = new LogOutputStream(managingTask,
Project.MSG_WARN);
} else {
if (out != null) {
-outputStream
-= new DelayedFileOutputStream(out, append);
+outputStream = new LazyFileOutputStream(out, append);
managingTask.log(Output redirected to + out,
Project.MSG_VERBOSE);
}
@@ -296,8 +295,7 @@
}
if (error != null) {
-errorStream
-= new DelayedFileOutputStream(error, append);
+errorStream = new LazyFileOutputStream(error, append);
managingTask.log(Error redirected to + error,
Project.MSG_VERBOSE);
}
@@ -460,8 +458,18 @@
if (inputStream != null) {
inputStream.close();
}
+
+if (outputStream instanceof LazyFileOutputStream) {
+((LazyFileOutputStream) outputStream).open();
+}
outputStream.close();
-errorStream.close();
+
+if (errorStream != outputStream) {
+if (errorStream instanceof LazyFileOutputStream) {
+((LazyFileOutputStream) errorStream).open();
+}
+errorStream.close();
+}
if (baos != null) {
setPropertyFromBAOS(baos, outputProperty);
1.1
ant/src/main/org/apache/tools/ant/util/LazyFileOutputStream.java
Index: LazyFileOutputStream.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
cvs commit: ant/src/script runant.pl
bodewig 2003/09/01 03:14:26
Modified:src/script runant.pl
Log:
Sync runant.pl with the other scripts to use new Launcher
Revision ChangesPath
1.6 +9 -36 ant/src/script/runant.pl
Index: runant.pl
===
RCS file: /home/cvs/ant/src/script/runant.pl,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- runant.pl 1 Jun 2002 12:26:42 - 1.5
+++ runant.pl 1 Sep 2003 10:14:26 - 1.6
@@ -1,6 +1,6 @@
#!/usr/bin/perl
#
-# Copyright (c) 2001-2002 The Apache Software Foundation. All rights
+# Copyright (c) 2000-2003 The Apache Software Foundation. All rights
# reserved.
#
###
@@ -18,7 +18,7 @@
# the code is not included.
#
# created: 2000-8-24
-# last modified: 2000-8-24
+# last modified: $Date$
# author: Steve Loughran [EMAIL PROTECTED]
###
#
@@ -86,38 +86,11 @@
$localpath=;
}
-#add jar files. I am sure there is a perl one liner to do this.
-my $jarpattern=$HOME/lib/*.jar;
-my @jarfiles =glob($jarpattern);
-print [EMAIL PROTECTED] if ($debug);
-my $jar;
-foreach $jar (@jarfiles )
-{
-$localpath.=$s$jar;
-}
-
-#if Java home is defined, look for tools.jar classes.zip and add to
classpath
-my $JAVA_HOME = $ENV{JAVA_HOME};
-if ($JAVA_HOME ne )
-{
-my $tools=$JAVA_HOME/lib/tools.jar;
-if (-e $tools)
-{
-$localpath .= $s$tools;
-}
-my $classes=$JAVA_HOME/lib/classes.zip;
-if (-e $classes)
-{
-$localpath .= $s$classes;
-}
-}
-else
-{
-print \n\nWarning: JAVA_HOME environment variable is not set.\n.
-If the build fails because sun.* classes could not be
found\n.
-you will need to set the JAVA_HOME environment variable\n.
-to the installation directory of java\n;
-}
+if ($localpath eq ) {
+ $localpath = $HOME/lib/ant-launcher.jar;
+} else {
+ $localpath = $HOME/lib/ant-launcher.jar$s$localpath;
+}
#set JVM options and Ant arguments, if any
my @ANT_OPTS=split( , $ENV{ANT_OPTS});
@@ -131,6 +104,7 @@
#construct arguments to java
my @ARGS;
+push @ARGS, @ANT_OPTS;
if ($onnetware == 1)
{
# make classpath literally $CLASSPATH; and then the contents of $localpath
@@ -143,8 +117,7 @@
push @ARGS, -classpath, $localpath;
}
push @ARGS, -Dant.home=$HOME;
-push @ARGS, @ANT_OPTS;
-push @ARGS, org.apache.tools.ant.Main, @ANT_ARGS;
+push @ARGS, org.apache.tools.ant.launch.Launcher, @ANT_ARGS;
push @ARGS, @ARGV;
print \n $JAVACMD @ARGS\n\n if ($debug);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22807] - No copyright in antRun.pl
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=22807. 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=22807 No copyright in antRun.pl [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 09:42 --- I was going to adapt the Perl script to use the new launcher anyway and will add the copyright header while I'm at it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22834] - XSLT fails transforming file with doctype
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=22834. 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=22834 XSLT fails transforming file with doctype --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 09:46 --- Maybe your Linux box is behind a firewall? You are loading the DTD via hhtp in your example and if the network connection to Sun fails for some reason, you are out of luck. Could you retry with a local copy of the DTD? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22807] - No copyright in antRun.pl
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=22807. 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=22807 No copyright in antRun.pl [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 09:59 --- mixed up antRun.pl and runant.pl, sorry. I've added the copyright. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/types Permissions.java
antoine 2003/09/01 05:45:07
Modified:docs/manual/CoreTasks java.html
src/main/org/apache/tools/ant/taskdefs Java.java
src/testcases/org/apache/tools/ant/taskdefs JavaTest.java
src/main/org/apache/tools/ant/types Permissions.java
Log:
Use again Permissions to catch non zero exit statuses when using the Java task
with FailOnError = true
PR: 22533
Revision ChangesPath
1.24 +1 -3 ant/docs/manual/CoreTasks/java.html
Index: java.html
===
RCS file: /home/cvs/ant/docs/manual/CoreTasks/java.html,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- java.html 29 Aug 2003 13:05:06 - 1.23
+++ java.html 1 Sep 2003 12:45:06 - 1.24
@@ -88,7 +88,7 @@
tr
td valign=topfailonerror/td
td valign=topStop the buildprocess if the command exits with a
- returncode other than 0. Default is false!--(see a
href=#failonerrornote)--/a/td
+ returncode other than 0. Default is false (see a
href=#failonerrornote)/a/td
td align=center valign=topNo/td
/tr
tr
@@ -220,13 +220,11 @@
pWhen the permission RuntimePermission exitVM has not been granted (or has
been revoked) the System.exit() call will be intercepted
and treated like indicated in ifailonerror/i./p
-!--
pa name=failonerror/
If you specify codefailonerror=quot;truequot;/code and you do not
specify permissions,
a set of default permissions will be added to your java invocation making
sure that
a non zero return code will lead to a codeBuildException/code.
/p
---
pSettings will be ignored if fork is enabled./p
pemsince Ant 1.6/em./p
1.73 +1 -3 ant/src/main/org/apache/tools/ant/taskdefs/Java.java
Index: Java.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Java.java,v
retrieving revision 1.72
retrieving revision 1.73
diff -u -r1.72 -r1.73
--- Java.java 29 Aug 2003 13:05:06 - 1.72
+++ Java.java 1 Sep 2003 12:45:07 - 1.73
@@ -180,13 +180,11 @@
log(bootclasspath ignored when same JVM is used.,
Project.MSG_WARN);
}
-/*
if (perm == null failOnError == true) {
-perm = new Permissions();
+perm = new Permissions(true);
log(running + this.cmdl.getClassname()
+ with default permissions (exit forbidden),
Project.MSG_VERBOSE);
}
-*/
log(Running in same VM + cmdl.describeJavaCommand(),
Project.MSG_VERBOSE);
}
1.17 +2 -2
ant/src/testcases/org/apache/tools/ant/taskdefs/JavaTest.java
Index: JavaTest.java
===
RCS file:
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/JavaTest.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- JavaTest.java 29 Aug 2003 13:05:06 - 1.16
+++ JavaTest.java 1 Sep 2003 12:45:07 - 1.17
@@ -195,7 +195,7 @@
executeTarget(testResultPropertyNonZeroNoFork);
assertEquals(-1,project.getProperty(exitcode));
}
-/*
+
public void testRunFailWithFailOnError() {
expectBuildExceptionContaining(testRunFailWithFailOnError,
non zero return code,
@@ -205,7 +205,7 @@
public void testRunSuccessWithFailOnError() {
executeTarget(testRunSuccessWithFailOnError);
}
-*/
+
public void testSpawn() {
FileUtils fileutils = FileUtils.newFileUtils();
File logFile = fileutils.createTempFile(spawn,log,
project.getBaseDir());
1.3 +55 -13ant/src/main/org/apache/tools/ant/types/Permissions.java
Index: Permissions.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/types/Permissions.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Permissions.java 29 Aug 2003 11:10:58 - 1.2
+++ Permissions.java 1 Sep 2003 12:45:07 - 1.3
@@ -86,8 +86,24 @@
private java.security.Permissions granted = null;
private SecurityManager origSm = null;
private boolean active = false;
-
-/**
+private boolean delegateToOldSM = false;
+
+/**
+ * default constructor
+ */
+public Permissions() {
+}
+/**
+ * create a new set of permissions
+ * @param delegateToOldSM if codetrue/code the old security manager
+ * will be used if the permission has not been explicitly granted or
revoked
+
DO NOT REPLY [Bug 22533] - [PATCH] Adding Permissions / Security Manager to Java task and JUnit 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=22533. 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=22533 [PATCH] Adding Permissions / Security Manager to Java task and JUnit task --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 10:09 --- Symptom of the problem : gump build failing in bootstrap-ojb, where there is an invocation of the java task with FailOnError=true The problem was due to missing permission read for system property file.encoding, then to missing permissions for file system operations. Why do nothing special about permissions in the Java task when failonerror = false ? there is no need to do anything. Why do something special about permissions when failonerror = true : so that non zero exit statuses generate an exception which can be caught in the Java task and so that the build can be failed (rather than terminated). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting 1.6 out the door
Hi,
I was on holidays the last two weeks
and so will use this reply to some
of the issues.
On Thursday 28 August 2003 14:07, Conor MacNeill wrote:
My position on these issues is
1. import
Go with it as is. I think it is useful and useable without coming up
against some of the cases we have discussed. How we address those issues
can be tackled later, perhaps with a different mechanism. That is bound up
in the whole issue of target visibility and overriding.
+1 to use import as is.
I'm not sure whether we should provide a simple include as well which
does no renaming (overrides)?
2. antlib
I think this should be in but I am not familiar with its state yet, nor do
I think it has had enough testing - might just be my own need to kick the
tyres. Are we planning to antlib Ant's own optional jars? In 1.7 I think we
need to look at removing antlibs from the root loader when their dependent
jars are not available in ANT_HOME/lib.
+ 1 for antlib in 1.6 , -1 to use for ant's optional jars in 1.6
+1 (from Dominique) to add antlib.xml to antcontrib
I have written a manual page for antlib. There is more
work required (for example how to write a task to fit correct
into an antlib - uri and classloader handling), it also
uses macrodef and presetdef as examples ;-).
3. macrodef and presetdef
These seem to have some issues lately and I suggest we pull these into 1.7
I would like them in 1.6 (but I would say that...), in particular I would
like macrodef to be present.
As far as I can see there are two issues with macrodef, handling of
properties and handling of attributes.
a) resolution of properties
The issue here is that properties get resolved when the macro is used
and not when the macro is defined.
I think that it would be difficult to resolve the properties correctly
when the macro is defined. For example:
macrodef name=echo.my.property
sequential
echo${my.property}/echo
/sequential
macrodef
If the property my.property is not defined at the time of definition
and is defined when echo.my.property is used, the Echo#setText() would
be given ${my.property} and would resolve it. Also how does macrodef
know that ${my.property} should be expanded for echo as against for
replace where is it (incorrectly) not.
I think that the current implementation and behaviour is preferable.
b) syntax of attributes
The issue here is that the syntax for macro attributes is the same as
properties (i.e. ${name}), and that people may be confused between
them. Some of the proposed syntaxes are:
i) $[name] (Conor)
ii) (@name) (Dominique)
iii) [EMAIL PROTECTED] name} (Dominique)
iv) ${macroattr:name} (Jose)
After using macrodef for a little while (well mostly in writing
examples), I think that ${name} feels the best.
In future I expect that there will be different scopes for
variables/properties (perhaps only for ant-contrib/antelope/other and
not in core ant), - task level variables, macro level variables and
global variables (properties). It would be strange to have different
syntax for each.
However this (unlike a) is easy to code for :-), if ${name} syntax is not
liked my other preference would be ${macroattr:name}.
Other issues for 1.6:
* Doc for new introspection methods (add(type))
* polymorphic attribute (ant-type)
Doc for this, is it useful?
* It would be nice to get the classloader task to work.
* overwriting definitions.
Currently one can overwrite a definition with only a warning. It may be
usefull to make it more difficult to overwrite definitions (Costin) -
for example for namespaced definitions. After struggling with make's
CCFLAGS, I really like ant's lack of magic varibles, so javac / means
javac/ and not javac x=y.../. (I realise that I have gave an example
of this in a previous e-mail).
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/docs/manual/CoreTypes antlib.html
peterreilly2003/09/01 07:22:04 Modified:docs/manual conceptstypeslist.html docs/manual/CoreTasks typedef.html Added: docs/manual/CoreTypes antlib.html Log: manual page for antlib Revision ChangesPath 1.13 +7 -0 ant/docs/manual/conceptstypeslist.html Index: conceptstypeslist.html === RCS file: /home/cvs/ant/docs/manual/conceptstypeslist.html,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- conceptstypeslist.html27 Aug 2003 14:23:16 - 1.12 +++ conceptstypeslist.html1 Sep 2003 14:22:04 - 1.13 @@ -36,10 +36,17 @@ a href=OptionalTypes/extension.htmlExtension Package/abr a href=OptionalTypes/extensionset.htmlSet of Extension Packages/abr +h3Antlib/h3 +a href=CoreTypes/antlib.htmlAntlib/abr +a href=CoreTypes/antlib.html#antlibnamespaceAntlib namespace/abr +a href=CoreTypes/antlib.html#currentnamespaceCurrent namespace/abr + + h3Custom Components/h3 a href=CoreTypes/custom-programming.htmlCustom Components/abr a href=CoreTypes/custom-programming.html#customconditionsConditions/abr a href=CoreTypes/custom-programming.html#customselectorsSelectors/abr a href=CoreTypes/custom-programming.html#filterreadersFilterReaders/abr + /body /html 1.10 +3 -25 ant/docs/manual/CoreTasks/typedef.html Index: typedef.html === RCS file: /home/cvs/ant/docs/manual/CoreTasks/typedef.html,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- typedef.html 13 Aug 2003 13:22:58 - 1.9 +++ typedef.html 1 Sep 2003 14:22:04 - 1.10 @@ -42,7 +42,8 @@ /pre p -The xml format is described below in the a href=#antlibAntlib/a +The xml format is described in the +a href=../CoreTypes/antlib.htmlAntlib/a section. /p @@ -81,7 +82,7 @@ are properties or xml. If the value is properties the file/resource is a property file contains name to classname pairs. If the value is xml, the file/resource is an xml file/resource structured according - to a href=#antlibAntlib/a. + to a href=../CoreTypes/antlib.htmlAntlib/a. The default is properties unless the file/resorce name ends with .xml, in which case the format attribute will have the value xml. (introduced in ant1.6) @@ -167,29 +168,6 @@ classname=com.acme.ant.RunClock adapter=org.acme.ant.RunnableAdapter/gt; /pre - h3a name=antlibAntlib xml format/a/h3 - An antlib file is an xml file with a root element of antlib. - Antlib is actually a a href=sequential.htmlSequential/a task with - special treatment for tasks that are ant definition tasks - like typedef - and a href=taskdef.htmlTaskdef/a. - -A group of tasks and types may be defined together in an antlib -file. For example the file isample.xml/i contains the following: - pre -lt;?xml version=1.0?gt; -lt;antlibgt; - lt;typedef name=if classname=org.acme.ant.If/gt; - lt;typedef name=scriptpathmapper - classname=org.acme.ant.ScriptPathMapper - onerror=ignore/gt; -lt;/antlibgt; - /pre -It defines two types or tasks, iif/i and iscriptpathmapper/i. -This antlib file may be used in a build script as follows: -pre - lt;typedef file=sample.xml/gt; -/pre - hr p align=centerCopyright copy; 2001-2003 Apache Software Foundation. All rights Reserved./p 1.1 ant/docs/manual/CoreTypes/antlib.html Index: antlib.html === html head meta http-equiv=Content-Language content=en-us/meta titleAntLib/title /head body h2a name=antlibAntlib/a/h2 p iEXPERIMENTAL:/i The antlib concept and implementation is experimental and may be under continual change until Ant1.6 ships. The contents of this page uses the experimental tasks lt;macrodefgt; and lt;presetdefgt; which may not be in Ant1.6. /p h3Description/h3 p An antlib file is an xml file with a root element of antlib. Antlib is actually a a href=sequential.htmlSequential/a task with special treatment for tasks that are ant definition tasks - like a href=../CoreTasks/typedef.htmlTypedef/a and a href=../CoreTasks/taskdef.htmlTaskdef/a. /p p A group of tasks and types may be defined together in an antlib file. For example the file isample.xml/i contains the following: /p blockquote pre lt;?xml version=1.0?gt;
RE: Getting 1.6 out the door
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
3. macrodef and presetdef
a) resolution of properties
The issue here is that properties get resolved when the
macro is used and not when the macro is defined.
I think that it would be difficult to resolve the
properties correctly when the macro is defined.
I think that the current implementation and behaviour is
preferable.
I think it's sad that you reflect on this from the implementation
perspective rather than the user's one... One of the major 'feature'
of Ant is that it is very explicit and relatively simple.
It's not all about power, or one would use a real programming language
like Perl or Python. macrodef, although powerful, complexifies the rules
of Ant, namely the property expansion one, making it context dependent!
Never underestimate the power and simplicity of context/scope free rules.
Although Ant already has scopes with ant/antcall/subant, the property
expansion rules works the same everywhere, and I'd like this to stay the
same.
b) syntax of attributes
After using macrodef for a little while (well mostly in writing
examples), I think that ${name} feels the best.
That's one opinion. You obviously don't mind complexity yourself b-)
I, OTOH, prefer things clearsimple, with the least possible surprise.
In future I expect that there will be different scopes for
variables/properties (perhaps only for ant-contrib / antelope
/ other and not in core ant), - task level variables, macro level
variables and global variables (properties). It would be strange
to have different syntax for each.
Wo, hold on! We're not turning Ant into a programming language,
remember?
However this (unlike a) is easy to code for :-), if ${name} syntax
is not liked my other preference would be ${macroattr:name}.
Sigh... Again, this notation would introduce a subtle variation on property
expansion, which may indeed be backward incompatible. It's currently
perfectly
OK to have regular property names that for some reason start with
macroattr:.
Property interceptors are not part of Ant, and might never be for that
matter.
Using a notation that mimicks interceptors is probably not a good idea
either.
As I've been saying all along, lets just introduce a new (unique) notion for
attribute/variable expansion (at use time rather than definition time),
which
is something new in Ant anyhow. No (or less?) backward compatibility issues,
and makes it plain and obvious what is what:
${name} it's a property!
(@name) it's an attribute/variable!!!
No context, no unnecessary brain cycles to figure out what is what.
I'll be just as glad as the next guy to use macrodef, I just don't want
that
power to come of the expanse of Ant's simplicitly and user-friendliness.
--DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant ProjectHelper.java ComponentHelper.java
peterreilly2003/09/01 07:15:30
Modified:src/main/org/apache/tools/ant ProjectHelper.java
ComponentHelper.java
Log:
Place antlibs temp defintions in a ant:current namespace.
Revision ChangesPath
1.100 +3 -0 ant/src/main/org/apache/tools/ant/ProjectHelper.java
Index: ProjectHelper.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/ProjectHelper.java,v
retrieving revision 1.99
retrieving revision 1.100
diff -u -r1.99 -r1.100
--- ProjectHelper.java13 Aug 2003 13:18:54 - 1.99
+++ ProjectHelper.java1 Sep 2003 14:15:30 - 1.100
@@ -88,6 +88,9 @@
/** The URI for ant name space */
public static final String ANT_CORE_URI = ant:core;
+/** The URI for antlib current definitions */
+public static final String ANT_CURRENT_URI = ant:current;
+
/** The URI for defined types/tasks - the format is antlib:package */
public static final String ANTLIB_URI = antlib:;
1.26 +13 -9 ant/src/main/org/apache/tools/ant/ComponentHelper.java
Index: ComponentHelper.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/ComponentHelper.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- ComponentHelper.java 15 Aug 2003 15:04:29 - 1.25
+++ ComponentHelper.java 1 Sep 2003 14:15:30 - 1.26
@@ -112,7 +112,7 @@
*/
private Stack antLibStack = new Stack();
/** current antlib context */
-private AntTypeTable antLibTypeTable = null;
+private AntTypeTable antLibCurrentTypeTable = null;
/**
* Map from task names to vectors of created tasks
@@ -268,8 +268,10 @@
public AntTypeDefinition getDefinition(String componentName) {
checkNamespace(componentName);
AntTypeDefinition ret = null;
-if (antLibTypeTable != null componentName.indexOf(':') == -1) {
-ret = antLibTypeTable.getDefinition(componentName);
+if (antLibCurrentTypeTable != null
+ ProjectHelper.ANT_CURRENT_URI.equals(
+ProjectHelper.extractUriFromComponentName(componentName))) {
+ret = antLibCurrentTypeTable.getDefinition(componentName);
}
if (ret == null) {
ret = antTypeTable.getDefinition(componentName);
@@ -689,9 +691,11 @@
Project.MSG_DEBUG);
antTypeTable.put(name, def);
-if (antLibTypeTable != null name.lastIndexOf(':') != -1) {
+if (antLibCurrentTypeTable != null name.lastIndexOf(':') !=
-1) {
String baseName = name.substring(name.lastIndexOf(':') + 1);
-antLibTypeTable.put(baseName, def);
+antLibCurrentTypeTable.put(
+ProjectHelper.genComponentName(
+ProjectHelper.ANT_CURRENT_URI, baseName), def);
}
}
}
@@ -700,8 +704,8 @@
* Called at the start of processing an antlib
*/
public void enterAntLib() {
-antLibTypeTable = new AntTypeTable(project);
-antLibStack.push(antLibTypeTable);
+antLibCurrentTypeTable = new AntTypeTable(project);
+antLibStack.push(antLibCurrentTypeTable);
}
/**
@@ -710,9 +714,9 @@
public void exitAntLib() {
antLibStack.pop();
if (antLibStack.size() != 0) {
-antLibTypeTable = (AntTypeTable) antLibStack.peek();
+antLibCurrentTypeTable = (AntTypeTable) antLibStack.peek();
} else {
-antLibTypeTable = null;
+antLibCurrentTypeTable = null;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: can't build ant 1.6
I've received no replies to this, so let me try again with a little more
information. Previous versions of build.sh (or build.bat) contained this
sequence:
LOCALCLASSPATH=lib/xercesImpl.jar:lib/xml-apis.jar:bootstrap/lib/ant.jar
# add in the dependency .jar files
DIRLIBS=lib/optional/*.jar
for i in ${DIRLIBS}
do
if [ $i != ${DIRLIBS} ] ; then
LOCALCLASSPATH=$LOCALCLASSPATH:$i
fi
done
In the current version, it is like this:
LOCALCLASSPATH=
# add in the dependency .jar files
DIRLIBS=lib/optional/*.jar
for i in ${DIRLIBS}
do
if [ $i != ${DIRLIBS} ] ; then
LOCALCLASSPATH=$LOCALCLASSPATH:$i
fi
done
The difference is that LOCALCLASSPATH is no longer being preset with
xercesImpl.jar and xml-apis.jar before the optional directory is scanned.
The absence of these jars from the classpath was what led to the failures
below. Getting them onto the classpath solved the problem.
But is this a bug? Or is it an undocumented requirement that ant be built in
an environment that has these or other such jars on the classpath? Or is it a
documented requirement and I've just been unable to find the documentation?
-Original Message-
From: Steve Cohen
Sent: Sat 8/30/2003 5:09 PM
To: [EMAIL PROTECTED]
Cc:
Subject:can't build.
This is my first attempt to build ant in awhile.
I downloaded a completely fresh source tree from cvs, made a couple of
extremely minor changes, and then tried to build with build.sh. The bootstrap
build successfully completes, but then when the main build starts, I get this:
[EMAIL PROTECTED] ~/ant]$ ./build.sh -Ddist.dir=dist dist
ANT_HOME=bootstrap
Buildfile: build.xml
BUILD FAILED
XML parser factory has not been configured correctly:
java.lang.ClassNotFoundException: org.apache.xerces.jaxp.SAXParserFactoryImpl
I don't understand this.
My ant/lib directory contains (from the download)
927669 8-01-2003 1:45a -rw-rw-r-- /home/scohen/ant/lib/xercesImpl.jar
108484 6-01-2002 7:26a -rw-rw-r-- /home/scohen/ant/lib/xml-apis.jar
What am I missing? I've never needed anything else to build ant. Has
something changed in the build procedure?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ezmlm warnings
Hello, I have been subsribed to this list for about one year, but in the last months, I sometimes get messages from ezmlm telling me that messages to me have bounced back. And the reason for this is Sorry, I couldn't find any host named nowhere. (#5.1.2) So what does this mean? Below is a copy of the bounce message ezmlm received. Tilman --- Enclosed is a copy of the bounce message I received. Return-Path: Received: (qmail 4410 invoked for bounce); 19 Aug 2003 08:24:15 - Date: 19 Aug 2003 08:24:15 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: failure notice Hi. This is the qmail-send program at apache.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: Sorry, I couldn't find any host named nowhere. (#5.1.2) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22533] - [PATCH] Adding Permissions / Security Manager to Java task and JUnit 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=22533. 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=22533 [PATCH] Adding Permissions / Security Manager to Java task and JUnit task [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22863] New: - Can't just rename a directory with the move 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=22863.
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=22863
Can't just rename a directory with the move task
Summary: Can't just rename a directory with the move task
Product: Ant
Version: 1.5.4
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Normal
Priority: Other
Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I find myself having to resort to the rename task instead of the move task,
for just renaming a directory efficiently (i.e. without actually moving each
file in its subtree individually). Using move would clearly be preferred,
since rename is deprecated in favor of it -- but move makes me wait far
too long.
I tried several variants of move:
move todir=${parent}/${newname}
fileset dir=${parent}/${oldname}/
/move
move todir=${parent}/${newname}
fileset dir=${parent} includes=${oldname}/
/move
move todir=${parent}
fileset dir=${parent} includes=${oldname}/
mapper type=glob from=${oldname} to=${newname}/
/move
move todir=${parent}
fileset dir=${parent}/
mapper type=glob from=${oldname} to=${newname}/
/move
but they all resulted in a heavy-duty hard-disk-crunching file operation,
which is is completely unnecessary, and the rename task doesn't do that.
It may be that there *is* a way to do a simple directory rename using move
... if so, then there is still a bug: the bug is that it is not at all easy
to figure out how to do that! :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting 1.6 out the door
On Monday 01 September 2003 16:43, Dominique Devienne wrote:
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
3. macrodef and presetdef
a) resolution of properties
The issue here is that properties get resolved when the
macro is used and not when the macro is defined.
I think that it would be difficult to resolve the
properties correctly when the macro is defined.
I think that the current implementation and behaviour is
preferable.
I think it's sad that you reflect on this from the implementation
perspective rather than the user's one... One of the major 'feature'
of Ant is that it is very explicit and relatively simple.
The problem is that I do not know how (or if it is possible) to implement the
feature of expanding the properties at definition time.
It's not all about power, or one would use a real programming language
like Perl or Python. macrodef, although powerful, complexifies the rules
of Ant, namely the property expansion one, making it context dependent!
Never underestimate the power and simplicity of context/scope free rules.
Although Ant already has scopes with ant/antcall/subant, the property
expansion rules works the same everywhere, and I'd like this to stay the
same.
macrodef follows (I think) the same rules of properties as antcall with
inheritall=yes.
target name=do.echo.target
echo${do.echo}/echo
do.echo.task/
/target
target name=do.echo.test
macrodef name=do.echo.task
sequential
echo${do.echo}/echo
/sequential
/macrodef
antcall target=do.echo.target
param name=do.echo value=Hello world/
/antcall
/target
macrodef should make ant a little simpler by removing the need
for a lot of antcalls. People sometimes use them at the moment to emulate
macros/templates.
Normally (I think), macrodef would be used in the same project that defined
it, so the rules for property expansion would not be an issue.
b) syntax of attributes
After using macrodef for a little while (well mostly in writing
examples), I think that ${name} feels the best.
That's one opinion. You obviously don't mind complexity yourself b-)
I, OTOH, prefer things clearsimple, with the least possible surprise.
Ok, after using perl, I do not like the idea of having different
syntax for different (but similar) things.
In future I expect that there will be different scopes for
variables/properties (perhaps only for ant-contrib / antelope
/ other and not in core ant), - task level variables, macro level
variables and global variables (properties). It would be strange
to have different syntax for each.
Wo, hold on! We're not turning Ant into a programming language,
remember?
But it is one of the objectives/consequences of ant-contrib/antelope.
One would like to do things like:
notation:warning name=Use of ant as a progamming language
foreach param=file
path
fileset dir=${test.dir}/mains includes=*.cpp/
pathelement
path=${test.dir}/probeoffline/probeoffline.cpp/
pathelement path=src/shell/probesh.cpp/
/path
sequential
propertyregex
property=program input=${file}
regexp=.*/([^\.]*)\.cpp replace=\1/
compile-exec program=${program}
cc-files
path path=${file}/
/cc-files
/compile-exec
compile-exec-file file=${file}/
/sequential
/foreach
/notation:warning
without the program property being visible outside the foreach
sequential element.
However this (unlike a) is easy to code for :-), if ${name} syntax
is not liked my other preference would be ${macroattr:name}.
Sigh... Again, this notation would introduce a subtle variation on property
expansion, which may indeed be backward incompatible. It's currently
perfectly
OK to have regular property names that for some reason start with
macroattr:.
Ok, scratch ${macroattr:name}.
Property interceptors are not part of Ant, and might never be for that
matter.
Using a notation that mimicks interceptors is probably not a good idea
either.
As I've been saying all along, lets just introduce a new (unique) notion
for attribute/variable expansion (at use time rather than definition time),
which
is something new in Ant anyhow. No (or less?) backward compatibility
issues, and makes it plain and obvious what is what:
${name} it's a property!
(@name) it's an attribute/variable!!!
yes but (IMO) this is confusingly similar to XPath use of variables.
macrodef name=cut
attribute name=use
sequential
xmltask source=input.xml dest=1.xml
cut path=web/servlet/context/[EMAIL PROTECTED]'(@use)']
DO NOT REPLY [Bug 15729] - StarTeam rootLocalFolder should be java.io.File
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=15729. 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=15729 StarTeam rootLocalFolder should be java.io.File --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 18:46 --- Now, that at last, I have some free time, I am taking a fresh look at this bug. If I may summarize the discussion to this point: Lee Marlow (supported by Jose Alberto Fernandez) wants the rootlocalfolder attribute to be set relative to basedir when not specified as an absolute path. They point out that this gives more conceptual unity with the rest of ant. Stefan Bodewig worries that this will break backward compatibility with users who expect it to be relative to current working directory. I, Steve Cohen, point out that while backward compatibility will break, Stefan incorrectly understands part of what current functionality is. While it is true that if rootlocalfolder is specified as a relative path, that will currently be interpreted relative to CWD, there is a further twist that if NO rootlocalfolder is specified, rlf will be the default local directory stored in starteam. This is primarily useful in the StarTeam GUI itself, and losing this functionality in ant would be no great loss, IMHO. (It could be remedied by adding yet another attribute to the task, possibly). But Stefan is correct, there would still be a significant backward compatibility issue when relative paths are specified. I wasn't thinking about THAT issue at the time of my earlier comments. However, I am inclined to press forward despite this. Current functionality is a mess: 1) if an absolute path is specified, use that. 2) if a relative path is specified, it is relative to CWD 3) if no rootlocalfolder is specified, the starteam default is used. The problem is that 2 is undocumented (no documentation is provided on what happens when a relative rootlocalfolder is specified). Additionally, its lack of documentation makes it inconsistent with 3. User is arguably entitled to assume that not specifying the attribute would be the same as specifying a relative .. In my use cases, it would make no difference. I always specify rootlocalfolder as an absolute path (perhaps unconsciously aware of the relative path ambiguity here). So what I propose to do is that whenever a relative path is specified, print a WARNING message indicating that the meaning of this attribute has changed from what it meant in 1.5. Something along the lines of WARNING - a relative rootlocalfolder is now interpreted relative to basedir and not to the current working directory as it was in Ant versions prior to 1.6. - 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-09-01 16:17 --- Antoine, Thanks for applying part of the patch and sorry for taking so long to reply (I've been away on business). How about a patch to refactor MailMessage and PlainMailer so that the ContentType and Date code (PlainMailer lines 109 through 116) sits within MailMessage (by adding Date and ContentType getter and setter methods to MailMessage)? Also, being able to specify 7bit, 8bit or MIME header encoding (RFC 1522 - MIME part 2) might be useful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22533] - [PATCH] Adding Permissions / Security Manager to Java task and JUnit 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=22533. 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=22533 [PATCH] Adding Permissions / Security Manager to Java task and JUnit task --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 10:05 --- Created an attachment (id=8019) fix for Java task and Permissions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17695] - Starteam Checkout Mistakenly Says Status Modified
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=17695. 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=17695 Starteam Checkout Mistakenly Says Status Modified [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 19:14 --- I think I need a more detailed description to proceed with looking at this. Also, your StarTeam version is older than any I have access to. Since both your client and server are Win2K machines, I am assuming that CRLF considerations are not involved. Also the whole discussion about Revision On Disk seems to be a false trail, since that is inherently GUI dependent. I wonder if the problem is not inherent in the operation of checking out to a label. Could it perhaps be that StarTeam sees a later version of the file on disk and therefore assumes that the file is modified vis-a-vis the labeled version you are trying to check out? Personally, when checking out a labeled project version through ant, I'd be tempted to start with an empty local directory tree. Otherwise, to get a fully correct local tree you must make sure to also set the createworkingdirs and deleteuncontrolled attributes. I'd like to understand more of your use case here. At any rate I am going to set this to INVALID. If you can provide me with more exact details, I will take a further look. Sorry to take so long on this, but I have been very busy the past six months. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20360] - stcheckout Unable to find root folder When Using a Label
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=20360. 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=20360 stcheckout Unable to find root folder When Using a Label [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 19:37 --- As I think about this, I am strongly inclined not to attempt this fix and have set the status to WONTFIX (even though I'm not sure it's fair to classify this as a bug), and here is why: I think it this request puts too much demand for intelligence on Ant and not enough on the build script. It sounds as though you want to use the same build script to build widely different versions of your target, merely changing the label and have the tool be smart enough to understand the whole StarTeam repository structure over time - even when the versions differ to an extent such that they do not even share the same root local folder! Might it not be simpler to just have different versions of the build script than to change the whole way this task works? RootStarteamFolder is a fundamental concept to this task and I think you're expecting too much if you're expecting consistent behavior over labeled versions when the root directory is not consistent. I'm willing to reopen this, but I need a stronger justification for doing so. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting 1.6 out the door
peter reilly wrote, On 01/09/2003 20.10: On Monday 01 September 2003 16:43, Dominique Devienne wrote: ... It's not all about power, or one would use a real programming language like Perl or Python. macrodef, although powerful, complexifies the rules of Ant, namely the property expansion one, making it context dependent! Never underestimate the power and simplicity of context/scope free rules. Although Ant already has scopes with ant/antcall/subant, the property expansion rules works the same everywhere, and I'd like this to stay the same. macrodef follows (I think) the same rules of properties as antcall with inheritall=yes. +1 ... macrodef should make ant a little simpler by removing the need for a lot of antcalls. People sometimes use them at the moment to emulate macros/templates. Normally (I think), macrodef would be used in the same project that defined it, so the rules for property expansion would not be an issue. I agree. I also think that macrodef is quite important, as it does most of what I have been doing with importing targets, but without the need of using targets. Imports should be reusable bits of builds. But instead they carry the baggage of targets. With macrodef I can finally *create tasks using Ant*. To me, the current macrodef behaviour seems pretty easy to grok. -- 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]
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-09-01 19:41 --- OK, you may attach a new patch to this bug report, or maybe better create a new bug report. Concerning 7bit, 8bit or MIME, I have 3 questions/remarks : 1) what is the practical utility of letting the user choose here ? 2)if we need to offer the choice (between 7bit, 8bit or MIME) to the user, then we need to patch also EMailTask and Mailer. Currently, there is a encoding attribute in the EMailTask, whose possible values are plain, uu, mime or auto. The real meaning of the attribute is implementation because basically it is a choice between ant's own implementation of sending email (PlainMailer and MailMessage classes)and JavaMail wrapped by the MimeMailer class. 3)would a name of contenttype for the new attribute with values 7bits, 8bits or MIME be OK ? this attribute needs to exist in EMailTask and to be pushed from EMailTask to the Mailer abstract class, then to be read in the PlainMailer class and finally used in the MailMessage class. Does this contenttype attribute make sense for the JavaMail implementation of the EMailTask (class MimeMailer) ? If not, this should be said in the docs and a warning should be issued in EMailTask#execute Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20578] - STCheckout - it would be nice to be able to check out against timestamps
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=20578. 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=20578 STCheckout - it would be nice to be able to check out against timestamps --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 19:48 --- I disagree that checking out against a label before a successful compile is not logical. There are many uses for that functionality, for example, a version that has built locally is labeled. It is then submitted to QA. Bugs are fixed, but in the meantime, development has continued beyond this point. Also, StarTeam allows the label for a file to be rolled forward on an individual file basis, meaning that if the original content of a view label had problems, simply my manipulating the label-file association, the label may be made valid. Be that as it may, your use case has validity, and the StarTeam API supports it, so I am going to try to implement it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15934] - StarTeam checkout by date/time
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=15934. 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=15934 StarTeam checkout by date/time [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 19:50 --- This is the same request as in 20578. I am going to take a whack at that. *** This bug has been marked as a duplicate of 20578 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22834] - XSLT fails transforming file with doctype
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=22834. 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=22834 XSLT fails transforming file with doctype --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 10:57 --- it's not a firewall problem: I can get the dtd through my browser on this computer. The problem is exactly the same using a local copy of the dtd. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20578] - STCheckout - it would be nice to be able to check out against timestamps
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=20578. 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=20578 STCheckout - it would be nice to be able to check out against timestamps [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 19:51 --- *** Bug 15934 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Timestamp attribute processing
There have been some requests to add functionality to the stcheckout task (for StarTeam) to enable checkout by a timestamp. It will not be hard to do this, as the scenario is well-supported in the StarTeam API. However, what about the Ant API? Is there a standard way (and reusable/accessible code) for passing in timestamps as attributes to a task? It seems like a bad idea for every task to roll its own date-parse processing. Can someone point me at a better way to implement it in ant? Ideally this would support at least -MM-dd, -MM-dd hh:mm without making the user supply a date-format string.
Re: can't build ant 1.6
Hi Steve,
what I am doing to build ant 1.6 is :
./bootstrap.sh
./build.sh install-lite
ant -Dtest.haltonfailure=no test
this sequence works for me.
Maybe you get hit if you do not first run bootstrap.sh separately.
There have been some changes involving copying xml-apis.jar and Xerces.jar
from lib to bootstrap/lib when building or bootstrapping ant, and removing
xml-apis.jar and Xerces.jar from the CLASSPATH of build.sh.
Hopes this helps,
Antoine
- Original Message -
From: Steve Cohen [EMAIL PROTECTED]
To: Steve Cohen [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, September 01, 2003 7:14 PM
Subject: RE: can't build ant 1.6
I've received no replies to this, so let me try again with a little more
information. Previous versions of build.sh (or build.bat) contained this
sequence:
LOCALCLASSPATH=lib/xercesImpl.jar:lib/xml-apis.jar:bootstrap/lib/ant.jar
# add in the dependency .jar files
DIRLIBS=lib/optional/*.jar
for i in ${DIRLIBS}
do
if [ $i != ${DIRLIBS} ] ; then
LOCALCLASSPATH=$LOCALCLASSPATH:$i
fi
done
In the current version, it is like this:
LOCALCLASSPATH=
# add in the dependency .jar files
DIRLIBS=lib/optional/*.jar
for i in ${DIRLIBS}
do
if [ $i != ${DIRLIBS} ] ; then
LOCALCLASSPATH=$LOCALCLASSPATH:$i
fi
done
The difference is that LOCALCLASSPATH is no longer being preset with
xercesImpl.jar and xml-apis.jar before the optional directory is scanned.
The absence of these jars from the classpath was what led to the failures
below. Getting them onto the classpath solved the problem.
But is this a bug? Or is it an undocumented requirement that ant be built
in an environment that has these or other such jars on the classpath? Or is
it a documented requirement and I've just been unable to find the
documentation?
-Original Message-
From: Steve Cohen
Sent: Sat 8/30/2003 5:09 PM
To: [EMAIL PROTECTED]
Cc:
Subject: can't build.
This is my first attempt to build ant in awhile.
I downloaded a completely fresh source tree from cvs, made a couple of
extremely minor changes, and then tried to build with build.sh. The
bootstrap build successfully completes, but then when the main build starts,
I get this:
[EMAIL PROTECTED] ~/ant]$ ./build.sh -Ddist.dir=dist dist
ANT_HOME=bootstrap
Buildfile: build.xml
BUILD FAILED
XML parser factory has not been configured correctly:
java.lang.ClassNotFoundException:
org.apache.xerces.jaxp.SAXParserFactoryImpl
I don't understand this.
My ant/lib directory contains (from the download)
927669 8-01-2003 1:45a -rw-rw-r--
/home/scohen/ant/lib/xercesImpl.jar
108484 6-01-2002 7:26a -rw-rw-r--
/home/scohen/ant/lib/xml-apis.jar
What am I missing? I've never needed anything else to build ant. Has
something changed in the build procedure?
-
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]
Re: Timestamp attribute processing
- there is a date selector with a method DateSelector#setDateTime which contains parsing code (with a hardcoded US locale, looks like the europeans (continentals) are not allowed to enter DD-MM- dates, MM-DD- is preferred. - there is a DateUtils class in ant It has methods to format dates, but not to parse them. Parsing methods should be added there. - the cvstagdiff task has attributes which are date/timestamps, but the task does not parse these attributes itself, rather they are copied without parsing as command line arguments for the cvs executable. - the tstamp task can create strings (properties) representing dates, but does not have to parse the strings back Cheers, Antoine - Original Message - From: Steve Cohen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 01, 2003 9:58 PM Subject: Timestamp attribute processing There have been some requests to add functionality to the stcheckout task (for StarTeam) to enable checkout by a timestamp. It will not be hard to do this, as the scenario is well-supported in the StarTeam API. However, what about the Ant API? Is there a standard way (and reusable/accessible code) for passing in timestamps as attributes to a task? It seems like a bad idea for every task to roll its own date-parse processing. Can someone point me at a better way to implement it in ant? Ideally this would support at least -MM-dd, -MM-dd hh:mm without making the user supply a date-format string. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: can't build ant 1.6
I tried both with and without separate ./boostrap.sh commands, but I did not
build the way you suggest. My commands were
./bootstrap.sh
./build.sh -Ddist.dir=dist dist-lite
This used to work but no longer does.
If there is a change to the recommended way of building Ant, methinks that
should be well-documented somewhere.
-Original Message-
From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
Sent: Mon 9/1/2003 3:01 PM
To: Ant Developers List
Cc:
Subject:Re: can't build ant 1.6
Hi Steve,
what I am doing to build ant 1.6 is :
./bootstrap.sh
./build.sh install-lite
ant -Dtest.haltonfailure=no test
this sequence works for me.
Maybe you get hit if you do not first run bootstrap.sh separately.
There have been some changes involving copying xml-apis.jar and Xerces.jar
from lib to bootstrap/lib when building or bootstrapping ant, and removing
xml-apis.jar and Xerces.jar from the CLASSPATH of build.sh.
Hopes this helps,
Antoine
- Original Message -
From: Steve Cohen [EMAIL PROTECTED]
To: Steve Cohen [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, September 01, 2003 7:14 PM
Subject: RE: can't build ant 1.6
I've received no replies to this, so let me try again with a little more
information. Previous versions of build.sh (or build.bat) contained this
sequence:
LOCALCLASSPATH=lib/xercesImpl.jar:lib/xml-apis.jar:bootstrap/lib/ant.jar
# add in the dependency .jar files
DIRLIBS=lib/optional/*.jar
for i in ${DIRLIBS}
do
if [ $i != ${DIRLIBS} ] ; then
LOCALCLASSPATH=$LOCALCLASSPATH:$i
fi
done
In the current version, it is like this:
LOCALCLASSPATH=
# add in the dependency .jar files
DIRLIBS=lib/optional/*.jar
for i in ${DIRLIBS}
do
if [ $i != ${DIRLIBS} ] ; then
LOCALCLASSPATH=$LOCALCLASSPATH:$i
fi
done
The difference is that LOCALCLASSPATH is no longer being preset with
xercesImpl.jar and xml-apis.jar before the optional directory is scanned.
The absence of these jars from the classpath was what led to the failures
below. Getting them onto the classpath solved the problem.
But is this a bug? Or is it an undocumented requirement that ant be built
in an environment that has these or other such jars on the classpath? Or is
it a documented requirement and I've just been unable to find the
documentation?
-Original Message-
From: Steve Cohen
Sent: Sat 8/30/2003 5:09 PM
To: [EMAIL PROTECTED]
Cc:
Subject: can't build.
This is my first attempt to build ant in awhile.
I downloaded a completely fresh source tree from cvs, made a couple of
extremely minor changes, and then tried to build with build.sh. The
bootstrap build successfully completes, but then when the main build starts,
I get this:
[EMAIL PROTECTED] ~/ant]$ ./build.sh -Ddist.dir=dist dist
ANT_HOME=bootstrap
Buildfile: build.xml
BUILD FAILED
XML parser factory has not been configured correctly:
java.lang.ClassNotFoundException:
org.apache.xerces.jaxp.SAXParserFactoryImpl
I don't understand this.
My ant/lib directory contains (from the download)
927669 8-01-2003 1:45a -rw-rw-r--
/home/scohen/ant/lib/xercesImpl.jar
108484 6-01-2002 7:26a -rw-rw-r--
/home/scohen/ant/lib/xml-apis.jar
What am I missing? I've never needed anything else to build ant. Has
something changed in the build procedure?
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Timestamp attribute processing
Hmm, that's weaker than I would have expected. If I'd like something a little better, is your recommendation then to add to DateUtils? The StarTeam API uses something they call an OLEDate, which I'm sure has some sort of parse capability but if I rely on that then I run the risk of being out of synch with the rest of Ant. -Original Message- From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED] Sent: Mon 9/1/2003 3:15 PM To: Ant Developers List Cc: Subject:Re: Timestamp attribute processing - there is a date selector with a method DateSelector#setDateTime which contains parsing code (with a hardcoded US locale, looks like the europeans (continentals) are not allowed to enter DD-MM- dates, MM-DD- is preferred. - there is a DateUtils class in ant It has methods to format dates, but not to parse them. Parsing methods should be added there. - the cvstagdiff task has attributes which are date/timestamps, but the task does not parse these attributes itself, rather they are copied without parsing as command line arguments for the cvs executable. - the tstamp task can create strings (properties) representing dates, but does not have to parse the strings back Cheers, Antoine - Original Message - From: Steve Cohen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 01, 2003 9:58 PM Subject: Timestamp attribute processing There have been some requests to add functionality to the stcheckout task (for StarTeam) to enable checkout by a timestamp. It will not be hard to do this, as the scenario is well-supported in the StarTeam API. However, what about the Ant API? Is there a standard way (and reusable/accessible code) for passing in timestamps as attributes to a task? It seems like a bad idea for every task to roll its own date-parse processing. Can someone point me at a better way to implement it in ant? Ideally this would support at least -MM-dd, -MM-dd hh:mm without making the user supply a date-format string. - 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 22859] New: - Cross buildfile dependency
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=22859. 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=22859 Cross buildfile dependency Summary: Cross buildfile dependency 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] I would like to suggest that the depends attribute on targets shall support targets in other build.xml files. This way the project build can be split into subprojects (with their own build.xml files), without having to use the explicit ANT task to handle dependencies and flags to assure that each subproject is only built once (in case of multiple dependencies). Some nice syntax could be used. For example: depends=subproject/build.xml:targetname - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22865] New: - Zip whenempty attribute is broken
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=22865.
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=22865
Zip whenempty attribute is broken
Summary: Zip whenempty attribute is broken
Product: Ant
Version: 1.5
Platform: All
OS/Version: Windows NT/2K
Status: NEW
Severity: Blocker
Priority: Other
Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hello,
I've got something like this in my ant files:
zip destfile=${plugin.directory}/doc.zip basedir=${plugin.directory}
\transform.out.ad whenempty=fail
exclude name=*.xml/
/zip
and a zip file is still being created although there is nothing in it. I found
something on the internet saying that Zip.setWhenempty() has changed its
signature from 1.3 to 1.4. Is this attribute not fixed yet?
If so, please please fix this.
Thanks, Mandy
http://ntu.tw.freebsd.org/FreeBSD/ports/local-distfiles/znerd/jakarta-ant-
1.5.1/WHATSNEW
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
