MSHARED-931 is a specific example of a problem I've run into in many plugins while trying to upgrade to Maven 3.
https://issues.apache.org/jira/projects/MSHARED/issues/MSHARED-931 Per https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies part of this work is to eliminate dependencies on maven-compat, an artifact that exists to bridge the differences between Maven 2 and Maven 3. However in maven-shared-io and many other plugins types defined in maven-compat are exposed on the public API surface. E.g. /** * @param factory {@link ArtifactFactory} * @param resolver {@link ArtifactResolver} * @param localRepository {@link ArtifactRepository} * @param remoteRepositories {@link ArtifactRepository} */ public ArtifactLocatorStrategy( ArtifactFactory factory, ArtifactResolver resolver, ArtifactRepository localRepository, List<ArtifactRepository> remoteRepositories ) Here ArtifactResolver comes from maven-compat. I can't remove the dependency on maven-compat without breaking the API. Transitively this means the maven-dependency-plugin also must depend on maven-compat. There are many other examples of this sort of problem. Tentatively, I think we should provide a non-deprecated replacement for ArtifactLocatorStrategy and deprecate the entire class. We'd release a version with both classes. and then delete it at head and release another version. Or perhaps if this class/package isn't widely used, we could simply deprecate and remove it without replacement. I'm not sure. But this is only one case of many, many dependencies on maven-compat. Thoughts? -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
