Re: maven-compat in public API

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: maven-compat in public API

rfscholte
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 <[hidden email]> 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
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven-compat in public API

Elliotte Rusty Harold
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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]