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.
IMHO, not knowing much about Maven, there's hardly a way we can enforce that
any artifact anywhere in the world occurs in only one repository. Therefore,
Maven needs to be robust about dealing with situations in which different
versions or a single artifact are found in different repositories. I don't
see how the renaming solution would work for a temporary scenario such as
the one found when patching artifacts. This is because chasing down
references and changing them could be very difficult and unnecessarily
burdensome.
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.
Absolutely my point. With OSS, there is bound to be a need to patch an
artifact for internal use before the patch becomes widely available. Just
take the metacase of patching maven itself to correctly resolve patched
artifacts. I would not want to wait until 2.0.6 for this to become
available. Therefore, INTERNAL patched projects are unavoidable at best.
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.
This is a no go based on my previous comment
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?
How about creating a patch for the maven-artifact-manager itself? That would
be a fix not a workaround.
Anyway, a workaround for a workaround sounds doubly bad if you ask me...
