[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516300#comment-17516300
]
Tamás Cservenák edited comment on MNG-7432 at 4/2/22 1:53 PM:
--------------------------------------------------------------
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps declared in profiles are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model already built with profile
applied due CLI`-PextraDeps`, instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolve it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolves within
Maven scope, this is true:
{{org.eclipse.aether.RepositorySystemSession#getWorkspaceReader insteanceof
MavenWorkspaceReader}} (and NEVER "raw" resolver specific WorkspaceReader).
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
from environment (system property set, file presence, etc) hence propagate,
while {{-P}} activator is explicitly given on CLI only, and does not propagate,
as expected.
was (Author: cstamas):
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps declared in profiles are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model already built with profile
applied due CLI`-PextraDeps`, instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolver it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolves within
Maven scope, this is true:
{{org.eclipse.aether.RepositorySystemSession#getWorkspaceReader insteanceof
MavenWorkspaceReader}} (and NEVER "raw" resolver specific WorkspaceReader).
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
from environment (system property set, file presence, etc) hence propagate,
while {{-P}} activator is explicitly given on CLI only, and does not propagate,
as expected.
> [REGRESSION] Dependencies from profile not picked up via -P<profileName>
> ------------------------------------------------------------------------
>
> Key: MNG-7432
> URL: https://issues.apache.org/jira/browse/MNG-7432
> Project: Maven
> Issue Type: Bug
> Affects Versions: 3.8.5
> Reporter: Falko Modler
> Priority: Critical
>
> The README of the following reproducer says it all:
> https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
> Initially discussed here:
> https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
