Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
gonozalviii opened this issue Jan 31, 2023 · 9 comments
Open

Comments

@gonozalviii
Copy link

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
Copy link
Owner

vlsi commented Jan 31, 2023

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 gradle/gradle#12774 (comment)

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
Copy link
Author

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
Copy link
Author

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

@vlsi
Copy link
Owner

vlsi commented Jan 31, 2023

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
Copy link
Owner

vlsi commented Jan 31, 2023

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
Copy link
Author

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

@vlsi
Copy link
Owner

vlsi commented Jan 31, 2023

I have not tried that.

@gonozalviii
Copy link
Author

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

@dgeissl
Copy link

dgeissl commented Jun 7, 2024

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants