vlsi / vlsi-release-plugins

A set of plugins to simplify Gradle release tasks
Apache License 2.0
41 stars 13 forks source link

[Jandex plugin] processJandexIndex delete resources from build dir #63

Open gonozalviii opened 1 year ago

gonozalviii commented 1 year ago

I have have custom resources that get generated during the build process. The standard "processResources"-Task copies them to "build/resources/main". Then later when the "processJandexIndex" task runs, it flags these resources as stale and deletes them.

Also having a task (processJandexIndex) using the same output directory as another task (processResources) is probably not a good idea at all.

vlsi commented 1 year ago

Unfortunately, there's no clear way of adding generated index into resources.

In Gradle, resource files are inputs to compilation tasks. jar index takes compilation results and it creates the index. If we add the index to resources, then it creates a circular loop.

See https://github.com/gradle/gradle/issues/12774#issuecomment-842408717

So the workaround is to add the file into build/resources/main directory. Of course, it might invalidate processResources as it will find an unexpected file in build/resources/main.

On the other hand, it might be slightly better to avoid copying the index into build/resources/main, and add them only into .jaronly (e.g. configurejartask to include the index). The drawback will be that tests running withbuild/main/classesin classpath would fail to find the index viaClassLoader.getResource`.

WDYT?

gonozalviii commented 1 year ago

I had a similar idea, modifiy the jar task to include the index, but that does bring the drawback you mentioned. Modifying the processResources task doesn't work because it runs too early. So maybe it is possible to make the "classes" task depend on the jandex tasks, and then tell the "processResources" task that it must run after the jandex task. Would that mess anything up?

gonozalviii commented 1 year ago

Would adding the "build/jandex/jandexMain" dir as a resource dir to the source set solve the testing issue?

vlsi commented 1 year ago

If processJandexIndex removes other files from build/resources/..., then I should probably use a different class for processJandexIndex itself. E.g. make it a regular sync task that copies only a single index file. Then it shouldn't remove other files.

The drawback would be it might trigger re-execution of processResources, which, I guess, might be acceptable.

vlsi commented 1 year ago

Would adding the "build/jandex/jandexMain" dir as a resource dir to the source set solve the testing issue?

The issue is that Gradle assumes all resource directories are inputs for compileJava tasks, so it would go wild when it starts compileJava and sees no files in build/jandex/jandexMain. On second execution, it will detect the previously built index, and it would trigger re-compilation.

gonozalviii commented 1 year ago

Are you sure about that? I don't think compileJava does anything with the resources.

vlsi commented 1 year ago

I have not tried that.

gonozalviii commented 1 year ago

I have turned off the processJandexIndex task and modified the jar task. This works fine for my use case.

dgeissl commented 5 months ago

processResources is not by default a requirement for the compileClasses task see https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_tasks But there may actually be some folks who configured it in their builds to be this way, depends if you'd like to take the risk of a circular dependency for some projects or not.

I also have to contradict the statement that messing around with another tasks output may be acceptable. Newer gradle versions specifically enforce getting rid of such behavior up to the point the plugin won't work anymore. It also destroys the whole build avoidance gradle is so proud of.

Currently I think the best option is to customize the jar task to include the index file, also declaring a dependency on the index task.

If you need the index in your tests add the output folder of the main SourceSet to your test/resources (and a dependency for the processTestResources). Of course if you build a jar of your tests you'll have to make sure the index from the main is replaced with your test classes index...