See http://www.nabble.com/forum/ViewPost.jtp?post=7884079&framed=y&skin=177 for full discussion.
The problem is that a plugin contains defects that have not yet been resolved in a release. The defect may be fixed in a snapshot version or there may be an unapplied patch available. The releases of your companies artifacts can't use snapshot versions and internally patched versions of the plugins needs to be made available to all developers. My original stab at providing process guidance around this is at http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins. Other people have attempted to follow this and have found shortcomings because the repository for all versions of an artifact is based on that last repository that had metadata for the artifact. e.g. internal_plugins and central both have metadata for plugin X, the repository is set to internal_plugins, which also contains the latest version, and then the repository reset to central. At this point the build process fails because central does not contain the specified version. I can't find any decent use cases for why you want an artifact to be available from multiple repositories. The two I can think of are 1) an artifact moves to another repository, e.g. codehaus to maven. In this case the artifiact id usuallu changes too from a form of <name>-maven-plugin to maven-<name>-plugin. So this problem would never have been noticed before. 2) you are creating an internal patch repository. The current work around is to change the artifactId as part of the plugin patching process. I would like the opinion of some maven-devs on this and whether it makes sense to support this better in maven, or to continue with the workarounds available. Thanks. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
