On 2015-06-14, aalok singhvi wrote: > at org.apache.tools.ant.taskdefs.Delete.handle(Delete.java:720) > at org.apache.tools.ant.taskdefs.Delete.removeDir(Delete.java:769) > org.apache.tools.ant.taskdefs.Delete.removeDir(Delete.java:765) > org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:769) > org.apache.tools.ant.UnkownElement.execute(UnkownElement.java:291) > at sun.reflect.GeneratedMethodAccessor6.invoke( Unknown Source)
> Apache ant 1.7.0 https://github.com/apache/ant/blob/ANT_170/src/main/org/apache/tools/ant/taskdefs/Delete.java#L720 is inside the branch that deletes a directory, not a single file. And strangely there isn't even a line 769 in 1.7.0. And 769 is inside removeDir and execute at the same time? Strange. > As soon as build is done the main build file sets the classpath which > includes certain jars. Then this is a point where the jars may get locked - maybe there already is one before that. > Know what I am trying to do is before even importing those jars i am trying > to check if they were present in the project folder or not. > If they were delete them and copy newer version from a FTP location and > then set the classpath. I hope this makes sense. Yes, it does. If you want to do anything like that, then you must not build a classloader holding the jars before you try to relace them. Otherwise the JVM locks them and there is nothing Ant can do. And there is no way to force it, it is an OS level lock that Ant cannot lift. Is it possible you extract a small example build file that exhibits the problem and we can see whether we can improve it together so it works? Maybe open a Bugzilla issue for that since attaching files and trying patches back and force may be more convenient there. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@ant.apache.org For additional commands, e-mail: user-h...@ant.apache.org
