We have multiple projects/services where we do repeat same configuration over and over again as a part of build.gradle file. Examples could be configuration for spotless plugin, docker, junit/jacoco, versioning, groovy tasks, etc.
I wonder is there a way to externalize it or move to single place so that if needed we can update configuration once instead of doing the same across each and every project.
Very naive idea is to have master-build.gradle file stored in it's own git repo and where needed we can refer it as a git submodule with capabilities to extend/rewrite. Open for any ideas. Thanks!
Gradle scripts can be reused by creating external script files and importing them using apply from: my-script.gradle. apply from also accepts an URL, so you can use something like
apply from: 'https://github.com/user/myproject/raw/master/hello.gradle'
Note tough that using plain references (URLs; or GIT repo URLs) is sub-optimal; a better approach is to identify your build dependencies (and these scripts ARE dependencies!) using group:artifact:version coordinates- that is achieved by writing a plugin and publishing to a repo (eg. to https://plugins.gradle.org/).
Related
I am using spring-boot and would like to update the application.properties file in the /src/main/resources folder as a task within a manual build plan. As the service can be installed on premise at the customer, I want to build the jar for each customer, where I can provide variables (e.g. spring.data.mongodb.* properties) to be injected/overridden before the maven build.
I found the inject plugin, but this adds a prefix before the variables, which in this case wont work as the DB connection is done automatically with spring.
Is there another plugin I didn't find which could do the trick, or is there an easy way to script something like this (please provide an example as I am not very familiar with shell scripts)?
I have a few projects in separate git repositories.
Is there a way to store common gradle configuration that they are using in one place?
The common configuration includes repositories, tasks etc.
Yes, it's possible. You can define a gradle file with all the necessary data and expose it, e.g. www.company.com/master.gradle.
Then apply it in the following way:
apply from: 'www.company.com/master.gradle'
in all gradle scripts that require these global settings. This link may be also useful.
In the plugin I would like to be able to choose what other plugins apply (e.g. Nexus plugin or Bintray plugin, but not both) based on a configuration placed by a user in the configuration closure for my plugin.
I normally get the configuration for my plugin after the project has been evaluated. That is too late as I would like to allow users to override default configuration for those other plugins in their own (so they have to be applied earlier).
I could split my plugin into two separate plugins (within the same JAR), and require to apply the first one, provide configuration closure, apply the second one and use the configuration provided for the first plugin to decide what 3rd party plugins to apply.
Is there a better way to get the configuration for my plugin early enough to be able to conditionally apply other plugins (and allow them to use their configuration closures)?
You may use gradle 61.5. Init script plugins. This will allow your plugin runs before project configuration.
Example in the gradle documentation remove repositories from your build script. This means that you can read your configuration in a Init script plugin and decide which plugins to apply. Of course your configuration name should be fixed therefore your Init script plugin should be able to read it.
I have a Maven repo set up as a website, hosted on an Amazon S3 bucket. In my Groovy code, if I use the #GrabResolver annotation with my #Grab annotation, Grape successfully finds the jar I need and the script runs.
I want to set up grapeConfig.xml so that I don't have to use #GrabResolver in my scripts, and I can't figure out how to do it. http://groovy.codehaus.org/Grape doesn't explain how to set a remote resolver that's not hosted on ibiblio. It does say to consult the Ivy documentation, but I can only find info in the Ivy docs on how to connect to an Ivy repo, rather than a Maven one (ie, one that has ivy.xml files).
In short: How can I configure my grapeConfig.xml so that I don't need a #GrabResolver annotation pointing to my remote repo?
Well, it turns out I was massively overthinking it.
The solution is to just use an ibiblio tag anyway, specifying the Maven repo's root in the "root" attribute.
How can I use jars that buildr loads by default into the local maven repo, rather than creating new (and repetitive) artifact tasks/dependencies?
For example, if were creating a scala or groovy application buildr would automatically download the scala or groovy jars respectively. Is it possible to include or merge these (default) jars into an application rather than creating a new artifact?
I think that is not possible or doable in a one step, easy way. I recommend you talk with us on the dev list of Buildr and we can probably create an enhancement for that.
For each library you would like to depend on, you usual can grep the code to find where we define the default jar we depend on.
For the example you mention, here are the default method to retrieve the default jars:
For Groovy: Buildr::Groovy::Groovyc.dependencies
For Scala: Buildr::Scala::Scalac.dependencies
I hope that helps.