Skip to content

Conversation

@dsgrieve
Copy link
Contributor

What's changed?

What's your motivation?

When calling ChangeDependencyGroupIdAndArtifactId with overrideManagedVersion set to true, if you have:

  • A managed dependency in an external parent (com.fasterxml.jackson:jackson-bom:2.20.0 for example has a managed dependency of com.fasterxml.jackson.core:jackson-core:2.20.0)
  • A project (com.example:project:1.0.0) with the same managed dependency as the parent, but without a version number:
    <project>
      <groupId>com.example</groupId>
      <artifactId>project</artifactId>
      <version>1.0.0</version>
      <parent>
        <groupId>com.fasterxml.jackson</groupId>
        <artifactId>jackson-bom</artifactId>
        <version>2.20.0</version>
      </parent>
      <modules>
        <module>child-project</module>
      </modules>
      <dependencyManagement>
        <dependencies>
          <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-core</artifactId>
            <exclusions>
              <!-- ... -->
            </exclusions>
          </dependency>
        </dependencies>
      </dependencyManagement>
    </project>
  • A module (com.example:child-project:1.0.0) with a direct dependency on the same dependency managed in the parent, specifically without a version tag:
    <project>
      <groupId>com.example</groupId>
      <artifactId>child-project</artifactId>
      <version>1.0.0</version>
      <parent>
        <groupId>com.example</groupId>
        <artifactId>project</artifactId>
        <version>1.0.0</version>
      </parent>
      <dependencies>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-core</artifactId>
      </dependencies>
    </project>

and you're trying to change to a different groupId (ex. some.group) , artifactId (ex. some-artifact), and version (ex. 3.0.0), what ends up happening with ChangeDependencyGroupIdAndArtifactId is that the project's pom.xml changes to:

<project>
  <groupId>com.example</groupId>
  <artifactId>project</artifactId>
  <version>1.0.0</version>
  <parent>
    <groupId>com.fasterxml.jackson</groupId>
    <artifactId>jackson-bom</artifactId>
    <version>2.20.0</version>
  </parent>
  <modules>
    <module>child-project</module>
  </modules>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>some.group</groupId>
        <artifactId>some-artifact</artifactId>
        <exclusions>
          <!-- ... -->
        </exclusions>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

and the module's pom.xml changes to:

<project>
  <groupId>com.example</groupId>
  <artifactId>child-project</artifactId>
  <version>1.0.0</version>
  <parent>
    <groupId>com.example</groupId>
    <artifactId>project</artifactId>
    <version>1.0.0</version>
  </parent>
  <dependencies>
    <groupId>some.group</groupId>
    <artifactId>some-artifact</artifactId>
    <version>3.0.0</version>
  </dependencies>
</project>

Note worthy is that the requested version number appears on the module's pom.xml direct dependency, and not on the managed dependency despite this referring to a fully different artifact and group id and requesting it to update the managed version. If the version tag was present on the manged dependency in project's pom.xml to start with, the value will be updated, but no version number changes occur if the tag wasn't already existing, as above.

Anything in particular you'd like reviewers to focus on?

Anyone you would like to review specifically?

Have you considered any alternatives or workarounds?

Any additional context

From the description: "A project (com.example:project:1.0.0) with the same managed dependency as the parent, but without a version number:". A dependency in a <dependencyManagement> section will cause a mvn build error. This leads me to wonder if there was some upstream recipe that changed a <dependencies> section to a <dependencyManagement> section, or if the version of the managed dependency was somehow removed. Still, it seems as though the ChangeDependencyGroupIdAndArtifactId recipe should add the version to the managed dependency if the version is missing, or change it if the version is present.

Checklist

  • I've added unit tests to cover both positive and negative cases
  • I've read and applied the recipe conventions and best practices
  • I've used the IntelliJ IDEA auto-formatter on affected files

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

2 participants