Java recipes are not getting updated

[freya022]

What version of OpenRewrite are you using?

I am using

• OpenRewrite v3.34.0 (BOM)
• Gradle plugin v7.36.0
• rewrite-java v[whatever version the BOM is using]

How are you running OpenRewrite?

I am using the Gradle plugin, and my project is a single module project with an included build.

A repro can be found here: https://github.com/freya022/rewrite-gradle-plugin/tree/repro/retained-rewrite-classpath

What is the smallest, simplest way to reproduce the problem?

1. Run ./gradlew :rewriteDryRun, keep the logs
2. Modify the prints in recipes/src/main/kotlin/org/example/TestRecipe.kt, println("Test 1") => println("Test 2")
3. Run the same command again, notice the logs are the same, the code was not updated

What did you expect to see?

The recipe should be updated

What did you see instead?

The recipe was not updated and kept running old versions until Gradle was fully restarted

What is the full stack trace of any errors you encountered?

N/A

Are you interested in contributing a fix to OpenRewrite?

I'm fairly sure this is an issue of the ClassLoader not being replaced appropriately (adding a dependency in the rewrite configuration updates the recipe), but I'm not sure what the actual fix would be.

From

rewrite-gradle-plugin/plugin/src/main/java/org/openrewrite/gradle/DelegatingProjectParser.java

Lines 65 to 73 in b3a0c64

	if (rewriteClassLoader == null ||
	!classpathUrls.equals(rewriteClasspath) ||
	rewriteClassLoader.getPluginClassLoader() != pluginClassLoader) {
	if (rewriteClassLoader != null) {
	rewriteClassLoader.close();
	}
	rewriteClassLoader = new RewriteClassLoader(classpathUrls, pluginClassLoader);
	rewriteClasspath = classpathUrls;
	}

I can see some potential issues, if we assume the plugin class loader doesn't change when only my recipe changes, the classpath URLs will remain the same (only the contents changed) and thus it will reuse the old loader.

[timtebeek]

hi! Can you explain your use case in a wider context? Because we indeed have some optimizations in how recipes are loaded, and it seems you're eyeing some non-standard usage.

[freya022]

We write recipes in an included build then use dependency substitution, this allows us to write recipes in the same repo, then be used by the actual project (as demonstrated in the issue repro).

For example, we have a recipe that formats our Javadoc, and recently I was working on another recipe that automatically adds some annotations under some conditions.

The recipes works just fine after they're done, this is pretty standard Gradle stuff, other projects like KSP allows us to do the same thing, i.e., users can create and consume their processors in the same project.

[timtebeek]

That helps to know, thanks! And neat use case we hadn't anticipated. Not sure if there's much we can do to support this, as it's somewhat risky to change given that we have to support Gradle 4 through 10, as well as a platform/CLI that loads recipes differently still. And given that it only affects recipes as they are developed it's inconvenient, but not impossible to work around, fortunately.

We'll keep the issue open though, and we're open to hearing your thoughts on what could be changed to accommodate this usage.

[freya022]

I thought that the plugin's code snippet I showed above only had a caching purpose - avoiding loading new classes - in this sense, relaxing the cache condition to make it recreate a class loader more "frequently" sure could make it do additional work, but it wouldn't break anything, would it?

Ideally there would be a way for us to detect that a dependency has changed, perhaps Gradle has some API for this, I should be looking into this.

Also, although I haven't tested it, I believe this issue would also surface if you were to develop recipes in a separate project, the published binary would have the same path and thus keep the same class loader too.