I think we can remove it from the maven-assembly-pluign by copying two or three classes into that plugin and making them non-public.
On Thu, Jul 2, 2020 at 5:05 PM Robert Scholte <[email protected]> wrote: > > 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] > -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
