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