DO NOT REPLY [Bug 24169] New: - scp and sshexec failonerror documentation is reversed and wrong
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=24169. 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=24169 scp and sshexec failonerror documentation is reversed and wrong Summary: scp and sshexec failonerror documentation is reversed and wrong Product: Ant Version: 1.6Beta Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] From scp (sshexec is identical): failonerror Log a warning message, but do not stop the build, when the transfer does not work.No; defaults to true. The usual meaning of failonerror is whether to throw a buildexception if something goes wrong (when set to true) or just log a warning (when set to false). The code behaves according the usual meaning, so I think the message is just the wrong way around. (see tasks like cvs and mail for usual examples) sshexec failonerror doc is obviously a cut and paste needs correction anyway. scp should be something like: Whether to halt the build if the transfer fails. sshexec should be something like: Whether to halt the build if the command does not complete successfully. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24170] - failonerror does not work when sshexec task times out
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=24170. 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=24170 failonerror does not work when sshexec task times out --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 04:27 --- Created an attachment (id=8761) Proposed patch against v1.10 of SSHExec.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka ClassFileTest.java
antoine 2003/10/28 01:33:41
Modified:src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka
Tag: ANT_16_BRANCH ClassFileTest.java
Log:
Merge from HEAD
Revision ChangesPath
No revision
No revision
1.7.2.2 +2 -6
ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka/ClassFileTest.java
Index: ClassFileTest.java
===
RCS file:
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/optional/sitraka/ClassFileTest.java,v
retrieving revision 1.7.2.1
retrieving revision 1.7.2.2
diff -u -r1.7.2.1 -r1.7.2.2
--- ClassFileTest.java27 Oct 2003 18:32:13 - 1.7.2.1
+++ ClassFileTest.java28 Oct 2003 09:33:41 - 1.7.2.2
@@ -81,11 +81,7 @@
assertEquals(ClassFileTest.java, clazzfile.getSourceFile());
MethodInfo[] methods = clazzfile.getMethods();
assertEquals(3, methods.length);
-if (JavaEnvUtils.isJavaVersion(JavaEnvUtils.JAVA_1_2)) {
-assertHasMethod(void init(), 1, methods);
-} else {
-assertHasMethod(void init(), 2, methods);
-}
+assertHasMethod(void init(), 1, methods);
assertHasMethod(void testTwoLines(), 2, methods);
assertHasMethod(void testOneLine(), 3, methods);
}
@@ -95,7 +91,7 @@
for (int i = 0; i methods.length; i++) {
MethodInfo method = methods[i];
if (methodsig.equals(method.getFullSignature())) {
-
+
assertTrue(methodsig, method.getNumberOfLines() = line);
return;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24110] - Starteam disconnect
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=24110. 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=24110 Starteam disconnect [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam StarTeamLabel.java StarTeamTask.java TreeBasedTask.java
antoine 2003/10/28 01:56:26
Modified:src/main/org/apache/tools/ant/taskdefs/optional/starteam
StarTeamLabel.java StarTeamTask.java
TreeBasedTask.java
Log:
Solution for the Starteam disconnect bug
PR: 24110
Submitted by: Steve Cohen (scohen at apache dot org)
Revision ChangesPath
1.19 +24 -16
ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamLabel.java
Index: StarTeamLabel.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamLabel.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- StarTeamLabel.java2 Oct 2003 10:14:23 - 1.18
+++ StarTeamLabel.java28 Oct 2003 09:56:26 - 1.19
@@ -76,6 +76,7 @@
*
* @author Christopher Charlier, ThoughtWorks, Inc. 2001
* @author a href=mailto:[EMAIL PROTECTED]Jason Yip/a
+ * @author a href=mailto:[EMAIL PROTECTED]Steve Cohen/a
* @see A HREF=http://www.starbase.com/;StarBase Web Site/A
*
* @ant.task name=stlabel category=scm
@@ -179,25 +180,32 @@
+ both specified. A revision label cannot be a build
label.);
}
-View snapshot = openView();
+try {
+View snapshot = openView();
-// Create the new label and update the repository
+// Create the new label and update the repository
-if (this.revisionlabel) {
-new Label(snapshot, this.labelName, this.description).update();
-log(Created Revision Label + this.labelName);
-} else if (null != lastBuild) {
-new Label(snapshot, this.labelName, this.description,
this.lastBuild,
- this.buildlabel).update();
-log(Created View Label (
-+ (this.buildlabel ? : non-) + build) +
this.labelName
-+ as of + this.lastBuild.toString());
-} else {
-new Label(snapshot, this.labelName, this.description,
- this.buildlabel).update();
-log(Created View Label (
-+ (this.buildlabel ? : non-) + build) +
this.labelName);
+if (this.revisionlabel) {
+new Label(snapshot, this.labelName,
this.description).update();
+log(Created Revision Label + this.labelName);
+} else if (null != lastBuild) {
+new Label(snapshot, this.labelName, this.description,
this.lastBuild,
+ this.buildlabel).update();
+log(Created View Label (
++ (this.buildlabel ? : non-) + build) +
this.labelName
++ as of + this.lastBuild.toString());
+} else {
+new Label(snapshot, this.labelName, this.description,
+ this.buildlabel).update();
+log(Created View Label (
++ (this.buildlabel ? : non-) + build) +
this.labelName);
+}
+} catch (Exception e) {
+throw new BuildException(e);
+} finally {
+disconnectFromServer();
}
+
}
/**
1.12 +15 -1
ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamTask.java
Index: StarTeamTask.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamTask.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- StarTeamTask.java 9 Jul 2003 14:44:16 - 1.11
+++ StarTeamTask.java 28 Oct 2003 09:56:26 - 1.12
@@ -117,7 +117,7 @@
private void logStarteamVersion() {
log(StarTeam version:
-+ BuildNumber.getDisplayString(), Project.MSG_DEBUG);
++ BuildNumber.getDisplayString(), Project.MSG_VERBOSE);
}
@@ -318,6 +318,18 @@
}
/**
+ * disconnects from the StarTeam server. Should be called from the
+ * finally clause of every StarTeamTask-based execute method.
+ */
+protected final void disconnectFromServer() {
+if (null != this.server) {
+this.server.disconnect();
+log(successful disconnect from StarTeam Server + servername,
+Project.MSG_VERBOSE);
+}
+}
+
+/**
* returns a list of TypeNames known to the server.
*
* @return a reference to the server's TypeNames
@@ -362,6 +374,8 @@
}
View snapshot = createSnapshotView(view);
+log(Connected to StarTeam view + getURL(),
+Project.MSG_VERBOSE);
this.server =
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam StarTeamLabel.java StarTeamTask.java TreeBasedTask.java
antoine 2003/10/28 01:59:11
Modified:src/main/org/apache/tools/ant/taskdefs/optional/starteam
Tag: ANT_16_BRANCH StarTeamLabel.java
StarTeamTask.java TreeBasedTask.java
Log:
Merge from HEAD
PR: 24110
Submitted by: Steve Cohen (scohen at apache dot org)
Revision ChangesPath
No revision
No revision
1.16.2.3 +24 -16
ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamLabel.java
Index: StarTeamLabel.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamLabel.java,v
retrieving revision 1.16.2.2
retrieving revision 1.16.2.3
diff -u -r1.16.2.2 -r1.16.2.3
--- StarTeamLabel.java2 Oct 2003 10:15:15 - 1.16.2.2
+++ StarTeamLabel.java28 Oct 2003 09:59:11 - 1.16.2.3
@@ -76,6 +76,7 @@
*
* @author Christopher Charlier, ThoughtWorks, Inc. 2001
* @author a href=mailto:[EMAIL PROTECTED]Jason Yip/a
+ * @author a href=mailto:[EMAIL PROTECTED]Steve Cohen/a
* @see A HREF=http://www.starbase.com/;StarBase Web Site/A
*
* @ant.task name=stlabel category=scm
@@ -179,25 +180,32 @@
+ both specified. A revision label cannot be a build
label.);
}
-View snapshot = openView();
+try {
+View snapshot = openView();
-// Create the new label and update the repository
+// Create the new label and update the repository
-if (this.revisionlabel) {
-new Label(snapshot, this.labelName, this.description).update();
-log(Created Revision Label + this.labelName);
-} else if (null != lastBuild) {
-new Label(snapshot, this.labelName, this.description,
this.lastBuild,
- this.buildlabel).update();
-log(Created View Label (
-+ (this.buildlabel ? : non-) + build) +
this.labelName
-+ as of + this.lastBuild.toString());
-} else {
-new Label(snapshot, this.labelName, this.description,
- this.buildlabel).update();
-log(Created View Label (
-+ (this.buildlabel ? : non-) + build) +
this.labelName);
+if (this.revisionlabel) {
+new Label(snapshot, this.labelName,
this.description).update();
+log(Created Revision Label + this.labelName);
+} else if (null != lastBuild) {
+new Label(snapshot, this.labelName, this.description,
this.lastBuild,
+ this.buildlabel).update();
+log(Created View Label (
++ (this.buildlabel ? : non-) + build) +
this.labelName
++ as of + this.lastBuild.toString());
+} else {
+new Label(snapshot, this.labelName, this.description,
+ this.buildlabel).update();
+log(Created View Label (
++ (this.buildlabel ? : non-) + build) +
this.labelName);
+}
+} catch (Exception e) {
+throw new BuildException(e);
+} finally {
+disconnectFromServer();
}
+
}
/**
1.11.2.1 +15 -1
ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamTask.java
Index: StarTeamTask.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamTask.java,v
retrieving revision 1.11
retrieving revision 1.11.2.1
diff -u -r1.11 -r1.11.2.1
--- StarTeamTask.java 9 Jul 2003 14:44:16 - 1.11
+++ StarTeamTask.java 28 Oct 2003 09:59:11 - 1.11.2.1
@@ -117,7 +117,7 @@
private void logStarteamVersion() {
log(StarTeam version:
-+ BuildNumber.getDisplayString(), Project.MSG_DEBUG);
++ BuildNumber.getDisplayString(), Project.MSG_VERBOSE);
}
@@ -318,6 +318,18 @@
}
/**
+ * disconnects from the StarTeam server. Should be called from the
+ * finally clause of every StarTeamTask-based execute method.
+ */
+protected final void disconnectFromServer() {
+if (null != this.server) {
+this.server.disconnect();
+log(successful disconnect from StarTeam Server + servername,
+Project.MSG_VERBOSE);
+}
+}
+
+/**
* returns a list of TypeNames known to the server.
*
* @return a reference to the server's TypeNames
@@ -362,6 +374,8 @@
}
View snapshot = createSnapshotView(view);
+
DO NOT REPLY [Bug 24169] - scp and sshexec failonerror documentation is reversed and wrong
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=24169. 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=24169 scp and sshexec failonerror documentation is reversed and wrong [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Target Milestone|--- |1.6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/docs/manual/OptionalTasks scp.html sshexec.html
antoine 2003/10/28 02:33:40 Modified:docs/manual/OptionalTasks Tag: ANT_16_BRANCH scp.html sshexec.html Log: Merge from HEAD fix failonerror attribute of scp and ssh in the doc PR: 24169 Submitted by: Edwin Steele ( edwin_steele at rta dot nsw dot gov dot au) Revision ChangesPath No revision No revision 1.7.2.4 +1 -2 ant/docs/manual/OptionalTasks/scp.html Index: scp.html === RCS file: /home/cvs/ant/docs/manual/OptionalTasks/scp.html,v retrieving revision 1.7.2.3 retrieving revision 1.7.2.4 diff -u -r1.7.2.3 -r1.7.2.4 --- scp.html 16 Oct 2003 11:21:46 - 1.7.2.3 +++ scp.html 28 Oct 2003 10:33:40 - 1.7.2.4 @@ -70,8 +70,7 @@ /tr tr td valign=topfailonerror/td - td valign=topLog a warning message, but do not stop the build, - when the transfer does not work. + td valign=topWhether to halt the build if the transfer fails. /td td valign=top align=centerNo; defaults to true./td /tr 1.5.2.4 +1 -2 ant/docs/manual/OptionalTasks/sshexec.html Index: sshexec.html === RCS file: /home/cvs/ant/docs/manual/OptionalTasks/sshexec.html,v retrieving revision 1.5.2.3 retrieving revision 1.5.2.4 diff -u -r1.5.2.3 -r1.5.2.4 --- sshexec.html 16 Oct 2003 11:21:46 - 1.5.2.3 +++ sshexec.html 28 Oct 2003 10:33:40 - 1.5.2.4 @@ -64,8 +64,7 @@ /tr tr td valign=topfailonerror/td - td valign=topLog a warning message, but do not stop the build, - when the transfer does not work. + td valign=topWhether to halt the build if the command does not complete successfully. /td td valign=top align=centerNo; defaults to true./td /tr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24169] - scp and sshexec failonerror documentation is reversed and wrong
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=24169. 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=24169 scp and sshexec failonerror documentation is reversed and wrong [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 10:36 --- changes committed, thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24110] - Starteam disconnect
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=24110. 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=24110 Starteam disconnect --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 10:38 --- Thanks Ross and Steve (for reporting the problem and proposing a solution). Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/etc/testcases/taskdefs/optional dotnet.xml
On Fri, 24 Oct 2003, Steve Loughran [EMAIL PROTECTED] wrote: I guess there has to be an ilasm on the system, Yes, and it doesn't like the /(no)listing argument, it doesn't support /quiet either. we could patch the search to look for ilasm.exe only. There also is an ilasm.exe on Linux, so that wouldn#t help. ilasm is just this #!/bin/sh /usr/local/bin/mono /usr/local/bin/ilasm.exe $@ Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about MacroDef vs antcall
On Sat, 25 Oct 2003, Steve Cohen [EMAIL PROTECTED] wrote: Most of the smaller projects are usually (but not always) untouched, but they are touched just often enough that it is important for the master build to always build them. Maybe (just maybe) Ant 1.6 will help here as well, as directory scanning speed has improved a lot in certain configurations and scanning usually is where Ant spends its time when there is nothing to do. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ANT 1.6: Caught BuildExceptions with Ided datatypes
In my builds I have top level tasks like the ones bellow.
Notice the usage of ${build}/apps as the dir attribute for
the fileset/dirset. This file does not exists until some targets of
the build create this directory.
path id='all.xcomp'
pathelement location='${xcomp}'/
fileset dir='${build}/apps'
include name='*/xcomp'/
/fileset
/path
!-- All XCOMP directories --
path id='all.xcomp.dirs'
pathelement location='${xcomp}'/
dirset dir=${build}/apps
include name=**/xcomp/
/dirset
/path
Until 1.5.3 this was not a problem and the build worked correctly.
In 1.6b2 I get the following messages when the directory does not exist:
Buildfile: newbuild.xml
Caught exception (org.apache.tools.ant.BuildException) while expanding
all.xcomp: E:\projects\ant1_6-branch-20031018\pita\build\apps not found.
Caught exception (org.apache.tools.ant.BuildException) while expanding
all.xcomp.dirs: E:\projects\ant1_6-branch-20031018\pita\build\apps not
found.
This is while executing a target that has nothing to do with these
paths.
Although it seem to continue, the scarry part is that one does not know
if the path will be
are being actually damaged because of the early expansion. That would
mean that when
the path is actually used at the correct point in time, it will not
acomplish what it is suppose
to do (because it was evaluated too early).
Why am I getting this errors? Could this be a backward compatibility
issue?
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANT 1.6: Caught BuildExceptions with Ided datatypes
On Tue, 28 Oct 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: This is while executing a target that has nothing to do with these paths. Although it seem to continue, the scarry part is that one does not know if the path will be are being actually damaged It won't. Why am I getting this errors? Because the debug logging code invokes toString on the Path instance and this one will (try to) expand the FileSet. Could this be a backward compatibility issue? It's just a change in the logging, it really isn't as sever as it looks. Maybe we should lower the logging level to verbose or something. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam StarTeamTask.java
bodewig 2003/10/28 06:39:42 Modified:src/main/org/apache/tools/ant/taskdefs/optional/starteam StarTeamTask.java Log: 2003 Revision ChangesPath 1.13 +1 -1 ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamTask.java Index: StarTeamTask.java === RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamTask.java,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- StarTeamTask.java 28 Oct 2003 09:56:26 - 1.12 +++ StarTeamTask.java 28 Oct 2003 14:39:42 - 1.13 @@ -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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam StarTeamTask.java
bodewig 2003/10/28 06:41:05 Modified:src/main/org/apache/tools/ant/taskdefs/optional/starteam Tag: ANT_16_BRANCH StarTeamTask.java Log: 2003 Revision ChangesPath No revision No revision 1.11.2.2 +1 -1 ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamTask.java Index: StarTeamTask.java === RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam/StarTeamTask.java,v retrieving revision 1.11.2.1 retrieving revision 1.11.2.2 diff -u -r1.11.2.1 -r1.11.2.2 --- StarTeamTask.java 28 Oct 2003 09:59:11 - 1.11.2.1 +++ StarTeamTask.java 28 Oct 2003 14:41:05 - 1.11.2.2 @@ -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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional TraXLiaison.java
bodewig 2003/10/28 06:42:46
Modified:src/main/org/apache/tools/ant/taskdefs/optional Tag:
ANT_16_BRANCH TraXLiaison.java
Log:
Resolve entities inside the stylesheet as well, merge from HEAD
Revision ChangesPath
No revision
No revision
1.30.2.1 +9 -8
ant/src/main/org/apache/tools/ant/taskdefs/optional/TraXLiaison.java
Index: TraXLiaison.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/TraXLiaison.java,v
retrieving revision 1.30
retrieving revision 1.30.2.1
diff -u -r1.30 -r1.30.2.1
--- TraXLiaison.java 17 Sep 2003 20:11:43 - 1.30
+++ TraXLiaison.java 28 Oct 2003 14:42:46 - 1.30.2.1
@@ -64,6 +64,7 @@
import java.io.OutputStream;
import java.util.Vector;
import java.util.Enumeration;
+import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParserFactory;
import javax.xml.transform.ErrorListener;
import javax.xml.transform.Source;
@@ -86,6 +87,7 @@
import org.apache.tools.ant.util.JAXPUtils;
import org.xml.sax.EntityResolver;
import org.xml.sax.InputSource;
+import org.xml.sax.SAXException;
import org.xml.sax.XMLReader;
/**
@@ -199,7 +201,8 @@
* @return the configured source instance matching the stylesheet.
* @throws Exception if there is a problem creating the source.
*/
-private Source getSource(InputStream is, File infile) throws Exception {
+private Source getSource(InputStream is, File infile)
+throws ParserConfigurationException, SAXException {
// todo: is this comment still relevant ??
// FIXME: need to use a SAXSource as the source for the transform
// so we can plug in our own entity resolver
@@ -216,6 +219,8 @@
+ parser doesn't support SAX);
}
} else {
+// WARN: Don't use the StreamSource(File) ctor. It won't work
with
+// xalan prior to 2.2 because of systemid bugs.
src = new StreamSource(is);
}
src.setSystemId(JAXPUtils.getSystemId(infile));
@@ -226,9 +231,8 @@
* Read in templates from the stylesheet
*/
private void readTemplates()
-throws IOException, TransformerConfigurationException {
-// WARN: Don't use the StreamSource(File) ctor. It won't work with
-// xalan prior to 2.2 because of systemid bugs.
+throws IOException, TransformerConfigurationException,
+ ParserConfigurationException, SAXException {
// Use a stream so that you can close it yourself quickly
// and avoid keeping the handle until the object is garbaged.
@@ -239,10 +243,7 @@
xslStream
= new BufferedInputStream(new FileInputStream(stylesheet));
templatesModTime = stylesheet.lastModified();
-StreamSource src = new StreamSource(xslStream);
-// Always set the systemid to the source for imports, includes...
-// in xsl and xml...
-src.setSystemId(JAXPUtils.getSystemId(stylesheet));
+Source src = getSource(xslStream, stylesheet);
templates = getFactory().newTemplates(src);
} finally {
if (xslStream != null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML, XSL, and Ant
On Sat, 25 Oct 2003, Kyle Adams [EMAIL PROTECTED] wrote: And indeed it works quite nicely, for both resolving entities in a stylesheet, and resolving entities/dtds in anything xsl:import'ed, xsl:includ'ed and document()'ed. Great. The fix will be part of Ant 1.6 final. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24181] New: - Shutdown failing
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=24181. 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=24181 Shutdown failing Summary: Shutdown failing Product: Ant Version: 1.6Beta Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I press Ctrl-C to break an ant run and I get an InvocationTargetException, the root cause of which appears to be IllegalStateException: Shutdown in progress. This did not happen with the 1.5 version I was using previously. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about MacroDef vs antcall
--- Stefan Bodewig [EMAIL PROTECTED] wrote: directory scanning speed has improved a lot in certain configurations ... Stefan, could you point me to something that will elaborate on that statement? I hadn't noticed that in any of the 1.6 notes I've read... Thanks, Matt __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tale from the front: macrodef nesting
I have had a quick look at this.
It appears that the attributes as local properties
patch
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942
causes macrodef to behave in the way you expect.
A cut-down version shows this.
project
macrodef name=inner
attribute name=a/
attribute name=b/
sequential
echo name=a value=${a}/echo
echo name=b value=${b}/echo
/sequential
/macrodef
macrodef name=outer
attribute name=work/
attribute name=play/
element name=precompile optional=true/
element name=additional optional=true/
sequential
precompile/
additional/
/sequential
/macrodef
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=${work} b=${play} /
/precompile
/outer
/target
/project
Ant 1.6 currently outputs:
test.outer:
[echo] name=a value=${work}
[echo] name=b value=${play}
With the patch
this gets output:
test.outer:
[echo] name=a value=this is work
[echo] name=b value=this is play
Peter
On Sunday 26 October 2003 22:55, Steve Cohen wrote:
I am now trying to experiment with some of the new features of ant 1.6.
Here's a real-world example of the difficulties of trying to replace
antcalls with macrodefs.
Given the following definitions, notice that I am trying to nest a call to
the macrodef make.precompiled.web.xml inside a call to the macrodef
make.se.war.
This is failing because I am trying to use the ATTRIBUTE war.webxml inside
the ELEMENT precompile which contains a call to the nested macrodef
make.precompiled.web.xml.
I could easily fix this by substituting the actual value of the war.webxml
attribute for the ${war.webxml} token. But then I lose the advantage of
defining this in a single place.
Or I can create properties in the macrodef and pass them around, but that
feels wrong too.
Maybe there should be some mechanism for allowing inner macrodefs for
inheriting attributes from an outer macrodef. Maybe elements should be
able to be defined with nested attributes. Or something.
But this experience with trying to use this feature leads me to the feeling
that using the same notation for macrodef attributes and ant properties is
not a good thing. It will definitely cause confusion. At a minimum more
documentation of this is required.
macrodef name=make.precompiled.web.xml
attribute name=src.web.xml/
attribute name=dest.web.xml/
sequential
ant antfile=${basedir}/se/build-precomp.xml
target=create.precompiled.web.xml
property name=src.web.xml value=${src.web.xml}/
property name=dest.web.xml value=${dest.web.xml}/
/ant
/sequential
/macrodef
macrodef name=make.se.war
attribute name=work.dir/
attribute name=war.webxml/
attribute name=war.basedir/
attribute name=war.destfile/
element name=precompile optional=true/
element name=assemble optional=false/
element name=additional optional=true/
sequential
delete dir=${work.dir}/
mkdir dir=${work.dir}/temp/
mkdir dir=${work.dir}/war/
precompile/
assemble/
replace file=${war.webxml}
token=#build#
value=${project.version}.${project.maintenance.build}.${project.fix.build}
/ war destfile=${war.destfile}
webxml=${war.webxml}
basedir=${war.basedir}
additional/
/war
/sequential
/macrodef
target name=make.admin.war
depends=make.precompilation
make.se.war
work.dir=${dir.admin.ear}
war.webxml=${dir.build.precomp.webxml}/${admin.web.xml}
war.basedir=${dir.admin.ear}/temp
war.destfile=${dir.admin.ear}/war/${admin.war}
precompile
make.precompiled.web.xml
src.web.xml=${dir.src.web.xmls}/${admin.web.xml}
dest.web.xml=${war.webxml}
/
/precompile
assemble
copy todir=${war.basedir}
fileset dir=${dir.build.war.precomp}/
/copy
/assemble
/make.se.war
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about MacroDef vs antcall
On Tue, 28 Oct 2003, Matt Benson [EMAIL PROTECTED] wrote: --- Stefan Bodewig [EMAIL PROTECTED] wrote: directory scanning speed has improved a lot in certain configurations Stefan, could you point me to something that will elaborate on that statement? Apart from the cvs commits and some discussion on this list, I'm afraid there isn't too much. The most important changes started on July 14th (Antoine's change to DirectoryScanner) and things have settled down about two week later. In a nutshell, the scanner will now detect situations like includes=a/b/c/d/** and not scan any directories that are not below d at all. The old code would start with the base directory of the file set and at least scan a, a/b and a/b/c even though it never needed the results of the scans. So you'll notice a speedup of all scanning operations for filesets that contain include patterns with constant path prefixes. In particular you'll notice a big speedup for filesets that don't match on wildcards at all (i.e. where all include patterns are complete paths). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Echo.java
peterreilly2003/10/28 08:54:56
Modified:src/main/org/apache/tools/ant/taskdefs Echo.java
Log:
checkstyle
Revision ChangesPath
1.30 +10 -0 ant/src/main/org/apache/tools/ant/taskdefs/Echo.java
Index: Echo.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Echo.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- Echo.java 13 Sep 2003 12:58:33 - 1.29
+++ Echo.java 28 Oct 2003 16:54:56 - 1.30
@@ -116,6 +116,8 @@
/**
* File to write to.
+ * @param file the file to write to, if not set, echo to
+ * standard output
*/
public void setFile(File file) {
this.file = file;
@@ -123,6 +125,8 @@
/**
* If true, append to existing file.
+ * @param append if true, append to existing file, default
+ * is false.
*/
public void setAppend(boolean append) {
this.append = append;
@@ -130,6 +134,7 @@
/**
* Set a multiline message.
+ * @param msg the CDATA text to append to the output text
*/
public void addText(String msg) {
message += getProject().replaceProperties(msg);
@@ -146,6 +151,7 @@
* /ul
* pThe default is quot;warningquot; to ensure that messages are
* displayed by default when using the -quiet command line option./p
+ * @param echoLevel the logging level
*/
public void setLevel(EchoLevel echoLevel) {
String option = echoLevel.getValue();
@@ -163,9 +169,13 @@
}
}
+/**
+ * The enumerated values for the level attribute.
+ */
public static class EchoLevel extends EnumeratedAttribute {
/**
* @see EnumeratedAttribute#getValues
+ * @return the strings allowed for the level attribute
*/
public String[] getValues() {
return new String[] {error, warning, info,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tale from the front: macrodef nesting
From: peter reilly [mailto:[EMAIL PROTECTED]
It appears that the attributes as local properties
patch
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942
causes macrodef to behave in the way you expect.
A cut-down version shows this.
project
Let me add:
property name=a value=AAA /
property name=b value=BBB /
macrodef name=inner
attribute name=a/
attribute name=b/
sequential
echo name=a value=${a}/echo
echo name=b value=${b}/echo
/sequential
/macrodef
macrodef name=outer
attribute name=work/
attribute name=play/
element name=precompile optional=true/
element name=additional optional=true/
sequential
precompile/
additional/
/sequential
/macrodef
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=${work} b=${play} /
/precompile
/outer
/target
/project
Ant 1.6 currently outputs:
test.outer:
[echo] name=a value=${work}
[echo] name=b value=${play}
With the patch
this gets output:
test.outer:
[echo] name=a value=this is work
[echo] name=b value=this is play
Peter
What's the output now, with the addition?
I assume currently property 'a' and 'b' are simply ignored and the output
you show above Peter doesn't change w/ or w/out the patch. This behavior has
a name, and it's *variable hiding* (properties here in fact), and it's not a
recommended behavior.
As a user of Ant pre-macrodef, I would expect the output to be (with my
addition):
test.outer:
[echo] name=a value=AAA
[echo] name=b value=BBB
And without it:
[echo] name=a value=${a}
[echo] name=b value=${b}
Of course, one would then need a new notation to de-reference the attributes
of the macrodef... Exactly what was rejected in the first place.
Adding this new notation for macrodef attributes disambiguates regular
property de-references, from the macro's attributes, once and for all.
As far as using the local patch, yes, it does make sense as you show above,
but it still doesn't solve the point I've been trying to make from the get
go, and that apparently everybody else simply dismisses. --dD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tale from the front: macrodef nesting
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
From: peter reilly [mailto:[EMAIL PROTECTED]
It appears that the attributes as local properties
patch
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942
causes macrodef to behave in the way you expect.
A cut-down version shows this.
project
Let me add:
property name=a value=AAA /
property name=b value=BBB /
I think a more compelling argument for variable hiding is what would
happen
if one have instead:
property name=work value=AAA /
property name=play value=BBB /
with this properties, there is no way on earth that one can justfy why
the
following two lines are not equivalent in the expansion of the target:
inner a=${work} b=${play} /
inner a=AAA b=BBB /
macrodef name=inner
attribute name=a/
attribute name=b/
sequential
echo name=a value=${a}/echo
echo name=b value=${b}/echo
/sequential
/macrodef
macrodef name=outer
attribute name=work/
attribute name=play/
element name=precompile optional=true/
element name=additional optional=true/
sequential
precompile/
additional/
/sequential
/macrodef
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=${work} b=${play} /
/precompile
/outer
/target
/project
Ant 1.6 currently outputs:
test.outer:
[echo] name=a value=${work}
[echo] name=b value=${play}
With the patch
this gets output:
test.outer:
[echo] name=a value=this is work
[echo] name=b value=this is play
Peter
What's the output now, with the addition?
I assume currently property 'a' and 'b' are simply ignored
and the output you show above Peter doesn't change w/ or
w/out the patch. This behavior has a name, and it's *variable
hiding* (properties here in fact), and it's not a recommended
behavior.
As a user of Ant pre-macrodef, I would expect the output to
be (with my
addition):
test.outer:
[echo] name=a value=AAA
[echo] name=b value=BBB
And without it:
[echo] name=a value=${a}
[echo] name=b value=${b}
Of course, one would then need a new notation to de-reference
the attributes of the macrodef... Exactly what was rejected
in the first place.
Adding this new notation for macrodef attributes
disambiguates regular property de-references, from the
macro's attributes, once and for all.
As we have gone on this discussion before, I do not think in your
example we are doing actual bad variable hidding. What we are doing
is applying static scoping rules for attributes. That is, a local
variable (attribute) is hidding access (statically) to a global
variable (property). This is what we do on every structured prog.
language.
That is, a and b change meaning only inside the static context
of the macro.
In my variant, the variable hidding occurs outside the context of the
macrodef
that is I am doing an expansion of a property on a target and somehow
I get the value defined in a macrodef that may not even know what it
does
(it could have come in an antlib, or an import).
Jose Alberto
As far as using the local patch, yes, it does make sense as
you show above, but it still doesn't solve the point I've
been trying to make from the get go, and that apparently
everybody else simply dismisses. --dD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tale from the front: macrodef nesting
On Tuesday 28 October 2003 17:39, Dominique Devienne wrote:
From: peter reilly [mailto:[EMAIL PROTECTED]
It appears that the attributes as local properties
patch
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942
causes macrodef to behave in the way you expect.
A cut-down version shows this.
project
Let me add:
property name=a value=AAA /
property name=b value=BBB /
macrodef name=inner
attribute name=a/
attribute name=b/
sequential
echo name=a value=${a}/echo
echo name=b value=${b}/echo
/sequential
/macrodef
macrodef name=outer
attribute name=work/
attribute name=play/
element name=precompile optional=true/
element name=additional optional=true/
sequential
precompile/
additional/
/sequential
/macrodef
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=${work} b=${play} /
/precompile
/outer
/target
/project
Ant 1.6 currently outputs:
test.outer:
[echo] name=a value=${work}
[echo] name=b value=${play}
With the patch
this gets output:
test.outer:
[echo] name=a value=this is work
[echo] name=b value=this is play
Peter
What's the output now, with the addition?
I assume currently property 'a' and 'b' are simply ignored and the output
you show above Peter doesn't change w/ or w/out the patch. This behavior
has a name, and it's *variable hiding* (properties here in fact), and it's
not a recommended behavior.
Something like *variable hiding* would be needed to support local
properties - unless one used another notation was used for local
properties (Costin suggested local: as a prefix for local properties).
This is Stefan's argument - local properties should not
have dynamic extent. This makes the *variable hiding* much worse. However
this does occur currently with antcall target=tparam a=AAA//antcall.
Peter
As a user of Ant pre-macrodef, I would expect the output to be (with my
addition):
test.outer:
[echo] name=a value=AAA
[echo] name=b value=BBB
And without it:
[echo] name=a value=${a}
[echo] name=b value=${b}
Of course, one would then need a new notation to de-reference the
attributes of the macrodef... Exactly what was rejected in the first
place.
Adding this new notation for macrodef attributes disambiguates regular
property de-references, from the macro's attributes, once and for all.
As far as using the local patch, yes, it does make sense as you show above,
but it still doesn't solve the point I've been trying to make from the get
go, and that apparently everybody else simply dismisses. --dD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19964] - system property for a default timeout for tests
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=19964.
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=19964
system property for a default timeout for tests
--- Additional Comments From [EMAIL PROTECTED] 2003-10-28 18:44 ---
With ant 1.6 (beta currently) you can use presetdef
Example:
presetdef name=my.junit
junit timeout=${junit.timeout}/
/presetdef
Then where you have junit in your ant file, change to my.junit
http://ant.apache.org/manual-1.6beta/CoreTasks/presetdef.html
Recommend for closing.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20207] - enhance telnet task to be able to gather read outputs into a property
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20207. 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=20207 enhance telnet task to be able to gather read outputs into a property --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 18:48 --- Possible solution is to use loadfile on the output file from get and then delete output file. http://ant.apache.org/manual/CoreTasks/loadfile.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20207] - enhance telnet task to be able to gather read outputs into a property
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20207. 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=20207 enhance telnet task to be able to gather read outputs into a property --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 18:52 --- Forget my comment. I mis-read this. These are not the droids you are looking for. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21414] - Bugzilla Report Generator 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=21414. 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=21414 Bugzilla Report Generator Task --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 19:05 --- fyi: changing show_bug.cgi to xml.cgi will output XML with bugzilla. http://issues.apache.org/bugzilla/xml.cgi?id=21414 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24193] New: - [PATCH] Example of using move to append .bak to files does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24193. 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=24193 [PATCH] Example of using move to append .bak to files does not work Summary: [PATCH] Example of using move to append .bak to files does not work Product: Ant Version: 1.6Beta Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] move todir=my/src/dir fileset dir=my/src/dir exclude name=**/*.bak/ /fileset mapper type=glob from=* to=*.bak/ /move as recommended by move.html does not work in case there are subdirectories in my/src/dir - they are given the backup extension too, which is surely not what was wanted. Need to specify includeemptydirs=false - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24193] - [PATCH] Example of using move to append .bak to files does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24193. 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=24193 [PATCH] Example of using move to append .bak to files does not work --- Additional Comments From [EMAIL PROTECTED] 2003-10-28 22:51 --- Created an attachment (id=8787) Suggested patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24194] New: - csc ignores includes attribute
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=24194. 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=24194 csc ignores includes attribute Summary: csc ignores includes attribute Product: Ant Version: 1.6Beta Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Optional Tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have tree .cs files in one directory. When I execute csc scrDir=some/dir includes=one-file.cs.../ it builds all three of them. ant -v shows that csc checks all three files whether they are up to date. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24196] New: - When the drive letter of a mapped network drive is not explicitly specified in a path element, the location of the path element is indeterminate to the java task (and perhaps to other tasks, too).
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=24196.
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=24196
When the drive letter of a mapped network drive is not explicitly specified in
a path element, the location of the path element is indeterminate to the java
task (and perhaps to other tasks, too).
Summary: When the drive letter of a mapped network drive is not
explicitly specified in a path element, the location of
the path element is indeterminate to the java task (and
perhaps to other tasks, too).
Product: Ant
Version: 1.5.4
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
When running the following build.xml from a folder on a mapped drive (e.g.
H:/projects/test/build.xml):
?xml version=1.0 encoding=UTF-8?
project basedir=. default=test name=test
path id=test.path
pathelement location=${basedir}/jars/ant.jar/
/path
target name=test
echo message=Path does not work across a mapped network drive??? /
java classname=org.apache.tools.ant.Main fork=true
classpath refid=test.path/
arg value=-help /
/java
/target
/project
The following error message is output:
test:
[echo] Path does not work across a mapped network drive???
[java] java.lang.NoClassDefFoundError: org.apache.tools.ant.Main
[java] Exception in thread main
[java] Java Result: 1
BUILD FAILED
The basedir variable of the project is set to the current folder (.), and the
path element is built relatively from the basedir variable. The current folder
exists on a mapped network drive, but the mapped network drive letter is not
specified in the relative path. In this scenario, it appears that the location
of the path element is indeterminate to the java task (and perhaps to other
Ant tasks as well). I think that the task should derive the drive letter
programatically when relative file paths are used and the drive letter is not
specified in the relative path.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
