Support for Gradle configuration cache

[jprinet]

The Gradle configuration cache can't be enabled when using org.unbroken-dome.xjc Gradle plugin.

Quoting from the doc:

Gradle model types (e.g. Gradle, Settings, Project, SourceSet, Configuration etc…​) are usually used to carry some task input that should be explicitly and precisely declared instead.

Using a reference to the Configuration object is not supported:

gradle-xjc-plugin/src/main/kotlin/org/unbrokendome/gradle/plugins/xjc/XjcGenerate.kt

Line 114 in 82c1d69

abstract val catalogResolutionClasspath: Property<Configuration>

[eskatos]

catalogResolutionClasspath could be a ConfigurableFileCollection instead, which is supported by the configuration cache.

[dlmiles]

@eskatos thanks for your comment on this concerning making the plugin work with Gradle configuration cache

When you say this could be a ConfigurableFileCollection are you aware the MavenUriResolver feature does need an absolutePath to the JAR file, but it also needs the original Maven style GAV coordinate information such as org.groupId:artifactId:jar:classifier:1.2.3.4 as to the reason why that specific JAR file was selected.

So unfortunately this Property is not just a standard list of file: scheme URL JARs list

However good news, after surveying the landscape for solutions and understanding of the problem it appears @ryandens has successfully produced a clean commit (in the past month) that understands the feature of this plugin.

ryandens@8956a7e
ryandens@f488e10

At this time and updated change-set https://github.com/dlmiles/gradle-xjc-plugin/tree/master is undergoing CI testing before being added to PR #47 (or its successor)

[hegyibalint]

@dlmiles We are doing a survey of plugins to see the state of configuration cache support in the ecosystem. Do you still have plans to support the configuration cache fully?

[dlmiles]

@hegyibalint https://github.com/dlmiles/gradle-xjc-plugin/tree/master This project here was forked into the link in this comment, this was after a period of upstreaming the changes and providing feedback and a significant time to allow response. So AFAIKT this project here I consider it to be unmaintained.

There is however an issue with my disgust for Gradle's plugin policy/management concerning a number of areas I think are show stoppers to having it listed (so I am happy for this out-of-date plugin being the one listed and negatively impacting the ecosystem, due to not being supported on newer Gradle, not support later features, etc...) until Gradle improve the plugin catalog policies.
As an idea to the kind of issues concerning supply chain attacks and potential reputational attacks: Lack of official tick/ownership for plugin links/docs, Lack of official more secure builds taken directly from a public CI of the output build artifacts, Lack of signed JAR verification system to catalog and verify at runtime. When I last looked at it, it was a free for all, where any malicious actor could upload any JAR and point the upstream project at any website and attach someone else's name to it. What a nightmare in this modern era.
So if you wanted to survey, survey for that, as to why there are barriers to having a working version supporting current Gradle and configuration cache in the plugin catalog, think of me as a contributor situation that is walking away.