Repository navigation
v3 ProjectBuilder classifies a project built from its POM file as a dependency unless validation is STRICT #13395
Description
In the Maven 3 compatibility layer (the v3 bridge), DefaultProjectBuilder picks the Maven 4 request type for build(File, ProjectBuildingRequest) like this (impl/maven-core/.../DefaultProjectBuilder.java:468-478):
reactorMember || isStandalone
|| (pomFile != null && request.isProcessPlugins()
&& request.getValidationLevel() == ModelBuildingRequest.VALIDATION_LEVEL_STRICT)
? BUILD_EFFECTIVE
: (parent ? CONSUMER_PARENT : CONSUMER_DEPENDENCY)A project built from its own POM file outside a reactor is therefore treated as a dependency POM (CONSUMER_DEPENDENCY) whenever validation is below STRICT or plugin processing is off. That is exactly how IDEs call it: NetBeans (MavenEmbedder.readProjectWithDependencies) and m2e (MavenImpl.readProject) build the user's project at VALIDATION_LEVEL_MINIMAL for leniency. DefaultModelBuilder then evaluates the project's profiles in the external-origin sandbox, so -D user properties (for example from .mvn/maven.config) no longer activate its profiles, and file activation is skipped.
This is the Maven 4 counterpart of #13347, fixed for 3.10.x in #13394, where getPomFile() != null now means project mode whatever the validation level, as ModelBuildingRequest.setPomFile documents.
Proposed: classify a non-parent build(File) with a POM file as a project build, leaving build(ModelSource) and build(Artifact) as consumer requests. One open question: BUILD_EFFECTIVE also switches DefaultModelBuilder to strict validation (isBuildRequest() ? VALIDATION_LEVEL_STRICT : ...), so honouring the caller's lenient level may need the request type and the validation level to be decoupled rather than a one-line change.
Activity
arturobernalg commentedon Oct 10, 2026
I tried to reproduce this on current master (
61f92e956c).The profile activation issue does not reproduce: with
VALIDATION_LEVEL_MINIMAL, both user-property and file-activated profiles are applied.build(File, ...)uses a source with a null model id, so it is not treated as external by the profile activation sandbox.There is, however, a related problem. A standalone
ProjectBuilder.build(File, ...)with a local../pom.xmlparent fails at MINIMAL validation:The bridge currently selects
BUILD_EFFECTIVEonly forSTRICT + processPlugins. As a result,processPlugins/ validation level also determine whether local-parent lookup and other build-project semantics are enabled.Simply switching these calls to
BUILD_EFFECTIVEdoes not look correct either, because that would also force strict validation and ignore the validation level requested through the v3 API.It seems the underlying question is whether project/build semantics and validation strictness need to be represented independently in the Maven 4 model builder.
Would you prefer this to be addressed as part of #13395, or should the local-parent behavior be tracked separately before changing the model-builder API?