Community
Participate
Working Groups
Hello, in 2.1 M3 I noticed some annoying Ant behaviour that did't occur in previous releases, at least I can't remember it. I have a project in which I develop some Ant tasks. There are several build.xml files in this project for testing purposes. (1) In older releases of Eclipse (up to 2.0.2) I was able to change something to the tasks' implementations, then run a build.xml file and see my latest changes to the code, that is, use my lastest version of the tasks. (2) With the new Eclipse, it seems Ant tasks are never unloaded once they have been in use. At least my changes never make it into Ant until I restart the whole Eclipse. I have the impression that Ant is now started in the same JVM as Eclipse. While this makes sense from a performance point of view and is also ok for most cases, it's a problem when you are developing Ant tasks, because the classes can't be unloaded. I understand that you might not want the "spawning" behaviour as default any more, so how about a checkbox "Start Ant in its own JVM" in the Ant launch configuration for a specific build.xml file?
The Ant integration in Eclipse has always run in the same VM. The problem is that now the Ant classloader is cached and therefore your tasks are not reloaded. We need to address this problem. It could be as simple as adding an option to not reuse the Ant classloader. The current workaround is to make a "change" to the Ant classpath as this will cause the cached classloader to be discarded. We have bug 24129 for the separate VM enhancement.
You can now set a launch configuration to not reuse the classloader with the global classpath OR you can set a specific classpath for a classloader that will be recreated it build. See the Classpath tab in the launch configuration dialog for Ant. Please verify Luc.
Verified. Please update the build notes (DarinS).
