Re: delete task for antlib jars
On Fri, 13 Feb 2004, Mariano Benitez [EMAIL PROTECTED] wrote: that is why it makes more sense to me to define it as deleteOnExit, But what do we display to the user here? Failed to delete but we will try again after Ant has finished - please check whether the file is still there after that, if so, the build has failed. Unless you set quiet to true, failing to delete a file is supposed to break the build. I don't see how we can predict that the failure is non-critical, whether deleteOnExit will work or not. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: delete task for antlib jars
I meant an option to delete, not altering the default behaviour, If you are sure you are using that file, delete it on exit explicitly. MAriano Stefan Bodewig wrote: On Fri, 13 Feb 2004, Mariano Benitez [EMAIL PROTECTED] wrote: that is why it makes more sense to me to define it as deleteOnExit, But what do we display to the user here? Failed to delete but we will try again after Ant has finished - please check whether the file is still there after that, if so, the build has failed. Unless you set quiet to true, failing to delete a file is supposed to break the build. I don't see how we can predict that the failure is non-critical, whether deleteOnExit will work or not. Stefan - 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: delete task for antlib jars
On Mon, 16 Feb 2004, Mariano Benitez [EMAIL PROTECTED] wrote: I meant an option to delete, not altering the default behaviour, If you are sure you are using that file, delete it on exit explicitly. Works for me. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: delete task for antlib jars
are you ok that I send you the patch? shall I create a bug in bugzilla for this? MAriano Stefan Bodewig wrote: On Mon, 16 Feb 2004, Mariano Benitez [EMAIL PROTECTED] wrote: I meant an option to delete, not altering the default behaviour, If you are sure you are using that file, delete it on exit explicitly. Works for me. Stefan - 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: delete task for antlib jars
Mariano Benitez wrote: are you ok that I send you the patch? shall I create a bug in bugzilla for this? MAriano Stefan Bodewig wrote: On Mon, 16 Feb 2004, Mariano Benitez [EMAIL PROTECTED] wrote: I meant an option to delete, not altering the default behaviour, If you are sure you are using that file, delete it on exit explicitly. Will this work recursivly? I.e. when deleteing a directory Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: delete task for antlib jars
have to look at the java documentation and give it a try, if you want I can try it with different scenarios, adding testCases would be too much for me, I have enough with the ones I need for my own product :) MAriano Peter Reilly wrote: Mariano Benitez wrote: are you ok that I send you the patch? shall I create a bug in bugzilla for this? MAriano Stefan Bodewig wrote: On Mon, 16 Feb 2004, Mariano Benitez [EMAIL PROTECTED] wrote: I meant an option to delete, not altering the default behaviour, If you are sure you are using that file, delete it on exit explicitly. Will this work recursivly? I.e. when deleteing a directory Peter - 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]
delete task for antlib jars
Hi! I am using antlibs, and I face the normal problem in windows of not being able of deleting the file while it is used. I know this discussion must have probably taken place, I could not just find it :( Has there been any attempt to use File.deleteOnExit() as an option for the task? or another task? MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: delete task for antlib jars
Mariano Benitez wrote: Hi! I am using antlibs, and I face the normal problem in windows of not being able of deleting the file while it is used. I know this discussion must have probably taken place, I could not just find it :( Has there been any attempt to use File.deleteOnExit() as an option for the task? or another task? Alternatively, we may need a way to unload an antlib - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: delete task for antlib jars
From: Steve Loughran [mailto:[EMAIL PROTECTED] Mariano Benitez wrote: Hi! I am using antlibs, and I face the normal problem in windows of not being able of deleting the file while it is used. I know this discussion must have probably taken place, I could not just find it :( Has there been any attempt to use File.deleteOnExit() as an option for the task? or another task? Alternatively, we may need a way to unload an antlib Why does the antlib file or JAR would stay open beyond loading the classes and reading the antlib.xml? Maybe what is needed here, is a way to tell ALL AntClassLoaders to please close their open files (JARS) and reopen if needed later. After all, keeping the JARs open is just an optimization. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: delete task for antlib jars
Maybe what is needed here, is a way to tell ALL AntClassLoaders to please close their open files (JARS) and reopen if needed later. After all, keeping the JARs open is just an optimization. Sounds like a flag ant -releaselibs ant.jar junit.jar Jan
RE: delete task for antlib jars
Or a small task that can be called at the right time on your build before deleting. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 13 February 2004 11:14 To: [EMAIL PROTECTED] Subject: RE: delete task for antlib jars Maybe what is needed here, is a way to tell ALL AntClassLoaders to please close their open files (JARS) and reopen if needed later. After all, keeping the JARs open is just an optimization. Sounds like a flag ant -releaselibs ant.jar junit.jar Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: delete task for antlib jars
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] Why does the antlib file or JAR would stay open beyond loading the classes and reading the antlib.xml? Maybe what is needed here, is a way to tell ALL AntClassLoaders to please close their open files (JARS) and reopen if needed later. After all, keeping the JARs open is just an optimization. Well, after reading the antlib.xml, sure you could close the JAR, but once a URLClassLoader from the JDK starts using classes from the JAR (and most likely even before that), that JAR will stay open so it's not swapped under the JVM. I know for sure the Linux JVM memory-maps those JARs in the process address space, and it's very possible the Windows VM does something similar (thus the lock on the JAR file). I'm not sure Ant wants to go into the business of writing some custom ClassLoader that would not exhibit this 'standard' behavior of SUN's JDKs... --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: delete task for antlib jars
that is why it makes more sense to me to define it as deleteOnExit, and not mess with trying to unload an antlib when I don't want it anymore. MAriano Dominique Devienne wrote: From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] Why does the antlib file or JAR would stay open beyond loading the classes and reading the antlib.xml? Maybe what is needed here, is a way to tell ALL AntClassLoaders to please close their open files (JARS) and reopen if needed later. After all, keeping the JARs open is just an optimization. Well, after reading the antlib.xml, sure you could close the JAR, but once a URLClassLoader from the JDK starts using classes from the JAR (and most likely even before that), that JAR will stay open so it's not swapped under the JVM. I know for sure the Linux JVM memory-maps those JARs in the process address space, and it's very possible the Windows VM does something similar (thus the lock on the JAR file). I'm not sure Ant wants to go into the business of writing some custom ClassLoader that would not exhibit this 'standard' behavior of SUN's JDKs... --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: delete task for antlib jars
From: Dominique Devienne [mailto:[EMAIL PROTECTED] From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] Why does the antlib file or JAR would stay open beyond loading the classes and reading the antlib.xml? Maybe what is needed here, is a way to tell ALL AntClassLoaders to please close their open files (JARS) and reopen if needed later. After all, keeping the JARs open is just an optimization. Well, after reading the antlib.xml, sure you could close the JAR, but once a URLClassLoader from the JDK starts using classes from the JAR (and most likely even before that), that JAR will stay open so it's not swapped under the JVM. I know for sure the Linux JVM memory-maps those JARs in the process address space, and it's very possible the Windows VM does something similar (thus the lock on the JAR file). I'm not sure Ant wants to go into the business of writing some custom ClassLoader that would not exhibit this 'standard' behavior of SUN's JDKs... We already wrote a Custom classloader, and it already exhibit non-standard behavior. And they are already registered at least as an event listener. So they could as well register for a please close your files events as well. If the file disapears and classes cannot be loaded after that, then it should just throw a ClassNotFoundException or whatever. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
