[
https://issues.apache.org/jira/browse/MNG-7706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717271#comment-17717271
]
ASF GitHub Bot commented on MNG-7706:
-------------------------------------
basil commented on PR #1012:
URL: https://github.com/apache/maven/pull/1012#issuecomment-1525911551
> on `ProjectBuildingRequest` `setSession` from 2
The `setSession` method does not exist, but a `setRepositorySession` exists.
But why should I call that when `session.getProjectBuildingRequest()` already
calls it a few lines above?
> Deprecate ${localRepository} mojo parameter expression
> ------------------------------------------------------
>
> Key: MNG-7706
> URL: https://issues.apache.org/jira/browse/MNG-7706
> Project: Maven
> Issue Type: Improvement
> Components: Core
> Reporter: Tamas Cservenak
> Assignee: Tamas Cservenak
> Priority: Major
> Fix For: 3.9.1, 4.0.0-alpha-5, 4.0.0
>
>
> The mojo parameter expression 'localRepository' injects type
> {{ArtifactRepository}} that is part of the suite coming from Maven2 (predates
> Mercury, that was superseded by Aether, today Maven Resolver).
> The problem with this interface is that it is not compatible (nor is possible
> to adapt it) to Maven Resolver LocalRepositoryManager due lack of context.
> Also, the use of this interface in Mojos causes issues like MNG-7663, as they
> fully (and blindly) re-implement Maven local repository with *wired in*
> layout.
> Moreover, Mojos using this expression are usually dragging other (legacy)
> deprecated things as well, most typically maven-artifact-transfer, or
> maven-dependency-tree and so on, all things that predates Maven 3.1 (are done
> to "protect" from Aether package change happened between Maven 3.0 and Maven
> 3.1). Today baseline for plugins is 3.2.5, so none of these "indirection" are
> needed anymore. In fact, the use of this expression is very good sign of
> legacy and technical debt present in given plugin. And also, these plugins
> cripple Maven to adopt new features. This warning is a clear indicator for
> legacy or neglected plugins.
> The type {{ArtifactRepository}} is used in Maven internally (most in
> maven-compat, a bit less in maven-core), this is telling as well, but IMHO
> there is no need to deprecate this interface, as:
> * plugins who migrate from this ancient interface to Resolver will have much
> simpler job with maven 4 API (as it is much closer to Resolver than old Maven
> APIs)
> * this tackles only Plugins, while Maven itself is fine, as post Maven 4 the
> internals will be shut off, so warning Mojo authors is enough
> * still, we should look into core where and why is this type used for
> * deprecate localRepository used of {{ArtifactRepository}} type on
> following: {{{}MavenExecutionRequest{}}}, {{MavenSession}} and
> {{ProjectBuildingRequest}} as instance created for these are effectively not
> used (and are created "too early" and they carry repository system session
> anyway
> If a Mojo gets this WARNING, how should it be fixed?
> * presence of parameter {{{}$\{localRepository{}}}} (with presence of type
> ArtifactReposiory) usually means following things: Mojo uses maven-compat
> Maven2 compatibility layer, OR uses some deprecated libraries (most prominent
> example is maven-artifact-transfer). Both are technical debts, and remedy is
> to switch code to use current APIs.
> * second most often reason for parameter is access to the base directory of
> local repository. In this case {{RepositorySystemSession}} should be injected
> instead, use expression {{{}$\{repositorySystemSession{}}}} and get the
> LocalRepositoryManager (LRM) from it. Word of warning: in most cases you DO
> NOT want the base directory of local repository, as since Maven 3.9.0 the
> layout of it is not fixed. If you want to access contents of local
> repository, you *must use LRM APIs instead* (this is actually true since
> Maven 3.0.x)!
> If user is stuck with plugin that issues this warning, user still can use it,
> but should avoid use of any advanced (split, etc) local repository features,
> available since 3.9.0. Inevitably, the deprecated APIs (maven-compat, etc)
> will get removed in the future, so if no way to update the Mojo, user should
> plan to migrate to some alternative solution (to buy out the affected Mojo).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
