RE: A possible solution for conditional execution of tasks?
My opinion regarding the disadvantages of this approach: * Antcall has to create a whole new Project in memory in order to work and is therefore an inefficient task * If something invoked via Antcall depends on a target that is also depended on by something depending on the target invoking Antcall then this dependency target will be executed more than once because dependencies are not handled across Antcall invocations * The dependency tree is interrupted and graphing tools that can show ant build script structures will not (generally) work correctly and show the whole dependency tree It might be better to add if and unless to the standard ant Task to allow for conditional execution, or even add a nested condition to the standard ant Task to allow for conditional execution. To provide BC with the standard execute method, the condition/if/unless processing would need to happen outside this method. Phil :n. -Original Message- From: Sandip Chitale [mailto:[EMAIL PROTECTED] Sent: Sat 28/05/2005 18:56 To: dev@ant.apache.org Cc: Subject: A possible solution for conditional execution of tasks? To conditionally execute a step in Ant one has to resort to setting up a target structure like this: : target name=predicate condition property=condition-satisfied available .../ : /condition /target target name=conditional-step if=condition-satisfied !-- conditional tasks here -- : : /target target name=conditional depends=predicate, conditional-step/ target name=main depends=conditional : : /target : This is because of several reasons: * The ant tasks do not have something like *if* attribute. * One cannot get away with only two targets instead of three because the dependencies are executed before the dependent. Using the above example it is not possible to do what target predicate does in the main target and avoid using the predicate target. * Ensure order of execution However, I tried a solution making use of antcall task and it worked. It works as follows: : target name=conditional-step if=condition-satisfied !-- conditional tasks here -- : : /target target name=main depends=conditional-step : condition property=condition-satisfied available .../ : /condition antcall target=condition-satisfied/ : /target The advantage of this approach is to quickly have some tasks execute conditionally by putting them in a target and calling that target using antcall after setting some property. And it seemed to work. My question is - is there a problem using this approach? Why or why isn't this a preferred approach? Thanks in advance, Sandip
DO NOT REPLY [Bug 30548] - NPE in oata.Project when executing emma task from netbeans.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30548. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30548 --- Additional Comments From [EMAIL PROTECTED] 2005-05-29 12:25 --- I later on found out, that this had partly to do with the clean up code in the ant-bridge of NB 3.6. Looks like the ant-bridge is trying to prevent memory leaks by forcing some of the ANT-Internal variables to 'null' via reflection API. (Possible only, if there is no security manager, or security manager permissions are set accordingly). So anyway, this isn't ANTs fault, but could be considered a blatand breach of ANTs isolation by Netbeans... The problem vanished in NB 4.0. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 30548] - NPE in oata.Project when executing emma task from netbeans.
[EMAIL PROTECTED] schrieb: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30548. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30548 --- Additional Comments From [EMAIL PROTECTED] 2005-05-29 12:25 --- I later on found out, that this had partly to do with the clean up code in the ant-bridge of NB 3.6. Looks like the ant-bridge is trying to prevent memory leaks by forcing some of the ANT-Internal variables to 'null' via reflection API. (Possible only, if there is no security manager, or security manager permissions are set accordingly). So anyway, this isn't ANTs fault, but could be considered a blatand breach of ANTs isolation by Netbeans... The problem vanished in NB 4.0. As an after thought: NB resorting to a means like this might indicate, that integrating ANT into another application has its difficulties with house keeping. I'm not good at ANTs internals, and don't know if something alike is already there, but maybee it would be of help for IDEs like NB, if there was an explicitly defined lifecycle for all important ANT Objects, namely Projects, Targets, and Tasks, including a cleanUp() method, releasing internal resources. Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A possible solution for conditional execution of tasks?
Phil Weighill-Smith wrote: My opinion regarding the disadvantages of this approach: * Antcall has to create a whole new Project in memory in order to work and is therefore an inefficient task Yes. If the project is large this could be a large overhead. It seems the semantics of antcall is not like a sub target but more like a target in a sub project (even though the project happens to be the same project). Is there a more lightweight solution planned in this area? * If something invoked via Antcall depends on a target that is also depended on by something depending on the target invoking Antcall then this dependency target will be executed more than once because dependencies are not handled across Antcall invocations Yes. * The dependency tree is interrupted and graphing tools that can show ant build script structures will not (generally) work correctly and show the whole dependency tree I did not think about the graphing tools, but that is a good point also. Given the fact that you did not list any advantages it seems this is not a good idea. It might be better to add if and unless to the standard ant Task to allow for conditional execution, or even add a nested condition to the standard ant Task to allow for conditional execution. To provide BC with the standard execute method, the condition/if/unless processing would need to happen outside this method. This seems like this is the real answer. However I read somewhere that it is an architectural decision to not support if and unless etc. at the task level. Can anyone point me to a discussion/document on that? What about using scripting? Is that not recommended either? Google search revealed that many people are looking for solutions for similar problems. Regards, Sandip Phil :n. -Original Message- From: Sandip Chitale [mailto:[EMAIL PROTECTED] Sent: Sat 28/05/2005 18:56 To: dev@ant.apache.org Cc: Subject: A possible solution for conditional execution of tasks? To conditionally execute a step in Ant one has to resort to setting up a target structure like this: : target name=predicate condition property=condition-satisfied available .../ : /condition /target target name=conditional-step if=condition-satisfied !-- conditional tasks here -- : : /target target name=conditional depends=predicate, conditional-step/ target name=main depends=conditional : : /target : This is because of several reasons: * The ant tasks do not have something like *if* attribute. * One cannot get away with only two targets instead of three because the dependencies are executed before the dependent. Using the above example it is not possible to do what target predicate does in the main target and avoid using the predicate target. * Ensure order of execution However, I tried a solution making use of antcall task and it worked. It works as follows: : target name=conditional-step if=condition-satisfied !-- conditional tasks here -- : : /target target name=main depends=conditional-step : condition property=condition-satisfied available .../ : /condition antcall target=condition-satisfied/ : /target The advantage of this approach is to quickly have some tasks execute conditionally by putting them in a target and calling that target using antcall after setting some property. And it seemed to work. My question is - is there a problem using this approach? Why or why isn't this a preferred approach? Thanks in advance, Sandip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A possible solution for conditional execution of tasks?
There is the option to use the conditional task (if) from ant-contrib... this allows the nesting of a sequential task which itself can contain any tasks you want. -Original Message- From: Sandip Chitale [mailto:[EMAIL PROTECTED] Sent: Sun 29/05/2005 16:06 To: Ant Developers List Cc: Subject: Re: A possible solution for conditional execution of tasks? Phil Weighill-Smith wrote: My opinion regarding the disadvantages of this approach: * Antcall has to create a whole new Project in memory in order to work and is therefore an inefficient task Yes. If the project is large this could be a large overhead. It seems the semantics of antcall is not like a sub target but more like a target in a sub project (even though the project happens to be the same project). Is there a more lightweight solution planned in this area? * If something invoked via Antcall depends on a target that is also depended on by something depending on the target invoking Antcall then this dependency target will be executed more than once because dependencies are not handled across Antcall invocations Yes. * The dependency tree is interrupted and graphing tools that can show ant build script structures will not (generally) work correctly and show the whole dependency tree I did not think about the graphing tools, but that is a good point also. Given the fact that you did not list any advantages it seems this is not a good idea. It might be better to add if and unless to the standard ant Task to allow for conditional execution, or even add a nested condition to the standard ant Task to allow for conditional execution. To provide BC with the standard execute method, the condition/if/unless processing would need to happen outside this method. This seems like this is the real answer. However I read somewhere that it is an architectural decision to not support if and unless etc. at the task level. Can anyone point me to a discussion/document on that? What about using scripting? Is that not recommended either? Google search revealed that many people are looking for solutions for similar problems. Regards, Sandip Phil :n. -Original Message- From: Sandip Chitale [mailto:[EMAIL PROTECTED] Sent: Sat 28/05/2005 18:56 To: dev@ant.apache.org Cc: Subject: A possible solution for conditional execution of tasks? To conditionally execute a step in Ant one has to resort to setting up a target structure like this: : target name=predicate condition property=condition-satisfied available .../ : /condition /target target name=conditional-step if=condition-satisfied !-- conditional tasks here -- : : /target target name=conditional depends=predicate, conditional-step/ target name=main depends=conditional : : /target : This is because of several reasons: * The ant tasks do not have something like *if* attribute. * One cannot get away with only two targets instead of three because the dependencies are executed before the dependent. Using the above example it is not possible to do what target predicate does in the main target and avoid using the predicate target. * Ensure order of execution However, I tried a solution making use of antcall task and it worked. It works as follows: : target name=conditional-step if=condition-satisfied !-- conditional tasks here -- : : /target target name=main depends=conditional-step : condition property=condition-satisfied available .../ : /condition antcall target=condition-satisfied/ : /target The advantage of this approach is
How to write a JUnit test for this new functionality?
Neeme Praks has sent me an interesting patch that allows the ftp task
to execute with a certain number of retries specified. That is, it
won't fail until the specified number of retries has passed.
I want to write some JUnit tests to test this patch. My idea was to
simulate failure by subclassing the FTP task class
(o.a.t.a.taskdefs.optional.net.FTP) within the JUnit test with a version
that allows setting a numberOfFailuresToSimulate member, and a modified
transferFiles() method that would, if numberOfFailuresToSimulate 0,
simply decrement this value by 1 and throw a dummy BuildException,
otherwise, simply execute the regular transferFiles. This seems like a
good way to test Neeme's retry handler. Then this can be tested with a
build file that specifies the number of retry times, and the test can
then illustrate what happens with this buildfile when numbers , , or
== to the specified number of simulated failures occur.
To wit:
private static class myRetryableFTP extends FTP {
private int numberOfFailuresToSimulate;
int getNumberOfFailuresToSimulate() {
return numberOfFailuresToSimulate;
}
void setNumberOfFailuresToSimulate(int numberOfFailuresToSimulate) {
this.numberOfFailuresToSimulate = numberOfFailuresToSimulate;
}
protected int transferFiles(FTPClient ftp, FileSet fs)
throws IOException, BuildException
{
if (this.numberOfFailuresToSimulate 0) {
this.numberOfFailuresToSimulate--;
throw new BuildException(Simulated failure for testing);
}
return super.transferFiles(ftp, fs);
}
}
However, my knowledge of Ant internals is somewhat limited. How can I
tell an ant project in my test code that when it sees an ftp tag, it
should delegate the performance of this task to myRetryableFTP, instead
of to the standard FTP as it would normally do? Is there an example of
this sort of thing within the existing Ant test suite?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to write a JUnit test for this new functionality?
Steve Cohen wrote: However, my knowledge of Ant internals is somewhat limited. How can I tell an ant project in my test code that when it sees an ftp tag, it should delegate the performance of this task to myRetryableFTP, instead of to the standard FTP as it would normally do? Is there an example of this sort of thing within the existing Ant test suite? . project.addTaskDefinition(ftp, MyRetryableFtp.class) ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to write a JUnit test for this new functionality?
Stephane Bailliez wrote: Steve Cohen wrote: However, my knowledge of Ant internals is somewhat limited. How can I tell an ant project in my test code that when it sees an ftp tag, it should delegate the performance of this task to myRetryableFTP, instead of to the standard FTP as it would normally do? Is there an example of this sort of thing within the existing Ant test suite? . project.addTaskDefinition(ftp, MyRetryableFtp.class) ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks. I found something else that works, using ComponentHelper, but this seems simpler. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/docs/manual/OptionalTasks ftp.html
scohen 2005/05/29 17:40:21
Modified:src/testcases/org/apache/tools/ant/taskdefs/optional/net
FTPTest.java
src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
src/etc/testcases/taskdefs/optional/net ftp.xml
docs/manual/OptionalTasks ftp.html
Added: src/main/org/apache/tools/ant/util Retryable.java
RetryHandler.java
Log:
Based on a patch submitted by Neeme Praks, allow support for a retry count on
FTP transfers. Some
servers are unreliable for unknown - this allows for a retry count to be
specified to accomodate work on such
flaky servers.
Revision ChangesPath
1.1 ant/src/main/org/apache/tools/ant/util/Retryable.java
Index: Retryable.java
===
/*
* Copyright 2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
package org.apache.tools.ant.util;
import java.io.IOException;
/**
* Simple interface for executing a piece of code. Used for writing anonymous
inner
* classes in FTP task for retry-on-IOException behaviour.
*
* @see RetryHandler
*/
public interface Retryable {
public static final int RETRY_FOREVER = -1;
void execute() throws IOException;
}
1.1 ant/src/main/org/apache/tools/ant/util/RetryHandler.java
Index: RetryHandler.java
===
/*
* Copyright 2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
package org.apache.tools.ant.util;
import java.io.IOException;
import org.apache.tools.ant.Project;
import org.apache.tools.ant.Task;
/**
* A simple utility class to take a piece of code (that implements
* codeRetryable/code interface) and executes that with possibility to
* retry the execution in case of IOException.
*/
public class RetryHandler {
private int retriesAllowed = 0;
private Task task;
/**
* Create a new RetryingHandler.
*
* @param retriesAllowed how many times to retry
* @param task the Ant task that is is executed from, used for logging
only
*/
public RetryHandler(int retriesAllowed, Task task) {
this.retriesAllowed = retriesAllowed;
this.task = task;
}
/**
* Execute the codeRetryable/code code with specified number of
retries.
*
* @param exe the code to execute
* @param desc some descriptive text for this piece of code, used for
logging
* @throws IOException if the number of retries has exceeded the allowed
limit
*/
public void execute(Retryable exe, String desc) throws IOException {
int retries = 0;
while (true) {
try {
exe.execute();
break;
} catch (IOException e) {
retries++;
if (retries this.retriesAllowed this.retriesAllowed
-1) {
task.log(try # + retries + : IO error (
+ desc + ), number of maximum retries reached (
+ this.retriesAllowed + ), giving up,
Project.MSG_WARN);
throw e;
} else {
task.log(try # + retries + : IO error ( + desc + ),
retrying, Project.MSG_WARN);
}
}
}
}
}
1.19 +86 -0
ant/src/testcases/org/apache/tools/ant/taskdefs/optional/net/FTPTest.java
Index: FTPTest.java
===
RCS file:
cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/net FTPTest.java
scohen 2005/05/29 19:18:39
Modified:src/testcases/org/apache/tools/ant/taskdefs/optional/net
FTPTest.java
Log:
improve new test
Revision ChangesPath
1.20 +2 -2
ant/src/testcases/org/apache/tools/ant/taskdefs/optional/net/FTPTest.java
Index: FTPTest.java
===
RCS file:
/home/cvs/ant/src/testcases/org/apache/tools/ant/taskdefs/optional/net/FTPTest.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- FTPTest.java 30 May 2005 00:40:20 - 1.19
+++ FTPTest.java 30 May 2005 02:18:39 - 1.20
@@ -829,7 +829,7 @@
public static class randomFailureFTP extends myRetryableFTP {
public randomFailureFTP() {
-super(new Random(3).nextInt());
+super(new Random().nextInt(Short.MAX_VALUE));
}
}
public void testGetWithSelectorRetryable1() {
@@ -858,7 +858,7 @@
}
}
public void testGetWithSelectorRetryableRandom() {
-getProject().addTaskDefinition(ftp, threeFailureFTP.class);
+getProject().addTaskDefinition(ftp, randomFailureFTP.class);
try {
getProject().setProperty(ftp.retries, forever);
getProject().executeTarget(ftp-get-with-selector-retryable);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33443] - FTP GET from Windows Server does not work if FTP site uses MS-DOS style listing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33443. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33443 --- Additional Comments From [EMAIL PROTECTED] 2005-05-30 04:27 --- Please supply more details. What version of Ant was this reported with? What version of the jakarta-commons-net library were you using? This sounds like something that should have been fixed if you were using Ant =1.6.2 and Jakarta-commons Net = 1.2.2. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31124] - enhancement to FTP task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31124. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31124 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-05-30 04:31 --- Couldn't you first copy the file to a temporary location on the client machine, rename it there, then PUT the renamed file onto the server? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33443] - FTP GET from Windows Server does not work if FTP site uses MS-DOS style listing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33443. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33443 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26887] - FTP ability to synchronise
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26887. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26887 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-05-30 04:37 --- As Steve Loughran has said, there are other ways to solve your use case outside of the FTP task. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
