Re: Cleaning up Maven's caches after plugin:install
I often edit in-place in the plugin directory and copy back to the source directory when finished. But that's just me being lazy. I started out this way with beta7, but the new goal caching mechanism in beta8 seemed to defeat this approach for us. This seemed especially error-prone if you added or renamed goals in your "live" plugin.jelly. With beta8 we found it was better to get in the habit of using plugin:install to ensure consistent registration of the plugin's revised goals. Yep. Renaming goals / adding goal etc will not be detected until you flush the caches. Modified jelly script will be picked up straight away (well... as soon as maven restarts) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cleaning up Maven's caches after plugin:install
> [snippage] > > plugin will be registered and work properly. I have encapsulated this > logic > > into the following postgoal: > [snip code] > I've committed the change to the plugin:install. Wow, thanks! Honestly, I wasn't sure if deleting the caches out from underneath Maven was really safe. But, Maven seemed to treat the situation gracefully, so we kept it. I could imagine that there might be some runtime data structures that need to cleaned up or reinitialized as well so that they stay in sync with the caches. Any thoughts on this? I suppose a test case could be written to test for plugin reinstallation more formally: - plugin:install a plugin that defines some goals, let's say goalA and goalB. - verify that goalA and goalB can be attained - plugin:install a revised version of the same plugin that redefines goalA, does not define goalB, and defines a new goalC. - verify that goalA and goalC are attained properly, and goalA is the version from the revised plugin - verify that goalB no longer exists and cannot be attained. > I often edit in-place in the plugin directory and copy back to the source > directory when finished. But that's just me being lazy. I started out this way with beta7, but the new goal caching mechanism in beta8 seemed to defeat this approach for us. This seemed especially error-prone if you added or renamed goals in your "live" plugin.jelly. With beta8 we found it was better to get in the habit of using plugin:install to ensure consistent registration of the plugin's revised goals. -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cleaning up Maven's caches after plugin:install
"David Zeleznik" <[EMAIL PROTECTED]> wrote on 05/03/2003 07:50:31 AM: > Hi, > > I am developing some plugins that we will use internally across a variety of > projects that we are migrating to Maven. As a result, I am constantly > testing these plugins by invoking the "plugin:install" goal. However, I have I know that feeling :) [snippage] > plugin will be registered and work properly. I have encapsulated this logic > into the following postgoal: [snip code] I've committed the change to the plugin:install. > So far, this is working well for us. But, I am curious whether there is a > better approach for handling the iterative development, installation, and > testing of plugins. I often edit in-place in the plugin directory and copy back to the source directory when finished. But that's just me being lazy. Anyone else? -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cleaning up Maven's caches after plugin:install
Hi, I am developing some plugins that we will use internally across a variety of projects that we are migrating to Maven. As a result, I am constantly testing these plugins by invoking the "plugin:install" goal. However, I have noticed from time to time that some goals in the new version of the plugin do not work properly with Maven because the Maven's various caches contain old info. I wish that I could provide a more definitive test scenario than this, but hopefully you get the idea. In the meantime, I have found that if I delete all of the *.cache and .processed files from Maven's plugin directory tree, I am guaranteed that the goals of the new version of the plugin will be registered and work properly. I have encapsulated this logic into the following postgoal: This postgoal also guarantees 2 other issues I found: - If I have eliminated files from my plugin, the postgoal guarantees that they are also eliminated from the plugin's expansion directory. - If I change the version number of my plugin, the postgoal properly deletes any previous version from the plugins directory and thereby avoids conflicts. So far, this is working well for us. But, I am curious whether there is a better approach for handling the iterative development, installation, and testing of plugins. -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
