[
https://issues.apache.org/jira/browse/MNG-7706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-7706:
---------------------------------
Description:
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).
was:
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)!
> 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: 4.0.0, 4.0.0-alpha-5, 3.9.1
>
>
> 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)
