Treat a model built from a POM file as the project, whatever its validation level

[slachiewicz]

Fixes #13347.

The repository-model restrictions from #12953 (interpolation) and #13114 (profile activation sandbox) decided "this POM came from a repository" by validationLevel < VALIDATION_LEVEL_MAVEN_2_0 alone. IDEs build the user's own project from its POM file at VALIDATION_LEVEL_MINIMAL for leniency (NetBeans MavenEmbedder.readProjectWithDependencies, m2e MavenImpl.readProject), so their projects were sandboxed: -D profile activation stopped working, and maven.model.dependencyInterpolation.full only restored the interpolation half (apache/netbeans#9642).

Both checks now also require getPomFile() == null. ModelBuildingRequest.setPomFile already documents a POM file as project mode, and the repository paths never set one: DefaultArtifactDescriptorReader sets it only for WorkspaceRepository POMs, BOM imports use setModelSource, and DefaultProjectBuilder.build(Artifact) passes a POM file only for a project in the reactor. Callers that set neither keep the validation-level fallback, so nothing changes for the CLI or for repository resolution. No API change.

master needs the equivalent change in the v3 bridge (DefaultProjectBuilder request type), tracked in #13395.

Verified: mvn -pl maven-model-builder,maven-resolver-provider,maven-core -am install → BUILD SUCCESS (maven-core 402 tests). With the main-code change reverted, the new testProjectModeAtMinimalValidationEvaluatesUserPropertyAndFileActivators fails (expected: <activated> but was: <null>). The core ITs covering the hardening (MavenIT0085, mng3586, mng4379, mng4590) have not been run locally.

[gnodet]

Thanks for the fix — the IDE regression is real and this unblocks NetBeans/m2e users.

The pomFile == null addition is a pragmatic fix for a heuristic that was always indirect: validationLevel was never designed to carry the "this is a repository model" semantic, and now pomFile is being recruited for the same kind of duty. It works because DefaultArtifactDescriptorReader never sets a POM file for repository POMs, but it's a convention that callers need to know about — a tool that loads a project POM via setModelSource(new FileModelSource(f)) without calling setPomFile() would still be sandboxed.

For context, the v4 model builder (impl/maven-impl) solves this cleanly with RequestType + source provenance (isRepositoryResolved checks whether the source carries coordinates), so there's no heuristic at all. The compat layer can't easily use the same approach without API changes, so the pomFile check is the right tradeoff for 3.10.x and for the compat bridge on master.

A couple of observations:

1. The setPomFile() Javadoc says it indicates "project mode", but this is the first time it's load-bearing for security-relevant sandboxing. It might be worth adding a note in ModelBuildingRequest.setPomFile() that callers building their own project POM must use setPomFile() (not just setModelSource) to avoid being sandboxed.

2. In restrictExternalModelInterpolation (the interpolation side), the pomFile check is added but the maven.model.dependencyInterpolation.full escape hatch still exists. Should the escape hatch also restore profile activation, or is the intent that pomFile makes it unnecessary? Right now a caller that can't set pomFile for some reason has no workaround for the profile half.

The fix itself looks correct for the cases it targets. The test coverage (project-at-MINIMAL vs repository-at-MINIMAL) is good.

Claude Code on behalf of Guillaume Nodet