I want to set up my project to have a switch for Maven Local. The general idea is that there is a property, for example useMavenLocal, that I can set via the gradle.properties or gradle build to enable or disable the use of Maven local. I need this property at different locations as we are developing custom Java libraries and Gradle plugins, and I sometimes want to test these locally. Given that I also have a build-logic I therefore want to use the useMavenLocal property in
the plugin management of the settings.gradle of the root project
the plugin management of the build logic
the plugin management of another include build (the include build of a plugin that I develop)
the repository declaration, which is defined in the build-logic
My problem is that when I define a property in gradle.properties, I either don’t know how to access the property (syntax), or the property is not available. And more so, when I found one solution for one of these, that solution did not work for the other locations. Any suggestions on how to achieve this are highly appreciated. Ah, and I use Kotlin, not Groovy.
If the Gradle versions of the libraries and plugins are the same as (or at least compatible with) the Gradle versions of the consumer projects, I highly recommend you do not use mavenLocal() but composite builds which is exactly what they were invented for.
If you really need to use mavenLocal() you should make sure to have it always last in the list of repositories and only with a repository content filter controlling what exactly is taken from there. But I guess you know that and the reasons why you should avoid mavenLocal() if you can, or you would probably not have opened this thread.
Having said this, before trying to answer and if the composite build is not an option one more alternative suggestion. Do not require the consuming builds to have a facility for this, but just use an init script to add the repository. You could then also easily add some dedicated file-based local repository that is not mavenLocal(). And you can control this easily from commandline by either specifying the init script, or not.
Thank you so much for the input. Sadly, composite builds don’t work for us. We tried to realize these a year ago but ran into 101 problems, ranging from incompatible versions to individual builds that aren’t set up well and break in the composite build. I still would like to get composite builds running, but currently, given the resources we have, it is just not feasible for us.
Using local maven instead has worked like a charm from the get-go. It is just this one project, and its include builds that make problems.
I like the idea of the init script instead of adding a switch to maven local in the build. However, the plugin management doesn’t have a way to extend it (at least none that I found); any changes I make with the init script override existing repository declarations. And that’s a problem as our builds use different plugin repositories. Am I missing something?
