I have a set of gradle build scripts that I am trying to get to run faster. I do not believe gradle to be at fault; the problem is what its being asked to do.
There are many issues with them but one is that users have to compile all the Java code when they bring down a new branch.
In practice, most people, work on the top level project and don’t change any of the sub-projects so it would be better if they could optionally pull down jars for those sub-projects and thereby “cheat” the build process.
Its fairly easy to create a jar containing all the class files for the sub-projects and stick it in artifactory but less easy to conditionally hook it into the top level project.
To make this clearer, lets say there is a java project called breakfast which has a bunch of dependencies that look like this:
dependencies {
compile project(’:bacon’)
compile project(’:egg’)
compile project(’:mushroom’)
.
.
If I want to optionally not build bacon, egg and mushroom and use an artifactory jar instead, what is the best way of achieving this?
One last thing, the sub-projects all use a custom plug-in which extends the java plug-in so tweaking that is an option.
One option is to use the Build Cache. For example your developers could use a build cache populated by your CI process. If CI has built something that hasn’t changed, developers will use the cached result instead of doing the work locally.
Another option is composite builds. Each project would require a separate build and dependencies would be declared as
+1 for what Lance said. The build cache is what you want. We use the build cache to build Gradle and saw a big improvement (this is 1.5 years old now): https://blog.gradle.org/introducing-gradle-build-cache This has only gotten better over time.