We have many apps at our company and we would like to share same gradle configuration between all of them. Right now we need to copy the top-level build.gradle file to all our apps. This feature already exists in Maven - we hide all complex configuration into Maven parent.
Right now it’s possible using ‘apply from URL’, but that requires internet connection during every build. We would like to deploy build.gradle file into Maven repo and use it locally when cached.
Until caching for script plugins sourced over HTTP gets implemented, the best solution is to write a binary plugin (plugin class that ships as a Jar). This also has other advantages such as the ability to write tests for the plugin.
Peter, I don’t see how this
Peter, I don’t see how this solves the problem. I’m attempting to move our organization from Maven to Gradle. One of the biggest challenges, and frankly, disappointments is the lack of dependency based inheritance found with Maven and the parent POM concept. Our organization has over 100 projects and we try standardize dependencies as much as we can. For example, we make extensive use of Spring framework. We use parent POMs dependencyManagement section to control this. If we want to use a newer release of Spring framework in a project, we modify the parent POM, update the dependency version, increment the version of the parent POM, and check it into our artifact repo. All the child projects have to do is reference the new version of the parent POM, and viola, they are now using the newer version of Spring framework. Unless I’m missing something, I don’t see how to do this with Gradle.
Instead of publishing a build.gradle into your Maven repo, you’ll have to publish a Gradle plugin. A (binary) Gradle plugin is nothing else than a (reusable) build script, except that it’s implemented as a class.