ascheman commented on issue #12288: URL: https://github.com/apache/maven/issues/12288#issuecomment-4730049065
Thanks @slawekjaranowski for the documentation pointer — I see now that the limitation was added by you in maven-site#441 / [MNG-7850](https://issues.apache.org/jira/browse/MNG-7850) (July 2023, commit `68861020`). Reading the original issue and the PR discussion I cannot find an explicit *why* — only the observation that `profile/activation` is not honored at LRM init time. Is there a technical reason (timing / chicken-and-egg with the resolver session build, or otherwise) for the restriction, or is it documented because that's how it happened to behave at the time? The reason I ask: from a user perspective, declaring an active-by-default profile in `settings.xml` is the canonical Maven way to "make this always apply"; the requirement to list the profile id a *second* time in `<activeProfiles>` is non-obvious. The footgun is double-sharp because the only place this is documented is the resolver-transport mini-guide; settings.xsd and the Maven user guide don't flag the limitation. The fix in #12291 closes the gap for the `<activeByDefault>` case at the cost of seven lines in `DefaultRepositorySystemSessionFactory`. It deliberately does not re-implement full `DefaultProfileSelector` semantics (so e.g. deactivation-by-other-active-profile is not honored — PR body has the details). If the conclusion is to keep the existing behavior, 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: ``` [WARNING] Properties of profile 'aether-split-via-settings' (active-by-default) are NOT propagated to the resolver session config. To apply them, list the profile id under <activeProfiles> in settings.xml or activate via -P aether-split-via-settings on the CLI. ``` Happy to retarget #12291 to that smaller, behavior-preserving variant if preferred. Either way, if you confirm there *is* a technical reason that should not be unified, I'll close the PR and follow up with a maven-site PR that makes the limitation more discoverable beyond the resolver-transport mini-guide. -- 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]
