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?
Bugger.
This workaround also fails.
Why? Transitive dependencies.
I am trying to internally release maven-assembly-plugin.
This is the extract of the dependencies graph from "mvn site"
Note the two instances of org.codehaus.plexus:plexus-archiver, one an
internal "-i" release.
org.apache.maven.plugins:maven-assembly-i-plugin:maven-plugin
* org.apache.maven:maven-archiver:jar
o org.codehaus.plexus:plexus-archiver:jar
* org.apache.maven.shared:maven-plugin-testing-tools-i:jar
o org.apache.maven.shared:maven-invoker-i:jar
* org.codehaus.plexus:plexus-archiver-i:jar
The problem is that there are now two duplicate class jars in the
graph because, obviously, plexus-archiver and plexus-archiver-i are
different artifactIds.
So this brings us down to one workaround, install and configure
mvnproxy for aggregate repositories.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
