freefair / gradle-plugins

Gradle Plugin Collection
https://docs.freefair.io/gradle-plugins/current/reference/
MIT License
221 stars 33 forks source link

generateEffectiveLombokConfig is not cached #549

Open flocsy opened 2 years ago

flocsy commented 2 years ago

When I run gradle build and then without any changes in the code I run gradle build again then all the generateEffectiveLombokConfig tasks are run again even though the code hasn't change. IMHO generateEffectiveLombokConfig should be cached and it should only run again if there was a change in the code. (I'm using 6.4.3)

larsgrefer commented 2 years ago

Please have a look at https://github.com/freefair/gradle-plugins/pull/525#issuecomment-1136247942

mjaggard commented 2 years ago

@larsgrefer https://github.com/freefair/gradle-plugins/commit/6314b6da5697b03f71adc82f9652f66fbb93dd55 This commit doesn't completely solve the problem for me. After this commit if I make zero changes to my source at all then I get

Task :api-v1:generateEffectiveLombokConfig UP-TO-DATE

but if I make any changes at all to any files - not to config then I get

Task :api-v1:generateEffectiveLombokConfig

and my entire source is recompiled.

This is better than the previous situation (always recompiling everything) but not ideal because if the config hasn't changed then the generateEffectiveLombokConfig should be UP-TO-DATE already and not invalidate the java compile.

mjaggard commented 2 years ago

Task ':api-v1:generateEffectiveLombokConfig' is not up-to-date because: Input property 'paths' file /path/to/MyClassName.java has changed.

larsgrefer commented 2 years ago

Thats a good point. For the up-to-date check here, I don't care about the contents of your java classes, just where they are.

I'll have a look at this.

mjaggard commented 2 years ago

I'm not sure I fully understand, but doesn't the effective Lombok config only depend on files called lombok.config and those imported by it? I'd assumed that no java classes needed to be used at all?

larsgrefer commented 2 years ago

I'm not sure I fully understand, but doesn't the effective Lombok config only depend on files called lombok.config and those imported by it? I'd assumed that no java classes needed to be used at all?

Thats correct. Given your example path of /path/to/MyClassName.java Lombok would look for these files at first:

It traverses the file system upwards, starting at the java source file. That's why the location of the java sources is important. The content of the source files is not needed.

mjaggard commented 2 years ago

Oh, of course sorry. I forgot that Lombok configuration can be per directory. Thank you.

jenni commented 1 year ago

+1 , using gradle-7.5.1

mjaggard commented 1 year ago

+1 , using gradle-7.5.1

This has been fixed but not released. Locally I'm currently running the main branch as my plugin by installing the plugin into maven local and then referencing that in my project build instead of a release.

It's annoying having to keep merging my local changes in git though and I can't commit it because the build machine doesn't have this plugin snapshot.

kancsuki commented 1 year ago

Is it possible to include this change in the next version of the plugin?

larsgrefer commented 1 year ago

@kancsuki This should already be released for some time now

mmoayyed commented 10 months ago

Hello, am I correct in stating that based on https://github.com/freefair/gradle-plugins/pull/525#issuecomment-1136247942, the LombokConfig task cannot be cacheable?

Running with plugin version 8.4 and Gradle 8.5, I see that the generateTestEffectiveLombokConfig is run multiple times on each build run. Gradle's build scan reports the following:

The task was not up-to-date because of the following reasons: 
Output property 'outputFile' file webapp/cas-server-webapp-tomcat/build/lombok/effective-config/lombok-test.config has been removed.

In this scenario, there exists only one lombok.config file found at the root of the project: https://github.com/apereo/cas/blob/master/lombok.config

While the task typically executes very quickly, in some cases it can take up to 31 seconds or so. Could this task be made cacheable as pointed out here?