Support profile activation in Maven pom.xml resolution and writing

[michaelkedar]

Currently, osv-scanner scan does not activate any Maven profiles(?), and osv-scanner fix activates only profiles that are explicitly active by default.

For better profile support, we could:

• Activate profiles that would naturally be activated (e.g. if the activation depends on a property)
• Have a way for the user to give us the active profiles (analogous mvn's --activate-profiles/-P flag)
  • Related: possibly have something analogous to mvn's --define/-D flag to define properties outside of the pom.xml file
• Figure out a way for getting/setting the JDK & OS versions for profile activation.

[cuixq]

Ah - good spot on scan! I think default profiles are activated during merging parents but not the base project - we should fix this.

[michaelkedar]

There's another related issue in osv-scanner fix with writing patches to profiles only applying to the first one in the list:

e.g.

<dependencies>
  <dependency>
    <groupId>com.xyz</groupId>
    <artifactId>foo</artifactId>
  </dependency>
</dependencies>

<profiles>
  <profile>
    <id>profile1</id> <!-- this profile is not active -->
    <activation>
      <activeByDefault>false</activeByDefault>
    </activation>
    <dependencyManagement>
      <dependencies>
        <dependency>
          <groupId>com.xyz</groupId>
          <artifactId>foo</artifactId>
          <version>1.0.1</version>
        </dependency>
      </dependencies>
    </dependencyManagement>
  </profile>

  <profile>
    <id>profile2</id> <!-- this profile is active -->
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <dependencyManagement>
      <dependencies>
        <dependency>
          <groupId>com.xyz</groupId>
          <artifactId>foo</artifactId>
          <version>1.0.2</version>
        </dependency>
      </dependencies>
    </dependencyManagement>
  </profile>
</profiles>

gets patched to

<dependencies>
  <dependency>
    <groupId>com.xyz</groupId>
    <artifactId>foo</artifactId>
  </dependency>
</dependencies>

<profiles>
  <profile>
    <id>profile1</id>
    <activation>
      <activeByDefault>false</activeByDefault>
    </activation>
    <dependencyManagement>
      <dependencies>
        <dependency>
          <groupId>com.xyz</groupId>
          <artifactId>foo</artifactId>
          <version>2.0.0</version> <!-- Only this version is changed -->
        </dependency>
      </dependencies>
    </dependencyManagement>
  </profile>

  <profile>
    <id>profile2</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <dependencyManagement>
      <dependencies>
        <dependency>
          <groupId>com.xyz</groupId>
          <artifactId>foo</artifactId>
          <version>1.0.2</version> <!-- The version in the activated profile doesn't get patched -->
        </dependency>
      </dependencies>
    </dependencyManagement>
  </profile>
</profiles>

If there's also a dependencyManagement for the package outside of the profiles, that is the only thing that gets patched despite being overwritten by the profiles.