The migration guide is about plugins, not about libraries. For libraries it can be tricky.
However, based on https://mvnrepository.com/artifact/org.apache.maven.shared/maven-shared-io [https://mvnrepository.com/artifact/org.apache.maven.shared/maven-shared-io] the usage is quite low. There are several weird things: - It seems like this is not a Component (it is not annotated, not META-INF/plexus/components.xml contains it) - the constructor is only used in tests. This makes we wonder if we still need this project. If it can be removed from file-management(which we also might not need anymore either) and maven-assembly-plugin, I'd suggest to drop the repository. Robert On 2-7-2020 14:40:59, Elliotte Rusty Harold <[email protected]> wrote: 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 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]
