Support Maven version ranges in profile activation

[goutamadwant]

Addresses #11694.

Support Maven version ranges through the existing maven.version profile
activation property on master, without adding a POM model element.

The implementation recognizes range syntax only for maven.version and
evaluates it with the existing ModelVersionParser. Exact matching remains
unchanged for ordinary values and all other properties. Bounded, open-ended,
and negated ranges are supported; malformed ranges fail closed with a model
warning.

Tests cover the suggested [4.0.0,) form, prerelease and boundary behavior,
negation, malformed input, unchanged literal matching, and activation through
the model builder.

This implements the master path. Please consider a backport to
maven-4.0.x. Maven 3 requires a separate maven-3.10.x implementation using
its legacy model builder and version APIs.

Tests:

• mvn -pl impl/maven-impl verify (560 tests passed, 4 skipped)

• Full reactor and all 1,051 Core ITs executed

• Targeted Java 21 rerun of the affected IT classes (4 tests passed)

• Your pull request should address just one issue, without pulling in other changes.

• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.

• Each commit in the pull request should have a meaningful subject line and body.

• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied.

• Run mvn verify to make sure basic checks pass.

• You have run the Core IT successfully. See the test details above.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004.

• In any other case, please file an Apache Individual Contributor License Agreement.

[elharo]

Version ranges are a security hole and should never have been invented. let's not add more of them.

[gnodet]

Well-scoped, well-tested implementation of version range support for maven.version profile activation, following the no-model-change approach explicitly suggested by Maven maintainer @slawekjaranowski in issue #11694.

Highlights:

• Constructor injection of ModelVersionParser follows the established pattern already used by ConditionProfileActivator in the same package
• The compat module's separate PropertyProfileActivator (deprecated since 4.0.0, different package) is unaffected
• Test coverage is thorough: bounded, lower-bounded, upper-bounded, and boundary ranges; negated ranges; malformed ranges with and without negation; exact match preservation for maven.version; verification that range syntax remains a literal match for non-maven.version properties; and an integration test through DefaultModelBuilder with a test POM
• The POM namespace (4.1.0), test file naming convention, and ASF license header in the new test resource all follow existing project conventions

Minor observation (non-blocking): The return false in the VersionParserException catch block (PropertyProfileActivator.java line ~107) bypasses the negation logic, meaning ![malformed_range always evaluates to false (profile inactive) rather than being flipped to true by negation. This is explicitly tested and documented as "fail closed" behavior, which is safe and defensible — just worth a code comment for future maintainers.

This review was generated by an AI agent (Claude Code) and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet