Skip to content

3.10.0: Model interpolation does not take property activated profiles into account #13347

Open

Description

@mbien

Affected version

3.10.0

Bug description

Not certain if this is a bug or intended hardening, try running this test on 3.9.16 and 3.10.0

import static org.junit.jupiter.api.Assertions.assertEquals;

import java.nio.file.Files;
import java.nio.file.Path;
import java.util.Properties;

import org.apache.maven.model.Model;
import org.apache.maven.model.building.DefaultModelBuilderFactory;
import org.apache.maven.model.building.DefaultModelBuildingRequest;
import org.apache.maven.model.building.ModelBuildingRequest;
import org.apache.maven.model.building.ModelBuilder;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.io.TempDir;

class ProfileActivationViaProperty {

    @TempDir
    Path tempDir;

    @Test
    void propertyActivatedProfileSetsSecondProperty() throws Exception {
        Path pomFile = tempDir.resolve("pom.xml");

        Files.writeString(pomFile, """
            <project xmlns="http://maven.apache.org/POM/4.0.0"
                     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                     xsi:schemaLocation="
                       http://maven.apache.org/POM/4.0.0
                       https://maven.apache.org/xsd/maven-4.0.0.xsd">

                <modelVersion>4.0.0</modelVersion>

                <groupId>example</groupId>
                <artifactId>profile-test</artifactId>
                <version>${v}</version>

                <profiles>
                    <profile>
                        <id>foo</id>

                        <activation>
                            <property>
                                <name>activate.foo</name>
                                <value>true</value>
                            </property>
                        </activation>

                        <properties>
                            <second.property>profile-was-activated</second.property>
                        </properties>
                    </profile>
                </profiles>
            </project>
            """);

        Properties userProperties = new Properties();
        userProperties.setProperty("activate.foo", "true");
        userProperties.setProperty("v", "666");
        
        // required for 1) to pass
        // tells maven 3.10 to add props as interpolation value source
        userProperties.setProperty("maven.model.dependencyInterpolation.full", "true");
        
        
        ModelBuildingRequest request = new DefaultModelBuildingRequest()
                .setPomFile(pomFile.toFile())
                .setUserProperties(userProperties)
                .setValidationLevel(ModelBuildingRequest.VALIDATION_LEVEL_MINIMAL);

        ModelBuilder modelBuilder = new DefaultModelBuilderFactory().newInstance();

        Model effectiveModel = modelBuilder
                .build(request)
                .getEffectiveModel();

        // 1)
        assertEquals(
                "666",
                effectiveModel.getVersion()
        );

        // 2) fails on 3.10 despite "maven.model.dependencyInterpolation.full"
        assertEquals(
                "profile-was-activated",
                effectiveModel.getProperties().getProperty("second.property")
        );
    }
}

Activity

  1. added
    bugSomething isn't working
    on Oct 5, 2026
  2. PrityyKashyap commented on Oct 5, 2026

    @PrityyKashyap

    Hi, I’d like to investigate this issue. I noticed the related discussion in apache/netbeans#9642 regarding the Maven 3.10 model interpolation changes and user properties. I’ll look into the relevant model-building/interpolation code and try to narrow down whether this is an unintended regression.

  3. slachiewicz commented on Oct 9, 2026

    @slachiewicz
    Member

    Both effects come from hardening I added in #12948 (3.10.x: #12953), with profile activation later moved into a sandboxed activation context by #13112/#13114: a model resolved from a repository interpolates only a fixed set of expressions and does not activate profiles from user properties. Both checks use validationLevel < VALIDATION_LEVEL_MAVEN_2_0 to decide that a model came from a repository, because DefaultArtifactDescriptorReader builds those at VALIDATION_LEVEL_MINIMAL. NetBeans builds the user's own project at MINIMAL for leniency, so it is treated as a repository POM: -D profile activation stops working, and maven.model.dependencyInterpolation.full cannot bring it back.

    The validation level is the wrong signal for this. I'll open a PR for master and 3.10.x that adds an explicit flag on the model building request, set by DefaultArtifactDescriptorReader when it loads a POM, and makes both checks use it, falling back to the validation level only when the flag is unset. @gnodet, does that work for the activation sandbox? Until it is released, an embedder can build its project at VALIDATION_LEVEL_MAVEN_2_0.

  4. added a commit that references this issue on Oct 16, 2026
    b6272da
  5. added a commit that references this issue on Oct 20, 2026
    dd347b0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions