[MNG-7885] Plugin dependencies should be part in dependency management

[jira-importer]

Lars Uffmann opened MNG-7885 and commented

It would be a great improvement in dependency management if plugin dependencies could be part of the standard dependency management resolution. In the example below I could manage the version of the rewrite-maven-plugin using pluginManagement, the version of the rewrite-spring plugin dependency however has to be set in place.

 

 

<build>
  <plugins>
    <plugin>
      <groupId>org.openrewrite.maven</groupId>
      <artifactId>rewrite-maven-plugin</artifactId>
      <configuration>
        <activeRecipes>
          <recipe>org.openrewrite.java.spring.boot2.SpringBoot2JUnit4to5Migration</recipe>
        </activeRecipes>
      </configuration>
      <dependencies>
        <dependency>
          <groupId>org.openrewrite.recipe</groupId>
          <artifactId>rewrite-spring</artifactId>
          <version>4.35.0</version>
        </dependency>
      </dependencies>
    </plugin>
  </plugins>
<build>

 

 

Other plugins are using special configurations to declare extra dependencies. The version. management issue however is the same. A good example is   
annotationProcessorPaths of the compiler plugin.

---

Issue Links:

• MCOMPILER-391 annotationProcessorPaths have to follow dependencyManagement rules

[jira-importer]

Lars Uffmann commented

The maven compiler-plugin use case. I could add mapstruct-processor and lombok as an optional compile time dependency and their versions would be part of standard dependency management mechanism.

 

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <annotationProcessorPaths>
      <path>
        <groupId>org.mapstruct</groupId>
        <artifactId>mapstruct-processor</artifactId>
        <version>${mapstruct.version}</version>
      </path>
      <path>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>${lombok.version}</version>
      </path>
    </annotationProcessorPaths>
  </configuration>
</plugin>

[jira-importer]

Slawomir Jaranowski commented

Lars Uffmann for annotationProcessorPaths we have a fix: MCOMPILER-391

[jira-importer]

Lars Uffmann commented

sjaranowski  Thx for the heads-up, good to know the issue is resolved for the compiler-plugin!  Most of points made there would apply here as well. One of the last missing pieces in maven dependency-management, IMO.

[jira-importer]

Tamas Cservenak commented

While this sounds good, I think this is a bad idea... build tools (plugins) should be orthogonal to your project. Think all the "common" dependencies (logging, commons, etc), many times your plugin and your project have wildly different requirements.
IIUC you want to define a depMgt and that have applied to plugin dependencies? As in that moment, for example your project and plugin would be obliged to use same slf4j-api for example (just as an example of common dependency).

IMHO, current separation is cleaner: you define in depMgt project (what your project uses) dependencies, and yes, while a bit laborious, you need to define extra bits in plugin/dependencies as well.

Maybe just use properties for this?

• slf4j.version for project dependency versions
• plugin.slf4j.version for plugin dependency versions (and use expression in plugin/dependency)

Other problem I see IF this get applied, is how to "opt out"? I bet there will be users who does need and want what I wrote above (completely different versions for project itself and plugins).

[jira-importer]

Tamas Cservenak commented

Hm, reconsidering the second part, i said something silly about opt-out:

• plugin own dependencies should not be affected
• pom/plugins/plugin/dependencies if "complete" (as today must) should not be affected
• pom/plugins/plugin/dependencies, if "incomplete" (ie. version missing) should be affected ONLY

 

[jira-importer]

Lars Uffmann commented

Hi Tamas Cservenak, using properties is currently the only way to manage those plugin dependencies. But the usage of properties is very limited compared to bom style imports. The properties are limited to the current project or its parent hierarchy. Instead of just using the following bom import, I would have to introduce a property for each and every dependency managed in there.

 

<dependency>
  <groupId>org.openrewrite.recipe</groupId>
  <artifactId>rewrite-recipe-bom</artifactId>
  <version>${openrewrite-recipe-bom.version}</version>
  <type>pom</type>
  <scope>import</scope>
</dependency> 

 

[estekhin]

rewrite would benefit from this issue the most, because the version of the rewrite-recipe-bom usually differs from the version on each and every artifact managed by that bom.

Right now in order to configure the rewrite-maven-plugin one has to basically choose a version of rewrite-recipe-bom and copy-paste its contents.