Managing plugin versions using dependencyManagement?
Dear Colleagues, Is there a way to centrally control the version of a plugin by specifying something like dependencyManagement in top-level project pom so the plugin versions are not specified in all sub-module poms? Reading archives suggest this is not possible but I wanted to make sure. TIA for your help. -- Regards, Farrukh Najmi Web: http://www.wellfleetsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing plugin versions using dependencyManagement?
Use pluginManagement in your parent POM ! 2008/4/3, Farrukh Najmi [EMAIL PROTECTED]: Dear Colleagues, Is there a way to centrally control the version of a plugin by specifying something like dependencyManagement in top-level project pom so the plugin versions are not specified in all sub-module poms? Reading archives suggest this is not possible but I wanted to make sure. TIA for your help. -- Regards, Farrukh Najmi Web: http://www.wellfleetsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing plugin versions using dependencyManagement?
Yes, the pluginManagement tag will do this. Of course if you change the setting in a parent pom, all the child poms need to be updated to point to the new parent pom before this will take effect. If the child modules point to different versions of the parent pom, then they will still be using different versions of the plugin. I personally think using pluginManagement to impose the same version on a bunch of other modules is a bad idea anyway. You cannot control what plugin versions are used by third-party libraries - and don't care, right? So why try to impose this on your own code? If a module successfully builds and passes its unit tests with version X of a plugin then why does it matter if this is not the latest version, or is different from the version used by something else? Of course if you have a company policy of using only specific approved versions of libs or plugins, then the way to achieve that is to set up your own repository with only the allowed artifacts in it, and then use that instead of the public repos (using mirrorOf*/mirrorOf). Regards, Simon nicolas de loof schrieb: Use pluginManagement in your parent POM ! 2008/4/3, Farrukh Najmi [EMAIL PROTECTED]: Dear Colleagues, Is there a way to centrally control the version of a plugin by specifying something like dependencyManagement in top-level project pom so the plugin versions are not specified in all sub-module poms? Reading archives suggest this is not possible but I wanted to make sure. TIA for your help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing plugin versions using dependencyManagement?
The issue is not to force usage of any corporate-validated plugin (I'm using some timestamped SNAPSHOTS), but to ensure the project will be reproductible even when new version of the plugins si released. Some of us got issues when surefire 2.4 was released, and test didn't pass anymore. This was not a bug, as this was cleary documented in surefire release note. Nico.. 2008/4/3, [EMAIL PROTECTED] [EMAIL PROTECTED]: Yes, the pluginManagement tag will do this. Of course if you change the setting in a parent pom, all the child poms need to be updated to point to the new parent pom before this will take effect. If the child modules point to different versions of the parent pom, then they will still be using different versions of the plugin. I personally think using pluginManagement to impose the same version on a bunch of other modules is a bad idea anyway. You cannot control what plugin versions are used by third-party libraries - and don't care, right? So why try to impose this on your own code? If a module successfully builds and passes its unit tests with version X of a plugin then why does it matter if this is not the latest version, or is different from the version used by something else? Of course if you have a company policy of using only specific approved versions of libs or plugins, then the way to achieve that is to set up your own repository with only the allowed artifacts in it, and then use that instead of the public repos (using mirrorOf*/mirrorOf). Regards, Simon nicolas de loof schrieb: Use pluginManagement in your parent POM ! 2008/4/3, Farrukh Najmi [EMAIL PROTECTED]: Dear Colleagues, Is there a way to centrally control the version of a plugin by specifying something like dependencyManagement in top-level project pom so the plugin versions are not specified in all sub-module poms? Reading archives suggest this is not possible but I wanted to make sure. TIA for your help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Managing plugin versions using dependencyManagement?
I personally think using pluginManagement to impose the same version on a bunch of other modules is a bad idea anyway. You cannot control what plugin versions are used by third-party libraries - and don't care, right? So why try to impose this on your own code? If a module successfully builds and passes its unit tests with version X of a plugin then why does it matter if this is not the latest version, or is different from the version used by something else? This is the completely not what we suggest. First of all you don't care what 3rd parties use for plugins as those plugins are only used in their build, not yours. Assuming you see their jar, then their build succeeded. If you don't lock down your plugin versions, then you are subjected to plugin changes over time and your builds won't be reproducible. Further, if you haven't specified a preference, then there's no way to ensure consistency across your team. We have addressed the random plugin updates in 2.0.9 by specifying default versions for plugins but we still recommend that you take control of the plugin versions yourself. This way you will be able to go back and build a version at some point in the future and changing Maven versions won't upgrade all your plugins at once. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
