1

I'm about to add io.freefair.lombok plugin to my gradle projects.

plugins {
    id "io.freefair.lombok" version "5.3.3.3"
}

Problem is, I have to add this script more than 20+ repositories. If I have to upgrade plugin version within this scenario, every single build.gradle should be modified and it doesn't seem to be a good solution.

I wonder if I can manage plugin version with BOM. Or any other possible solution would be helpful.

Hello world
  • 353
  • 3
  • 18

1 Answers1

1

If you use Gradle 6.9+ or 7.0+, you could use dynamic versions, such as latest.release or 5.+ (Declaring Versions and Ranges).

plugins {
    id "io.freefair.lombok" version "5.3.+"
}

Please be aware that io.freefair.lombok plugin versions are usually tied to specific Gradle versions. Should you use the Gradle Wrapper, using latest.release without upgrading Gradle may break your builds.

This approach could be combined with a custom Gradle plugin or init script. For example, you could have a custom plugin that depends on a curated list of maintained plugins required for your builds. When your plugin gets applied, it should be able to apply other plugins as well.

plugins {
    id "com.company.my-gradle-plugin" version "latest.release"
}
thokuest
  • 5,800
  • 24
  • 36
  • Does this solution solves my fundamental concern?What I want to implement is managing gradle plugin version across lots of repositories. – Hello world May 11 '21 at 16:33
  • 1
    @Helloworld The question I'm asking myself is how you would do it in Maven (I'm not a Maven expert :-) ). Of course, you can have a parent POM, or import a BOM but this wouldn't solve the problem of touching all build files on plugin updates. My answer sketches a potential solution of what I'm thinking may solve the problem of touching all `build.gradle` files. – thokuest May 11 '21 at 18:09
  • Understood. I also agree with you. Thanks for the answer ;-) – Hello world May 12 '21 at 11:04