I was recently doing some analysis on ways to improve the build times for the project, and noticed that :api:cas-server-core-api-configuration-model:generateConfigurationMetadata doesn't currently appear to be structured in a way that supports either UP-TO-DATE checks or build caching. If we could address this, it might shave a good 8-10 seconds off of each build.
This task is currently a JavaExec to execute a custom class (ConfigurationMetadataGenerator). It looks like that class reads in a JSON file generated at compile-time by Spring annotation processors, does some project analysis, and writes out an updated version of that same JSON file. I don't see anywhere else in the project where that class is used, and it seems like the sort of thing that would be unlikely to be used outside the build for other purposes. Gradle currently excludes this task from UP-TO-DATE checks because it doesn't declare any outputs. We could use the DSL to declare outputs, but then we'd have issues because we're reading and writing the same file, and the outputs of the task would overlap with the outputs of the javaCompile task. When I've encountered situations like this in the past, the approach I've taken has been to handle the compilation post-processing as an additional action for the javaCompile task, rather than a separate task. With this approach, we can declare additional inputs for the javaCompile task as needed, and Gradle will consider the final outputs (after all actions have completed) for UP-TO-DATE and build caching. For comparison, here's an example of that technique being used for bytecode enhancement in the Hibernate project. https://github.com/hibernate/hibernate-orm/blob/main/tooling/hibernate-gradle-plugin/src/main/groovy/org/hibernate/orm/tooling/gradle/HibernatePlugin.java#L47 While it's possible to use an anonymous closure to do this, it's recommended to instead use a named class for the action, as anonymous closures sometimes cause problems with caching due to ending up with different hash keys when compiled on different JDKs/OSs/etc. If this all makes sense to others, I propose to assemble a pull request that: * Removes :api:cas-server-core-api-configuration-model:generateConfigurationMetadata * Converts ConfigurationMetadataGenerator from a command-line application to a Gradle Action (possibly in buildSrc), ConfigurationMetadataGeneratorAction * Adds a doLast action for ConfigurationMetadataGenerator to :api:cas-server-core-api-configuration-model:javaCompile * In my testing of the pull request, verify that UP-TO-DATE and build caching of :api:cas-server-core-api-configuration-model:javaCompile still works and that the content of the final json file is as expected If anyone has input on these points, it would be helpful: * Is it safe to remove ConfigurationMetadataGenerator (replacing it with a Gradle Action that can't be called outside the build) or do we need to maintain it (and possibly extract the logic so it can be used in multiple ways? * Is there a reason that the JSON file is being written to multiple locations (both "${buildDir/<FILENAME>" and "${buildDir}/classes/java/main/META-INF/<FILENAME>"? If so, why? If one is not needed, can it be removed? -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/67cc5fda-b623-4009-afa5-dec7424f18afn%40apereo.org.
