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]
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
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]
