Community
Participate
Working Groups
If you generate, then try to delete the tigerstripe.gen folder, then eclipse won't let you! Restart and you can delete them merrily! I imagine the files are not being properly released/closed when they are generated.
I cannot delete any files that are being written using the API either... I imported a UML profile, and got the same errors as below when I tried to delete that.
Eric can't reporduce - downgrading dependant on more testing!
Created attachment 136428 [details] ts-documentation.velocity.log, generated in project target directory Hello, I think we have reproduced it in our tip doc plugin. The file ts-documentation.velocity.log is not closed properly and so the clean-up cannot be done. It is not possible either to delete manually this file right away. Only after exiting and restartign Eclipse, it can be done. Note that this file contain an exception which is likely to be the reason for the fact the file is left open. Couldn't find class org.apache.velocity.runtime.log.AvalonLogChute or necessary supporting classes in classpath. java.lang.NoClassDefFoundError: org/apache/log/format/Formatter Best regards, Marc
I experience the same behavior when developing the TIP soap plugin. I do a manual delete. And almost 100% of the time within minute after running the plugin the deletion (Eclipse) fails on deleting the plugin log file (not velocity). It probably is the log file closing issue as I even had the file open in Eclipse and the file still being updated after the plugin execution had finished.
The issue is with the velocity log files that cannot be deleted on Windows after generation is complete. After spending a long time debugging this and looking through the Velocity Engine code, I noticed that the log files were being closed in the 'finalize' method of the LogChute in the Velocity Framework. This is not a good practice, since there is no control over when JVM's garbage collection is executed. Thus the reason why this issue is intermittent. It will work fine if garbage collection runs before the files are deleted and it will fail on Windows if the stream is left open and the user attempts to delete the files. There are no public APIs to retrieve the LogChute so it can be shutdown manually. To resolve this issue, I created a custom Logger so I can have control over when it's shut down. Tigerstripe now manually shuts down the logger and doesn't rely on Velocity Framework to close the stream. Modified files: TemplateBasedRule ArtifactBasedTemplateRule GlobalTemplateRule ModelTemplateRule The reason why this worked fine on Linux/Mac is because these operating systems have the ability to forcefully delete a file despite open streams on the file.
