`classPath` not declared as required input

[koppor]

I am using this plugin together with gradlex-org/extra-java-module-info.

When running, I get

caused by: java.lang.RuntimeException: File does not exist: /home/runner/work/jabref/jabref/test-support/build/libs/test-support.jar
  This is likely because a tool or another plugin performs early dependency resolution.
  You can prevent this error by setting 'skipLocalJars = true'.

https://github.com/JabRef/jabref/actions/runs/16052632080/job/45298938588

The workaround is to execute all GUI tests in the before openrewrite:

xvfb-run --auto-servernum ./gradlew --no-configuration-cache :jabgui:test :rewriteDryRun

Instead of

./gradlew --no-configuration-cache :rewriteDryRun

(See JabRef/jabref#13448)

I filed an issue at that plugin (gradlex-org/extra-java-module-info#188), but the response is that I should ask here:

If I read the code correctly the plugin is doing dependency resolution (accessing files on a classpath), without declaring the that classpath input to the task.

Thus, the question if you could add classpath as required input.

[timtebeek]

hi @koppor ; certainly open to declare that implied dependency on the classpath. Would you happen to know how? 😅
The linked issue and helpful comments there point towards this internal annotation, but stops short of saying what to do

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

Lines 73 to 74 in 9a8fb33

	@Internal
	protected <T extends GradleProjectParser> T getProjectParser() {

[jjohannes]

Hi. I don't know the plugin implementation well enough to give the exact fix. It's certain "special" how things are dome here. But there are likely good reasons for why it is done like that. I think the problem is that the property called resolvedDepenedncies is not defined as an input. The minimal change to defined it as input would be, I think, adding a getter for it with the @Classpath annotation. There might be reasons, why this was not done in the past. But maybe it just works with that.

@Classpath
Provider<Set<File>> getResolvedDependencies() {
  resturn resolvedDependencies;
}

I am not sure if Gradle can handle the Provider<Set<File>> type correctly in this context. Typically, you would use ConfigurableFileCollections as type for such properties. But that may be a larger change. And gain, maybe there are reasons not to use it here.

---

EDIT: It is probably not enough. The provider for the files constructed in the plugin is a custom thing. If you would have something like this in the task:

public abstract ConfigurableFileCollection getResolvedDependencies();

And then assign it some Gradle-controlled FileCollection in the Plugin:

task.getResolvedDependencies().from(detachedConf)

...Gradle knows all the meta information. Like, where do the Jars in the collection come from? Which task creates them etc?

Current, I think this information is lost.