Gradle Configuration Cache Support

[keastrid]

I'm submitting a…

• [ ] bug report
• [x] feature request
• [ ] other

Short description of the issue/suggestion: Since Gradle will at some point make the config. cache the default, and deprecate disabling it, it would be good to get javapackager to support it. This is by no means a pressing issue.

So far from my limited testing it seems to be from the package tasks referencing the project to dynamically create some tasks to handle work - I believe at least some of these can be handled by injected services, though I do not see a clean way to wire them through to the packager from the task initializer.

Steps to reproduce the issue/enhancement:

1. Enable configuration cache
2. Run build

What is the expected behavior? Build succeeds

What is the current behavior? Build fails.

Exception at `io.github.fvarrui.javapackager.gradle.CreateTarball.createTarTask(CreateTarball.java:107)`
org.gradle.api.InvalidUserCodeException: Execution of task ':packageAijForLinux_x86_64Bit_Java23' caused invocation of 'Task.convention' by task ':createTarball_d157568f-f297-4b2a-b1d6-60c3f76f5d5e' at execution time which is unsupported.
	at org.gradle.api.internal.tasks.DefaultTaskContainer.create(DefaultTaskContainer.java:283)
	at io.github.fvarrui.javapackager.gradle.CreateTarball.createTarTask(CreateTarball.java:107)
	at io.github.fvarrui.javapackager.gradle.CreateTarball.doApply(CreateTarball.java:45)
	at io.github.fvarrui.javapackager.packagers.ArtifactGenerator.apply(ArtifactGenerator.java:44)
	at io.github.fvarrui.javapackager.gradle.GradleContext.createTarball(GradleContext.java:62)
	at io.github.fvarrui.javapackager.packagers.Packager.createBundles(Packager.java:338)
	at io.github.fvarrui.javapackager.gradle.AbstractPackageTask.doPackage(AbstractPackageTask.java:47)
	at java.base/java.lang.Thread.run(Thread.java:1575)

Exception at `io.github.fvarrui.javapackager.gradle.CreateTarball.createTarTask(CreateTarball.java:107)`
org.gradle.api.InvalidUserCodeException: Execution of task ':packageAijForLinux_x86_64Bit_Java23' caused invocation of 'Task.project' by task ':createTarball_d157568f-f297-4b2a-b1d6-60c3f76f5d5e' at execution time which is unsupported.
	at org.gradle.api.internal.tasks.DefaultTaskContainer.create(DefaultTaskContainer.java:283)
	at io.github.fvarrui.javapackager.gradle.CreateTarball.createTarTask(CreateTarball.java:107)
	at io.github.fvarrui.javapackager.gradle.CreateTarball.doApply(CreateTarball.java:45)
	at io.github.fvarrui.javapackager.packagers.ArtifactGenerator.apply(ArtifactGenerator.java:44)
	at io.github.fvarrui.javapackager.gradle.GradleContext.createTarball(GradleContext.java:62)
	at io.github.fvarrui.javapackager.packagers.Packager.createBundles(Packager.java:338)
	at io.github.fvarrui.javapackager.gradle.AbstractPackageTask.doPackage(AbstractPackageTask.java:47)
	at java.base/java.lang.Thread.run(Thread.java:1575)

Do you have outputs, screenshots, demos or samples which demonstrate the problem or enhancement?

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• JavaPackager version: 1.7.6
• OS version: Windows 10
• JDK version: 23
• Build tool:
  • [ ] Maven
  • [x] Gradle

Other information (e.g. related issues, suggestions how to fix, links for us to have context)

[keastrid]

I had started some work on trying to put together a PR for this, and it turns out the documentation for ArchiveOperations was wrong (fixed now) - it cannot create archives, only read them. So it seems the options are (in my limited understanding) to use a library for creating the archives or, as tasks executing other tasks seems to be bad practice, to break the packaging steps down into subtasks (that are created at the start) and chained together.