[
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:13 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 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 does not implement
MavenWorkspaceReader while newly added MavenChainedWorkspaceReader does ->
SOLVES the issue, as resolver will "come back" to reactor workspace reader and
get the model WITH PROFILE ALREADY APPLIED with `-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 resolvers
within Maven scope, this is true: {{WSR insteanceof MavenWorkspaceReader}} and
not "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
of "environment" (system property set, file presence) 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 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 thought)
* The problem is that Resolver ChainedWorkspaceReader does not implement
MavenWorkspaceReader while newly added MavenChainedWorkspaceReader does ->
SOLVES the issue, as resolver will "come back" to reactor workspace reader and
get the model WITH PROFILE ALREADY APPLIED with `-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 resolvers
within Maven scope, this is true: {{WSR insteanceof MavenWorkspaceReader}} and
not "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
of "environment" (system property set, file presence) 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)
