buildStarted/Finished and subbuilds
Hi all, while investigating bug 8689 I realized that the Ant project instances we create in Ant never fire the build started or finished events. I'm not entirely sure that this is a good thing (but it probably is), but we probably can't change it for backwards compatibility reasons anyway. This has a couple of consequences, one of them causes the excess memory needed in AntClassLoader. If a task in the subbuild creates an AntClassLoader instance it never gets cleaned up since the subproject never calls build finished. Another one is that any record task used in the subbuild could leave open files hanging around until Ant exits. For what I propose below, I'll also have to add a close method to RecorderEntry. Since I don't think we can fix the build* events for subbuilds, I plan to do some things in ant after the subbuild has finished: * remove all build listeners of the main project from the subbuild. * iterate over the remaining build listeners of the subbuild and a) invoke cleanup() if it is an AntClassLoader b) invoke close() if it is a RecorderEntry this is ugly, but any clean solution I could come up with is not backwards compatible (add a dispose method to BuildListener, make subbuilds fire buildFinished ...). Any better ideas? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: buildStarted/Finished and subbuilds
The clean up you propose sounds very good. As regards whether the ant family tasks should fire build started and finished events. One may see these for subant, and ant but not for antcall (or at least the way it is used by some scripts as a sub-routine call). In any case, as you say, it cannot be changed for backwards compatibility reasons. Peter Stefan Bodewig wrote: Hi all, while investigating bug 8689 I realized that the Ant project instances we create in Ant never fire the build started or finished events. I'm not entirely sure that this is a good thing (but it probably is), but we probably can't change it for backwards compatibility reasons anyway. This has a couple of consequences, one of them causes the excess memory needed in AntClassLoader. If a task in the subbuild creates an AntClassLoader instance it never gets cleaned up since the subproject never calls build finished. Another one is that any record task used in the subbuild could leave open files hanging around until Ant exits. For what I propose below, I'll also have to add a close method to RecorderEntry. Since I don't think we can fix the build* events for subbuilds, I plan to do some things in ant after the subbuild has finished: * remove all build listeners of the main project from the subbuild. * iterate over the remaining build listeners of the subbuild and a) invoke cleanup() if it is an AntClassLoader b) invoke close() if it is a RecorderEntry this is ugly, but any clean solution I could come up with is not backwards compatible (add a dispose method to BuildListener, make subbuilds fire buildFinished ...). Any better ideas? 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: buildStarted/Finished and subbuilds
Stefan Bodewig wrote: this is ugly, but any clean solution I could come up with is not backwards compatible (add a dispose method to BuildListener, make subbuilds fire buildFinished ...). Any better ideas? Sounds OK. The only alternative I could think of (without checking whether it is feasible) would be to create BuildListener2 and add something like ProjectStarted/ProjectFinished to it. These would be called in Project.executeTargets for any BuildListeners which also implement BuildListener2. Would that be better than checking for AntClassLoaders explicitly? Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: buildStarted/Finished and subbuilds
On Wed, 23 Jun 2004, Conor MacNeill [EMAIL PROTECTED] wrote: The only alternative I could think of (without checking whether it is feasible) would be to create BuildListener2 and add something like ProjectStarted/ProjectFinished to it. These would be called in Project.executeTargets for any BuildListeners which also implement BuildListener2. Unfortunately this wouldn't help. * RecorderEntry wants to write something to the file in buildFinished, if we close the file in projectFinished, this would try to write to a closed file in the main build. * Similar, AntClassLoaders used in the master build would be cleaned as soon as the subbuild finishes since it is registered as a build listener for the subbuild as well. This would be way too early. Would that be better than checking for AntClassLoaders explicitly? Anything that works would be better 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: buildStarted/Finished and subbuilds
Stefan Bodewig wrote: On Wed, 23 Jun 2004, Conor MacNeill [EMAIL PROTECTED] wrote: Unfortunately this wouldn't help. * RecorderEntry wants to write something to the file in buildFinished, if we close the file in projectFinished, this would try to write to a closed file in the main build. * Similar, AntClassLoaders used in the master build would be cleaned as soon as the subbuild finishes since it is registered as a build listener for the subbuild as well. This would be way too early. Well, you could still take the approach of removing the main build listeners and then fire a SubBuildFinished on all the remaining listeners that are BuildListener2. Pretty similar to your original without hardcoding a specific class in there, which may let other build listeners do useful stuff at the end of a subbuild. I wonder if we should have separate lists for objects just to listen to their project and not events from subbuilds. Really we have overloaded the event interface to provide a cleanup mechanism. Probably too much work to separate them. Just to note that cleanup should be safe to call on the AntClassLoaders at any time if not necessarily optimal for performance. If that is not true, I'm not sure you can be safe cleaning them up at sub-build finished time :-) Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: buildStarted/Finished and subbuilds
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Hi all, while investigating bug 8689 I realized that the Ant project instances we create in Ant never fire the build started or finished events. I'm not entirely sure that this is a good thing (but it probably is), but we probably can't change it for backwards compatibility reasons anyway. This has a couple of consequences, one of them causes the excess memory needed in AntClassLoader. If a task in the subbuild creates an AntClassLoader instance it never gets cleaned up since the subproject never calls build finished. Another one is that any record task used in the subbuild could leave open files hanging around until Ant exits. For what I propose below, I'll also have to add a close method to RecorderEntry. Since I don't think we can fix the build* events for subbuilds, I plan to do some things in ant after the subbuild has finished: * remove all build listeners of the main project from the subbuild. * iterate over the remaining build listeners of the subbuild and a) invoke cleanup() if it is an AntClassLoader b) invoke close() if it is a RecorderEntry this is ugly, but any clean solution I could come up with is not backwards compatible (add a dispose method to BuildListener, make subbuilds fire buildFinished ...). Any better ideas? How about defining a new interface SubBuildListener when ant iterates over the listeners if it finds one implementing this interface it will call its finish() event or (some new method). Here AntClassLoader and RecorderEntry will implement this new interface. This looks like a more generic solution that other things can use if so they desire. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: buildStarted/Finished and subbuilds
On Thu, 24 Jun 2004, Conor MacNeill [EMAIL PROTECTED] wrote: Well, you could still take the approach of removing the main build listeners and then fire a SubBuildFinished on all the remaining listeners that are BuildListener2. Yes, much like what Jose Alberto describes later. This would mean triggering the events from within ant and not from Project#executeTarget. subProjectStarted may be interesting for some kinds of build listeners as well. subBuild or subProject? subBuild is closer to buildStarted/Finished. Another thing that just occured to me is that AntClassLoader should check the BuildEvent to see whether the firing project is the same it has been registered with and only cleanup itself if it is. This way we don't have to worry about removing the master build build listeners before subProjectFinished is fired. I wonder if we should have separate lists for objects just to listen to their project and not events from subbuilds. Listeners can look into the BuildEvent if this matters, we've jsut never told anybody that it could matter. Not sure when we started to send BuildListeners down to the subbuilds, but it hasn't been always that way - so things like record simply don't take it into account. Really we have overloaded the event interface to provide a cleanup mechanism. True. Just to note that cleanup should be safe to call on the AntClassLoaders at any time if not necessarily optimal for performance. cleanup nulls out the project reference which disturbs logging, Gump specific handling of the context classloader and addPathElement which is used by classloader. If that is not true, I'm not sure you can be safe cleaning them up at sub-build finished time :-) That would only be classloaders created in the subbuild. No object created in the subbuild should be able to reach the main build, so we are pretty save - except for spawned threads. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
