Open gonozalviii opened 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. configure
jartask to include the index). The drawback will be that tests running with
build/main/classesin classpath would fail to find the index via
ClassLoader.getResource`.
WDYT?
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?
Would adding the "build/jandex/jandexMain" dir as a resource dir to the source set solve the testing issue?
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.
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.
Are you sure about that? I don't think compileJava
does anything with the resources.
I have not tried that.
I have turned off the processJandexIndex
task and modified the jar
task. This works fine for my use case.
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...
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.