Found the problem. DefaultRepositoryMetadataManager.loadMetadata returns a boolean which indicates whether to set the repository (there are no javadocs for this class)
the setRepository flag is set based on the results of repoMetadata.getMetadata().merge( metadata ) and Metadata.merge() returns true if the metadata changed. Therefore since both internal_plugins and central have metadata available for the plugins both repositories cause the metadata to change and hence update the repository for the artifact. The ordering of repositories is unspecified so the order of which repository gets used for the artifact is also unspecified. In practice central is last so it always wins. This is something I will need to take onto the dev list to work out a way forward. I doubt anything will get fixed until 2.0.6 (since 2.0.5 is meant to be soon) Assuming that it is ok for multiple repositories to provide an artifact then the versioning information needs to include the repository that the version came from. Then instead of updating the repository based upon whether the metadata changed, the repository to be used should be based on version resolution and obtained from the versioning information. Having multiple repositories for an artifact is a big thing to assume. There are two reasons why this might occur; 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. Which is our current problem. The reason for the original wiki document was because there was no documentation that I could find that gave guidance on this and obviously few people are attempting it or there would be more complaints. Internal patched plugins are a necessity because the release process must not rely on snapshot versions. So are there workarounds? Yes. Change the artifactId, which makes it unique to your internal patch repository and the problem goes away. I would be suggestions maven-<original name>-internal-plugin. Problems with this approach. As long as the bindings are within pom.xml there aren't too many hassles. If the user is going to run the plugin on the command line then they will need to be educated on the new plugin name to use and when an official fully patched version arrives then they need to start using the official name again. Feedback on the workaround? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
