Starting Gradle setup for enterprise product

Help/Discuss
1

Hello, first off I apologize for my inexperience with Gradle/build utilities.

I have started researching what it would take for my product to move to Gradle. We are currently using some rather old build which I believe is ant based. We have a java based application and we also need to build some WAR files.

My question is for an enterprise level product, would we need to set up a build.gradle for every project that we need to build, can we apply a task that builds all of the subprojects in the same manner? Do the subprojects have to be in the main project directory?

Reading about the gradle wrapper, I’m a bit confused about how this works and how it is set up. Does it use the same gradle build file to build and generate the wrapper files or is it completely separate from the build.gradle file?

Our version control is through mercurial and I’ve done a little searching the web for any kind of integrations between the two, but haven’t found any. Is anyone aware of any useful tools for those? Possibly to do continuous builds on commits?

I’ve been going the the guide and it has been rather helpful, but any recommendations on starting a gradle build setup would be appreciated!

Thanks for your assistance, and again sorry for my lack of experience.

2

Welcome to Gradle!

More information about Multi-Project Builds here: https://docs.gradle.org/current/userguide/multi_project_builds.html

Each project (and subproject) needs it’s own build.gradle file.

You can apply tasks to all subprojects in the top level build.gradle file by doing:

subprojects {
    task doStuff
}

The subprojects can be in the main project directory, or in a child directory, just when you declare them in your settings.gradle file, make sure you include the child directory in the path:

root
    project1
    modules
        project2
        project3

settings.gradle file:

include ':project1'
include ':modules:project2'
include ':modules:project3'

The gradle wrapper is just a convenient and easy way for you to manage Gradle across multiple machines. Instead of ensuring that each machine has the same version of Gradle installed, you check the wrapper into your source control, then run the wrapper each time instead: ./gradlew build.

The difference between ./gradlew build and gradle build is gradlew will automatically download and use the version of Gradle described in your gradle-wrapper folder, whereas the other will just use whatever’s on the path.

I’m not sure what you want for mercurial integration, but basically, you can check the build.gradle files into source control, and build them via any CI tool (Jenkins has gradle support, but if you use the wrapper, you can just call the command line utility)

If you have any other questions, let me know. I just transformed our enterprise ant build to Gradle recently, learned a lot during the process.

3

Thanks Ed! That cleared up a lot of confusion. I am still in the process of swaying my manager into using Gradle, but from what I have seen so far, it seems very flexible in a way that would benefit our product. I appreciate your prompt response and knowing there is an active community on the forum will help my manager make a decision.

As for my question about mercurial and Gradle integration, I realize it was a rather open ended question, my intent was just to open up conversation about anything that may exist about mercurial with Gradle.

4

In my opinion, you should try to decouple your source control from your build tool as much as possible. That way if you want to change your tools to another (move to Git, or move away from Gradle), you can more easily.