I am working on a project where it would be great to share configuration details between Settings and Project. But have a lot of difficulty tracking down the best way to do this.
E.g., the project needs access to the JPA version to use. It needs this information in settings.gradle for defining dependencyResolutionManagement (catalog). It is also needs it in the project builds for configuring tasks, etc.
But to date, I have not found a great way to share stuff between Settings and Project. I saw some much older posts about using Gradle (project.getGradle()) as ExtensionAware to share state, but at least in Java project.getGradle().getExtensions() will not compile - Gradle is not ExtensionAware; oddly it does seem to be from Groovy DSL.
Anyway, pointers/hints on how to share such state?
Gradle like virtually any other object in Gradle and also all objects that Gradle creates for you from plugins and so on are decorated automatically to be ExtensionAware. Only a handful of objects actually declare being ExtensionAware explicitly, but you can cast practically any object to ExtensionAware and then use it. In Groovy the casting is simply not necessary due to its duck-typing and you can just use it as ExtensionAware.
Another way of sharing that JPA version would be to have it in gradle.properties, because then you can access it from settings script and build script.
Gradle properties are not about configuring Gradle.
They are also used for configuring Gradle details.
But it is perfectly fine to use them for own purposes too.
You shouldn’t overuse them and plugins should usually better provide extensions to configure, not Gradle properties and the user of the plugin can still bind a Gradle property to it if he wants.
Or custom tasks should better use @Options and so on.
But I think for that use-case it is exactly what you want to have.
I did not know about @Option but that is a cool feature to know.
What do you mean by “plugins should usually better provide extensions to configure”? Do you mean a DSL extension? Initially, before moving to catalogs, these properties were all leveraged relative to a Project. But since catalogs are defined in settings.xml, that changed the game which led to this post. Initially after moving to catalogs I wrote 2 plugins : one which got applied to Settings and one that got applied to Project. The both simply delegated to the same code. Settings and Project each resolved this property individually via the plugins, but using the same code so the values are ultimately the same.
I’m not sure exactly what you are suggesting though. Maybe a DSL extension with an @Option?
No, what I suggested was that you use a Gradle property as it seems to be the most fitting for your problem.
I just mentioned that there are many situations where plugin developers used to use Gradle properties where their use is not appropriate. For example to give arguments to a task from the commandline (for that @Option is appropriate) or to configure something for the plugin (for that an extension is better).