ascheman commented on issue #12288:
URL: https://github.com/apache/maven/issues/12288#issuecomment-4733085989

   @gnodet @slawekjaranowski — two follow-up questions to round out the issue:
   
   ### 1. Warning for the remaining activation channels?
   
   Earlier in this thread I had offered a warning variant as a 
behavior-preserving alternative for the `<activeByDefault>` case:
   
   > Would you accept a smaller alternative: emit a WARN when a profile has 
`<activeByDefault>true</activeByDefault>` + non-empty `<properties>` but its id 
is not in `<activeProfiles>` / not CLI-activated? I have a local prototype that 
does that in ~12 lines without behavior change; the warning text points the 
user directly to the two supported activation channels […]
   
   Now that the fix in [#12297](https://github.com/apache/maven/pull/12297) 
(and the regression-guard follow-up in 
[#12298](https://github.com/apache/maven/pull/12298)) handles 
`<activeByDefault>` cleanly, the warning is moot for that case. But the four 
other activation channels (`<jdk>`, `<os>`, `<property>`, `<file>`) still 
silently drop their `<properties>`, because their evaluation happens later in 
the model builder than the resolver session build.
   
   Would it make sense to emit a single `[WARNING]` from 
`DefaultRepositorySystemSessionFactory#getPropertiesFromRequestedProfiles` when 
a profile
   
   * declares one of those four activation conditions, **and**
   * has a non-empty `<properties>` block, **and**
   * is not active via `<activeProfiles>` / CLI `-P`
   
   Same shape as the earlier prototype, just scoped to non-`activeByDefault` 
activation conditions:
   
   ```
   [WARNING] Properties of profile '<id>' (activated via <kind>) are NOT 
propagated
   to the resolver session config. To apply them, list the profile id under
   <activeProfiles> in settings.xml or activate via -P <id> on the CLI.
   ```
   
   ### 2. Backport to maven 3.9.x?
   
   The same bug reproduces on Maven 3.9.16 (same 
activation-time-vs-LRM-build-time ordering). For users who can't move to Maven 
4 yet, would a backport of #12297 (and whichever shape #1 lands in) be in 
scope, or is the 3.9.x line strictly maintenance-only at this point?
   
   Happy to prepare the backport PR once you confirm direction.
   
   ### Why I'm asking together
   
   This affects the maven-site doc clarification I'm drafting at 
[apache/maven-site#1602](https://github.com/apache/maven-site/pull/1602) — the 
final wording depends on whether the limitation gets fixed on both lines or 
only Maven 4, and whether there's a WARN bridging the not-yet-fixed conditions. 
I'll keep that doc PR as Draft until both questions are settled.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to