Summary - We use Gradle to build and compile our projects with simple commands that do a lot for us in the background. Avoid doing full build commands (gradle build) unless absolutely necessary, and instead build specific components/JARs as this will be much faster. Finally, you can chain Gradle commands together into one-liners to save time, e.g. you can write gradle clean build instead of having to submit these commands separately, one after another.
Introduction
Gradle is a general-purpose build tool that we use here at Quantexa to automate the building and compiling of our projects. As the repositories we have to deal with like the Academy Task project are quite large and complicated, having something like Gradle configured to do this leg-work saves us a lot of time. It is important when working on any project to learn about how Gradle has been configured for that specific environment. This ensures you use it in the most optimal way and only run the necessary Gradle commands for the given situation you are in. For example, you don't want to have to build an entire project (slow) if you have only been working on a small area of the code, and can perhaps just build that relevant section instead (faster).
In the points below I'll cover some of the specific Gradle commands you will encounter when working on the Academy Task repository. Remember, whenever you write some code, you will need to build the right JAR file before then running the associated script to incorporate any changes you have made.
Useful Gradle Commands
gradle clean - The clean task simply deletes all of the Build folders in your repository, which contain your program's JAR files (the compiled code) among other things. You may want to use this at the very start of your Academy Task to clear out any previously built code. It can also sometimes be useful to perform a clean before building if you are having some difficulty with getting a specific build command to run.gradle uberclean - This command removes the node modules directory in the UI module, and can be useful if you are having problems with NPM or with getting your UI to build. You will need to run a gradle build command after running an uberclean. The screenshot of the uberclean command below is taken from the build.gradle file within the Quantexa UI folder.
gradle build - The build command will run all of the relevant build tasks as specified within the main build.gradle file in the root of the repository, as well as run any unit tests that have been set up. When starting your Academy task it's good to start off with a gradle clean followed by a gradle build to "initialise" the project and build a lot of the necessary JARs, as well as the apps that are required to run the UI (app-scoring etc). Generally speaking, you should rarely have to run this full gradle build command, aside from an initial one to set up the project, or after you have run a gradle clean command. This command can also be used to incorporate any changes you have made to the front-end UI, however when developing this aspect of the project its much faster to use the NPM LiveRun feature instead. Therefore, when you want to build your project to incorporate some of the changes you have made to your code, you should use one of the specific Gradle commands specified below. - For the academy task project, a lot of the code has been "broken out" into separate JARs, specific to the area of the project you are working on at the time. This means you don't need to run a full
gradle build when working on the majority of the project (and note that a full gradle build won't build these specific JARs anyway) - you can just run the following command when working in a given module instead:
gradle <module>:projectShadowJar <module>:dependencyShadowJar
If you want to know which JAR you need to build in order for a given program script to be updated before running it (for example CreateCaseClass or BatchScoringRunner), you can look in the relevant bash script that you use to run the Scala program. For example, when running the various ETL scripts, these are all run using the runQSS.sh bash script. Looking at the configuration contained within this script (see picture below), we see that it relies on two JARS: the data-source-all project & dependency shadow JARs, so we know that these will need to be built and kept up to date for any of our code changes to be in effect.
- The Project Shadow JAR - This will contain the majority of code that you are writing and modifying for your academy task.
- The Dependency Shadow JAR - This will contain the relevant dependency libraries required for the given module.
- If you want to know more about specifically what is contained within these commands, you can look at the relevant build.gradle file for the module in question.
gradle <app-name>:build - This command will rebuild one of the UI apps (like app-scoring or app-investigate), which can be useful if you want to quickly rebuild a specific app without having to do a full gradle build.gradle generateCode -t - When doing a lot of changes to Fusion files, it can be useful to run this command to set Gradle into a "watching" mode, where it will automatically build the changes on the fly as you write your code. This is handy as you get instant feedback of e.g. any syntax errors.
Note that the above descriptions of how the various build commands work are directly applicable to the Academy Tasks - when working on another project, things may be set up a little differently so it's always worth checking this at the start!
Other Useful Points
- You can chain more than one Gradle instruction with the same call to Gradle, i.e. you can do multiple commands in one line. For example, instead of running
gradle clean followed by gradle build, you can run gradle clean build. This can save time, particularly if you have just run a gradle clean and then want to rebuild all of the specific project & dependency shadow JARs and don't want to have to wait for one build command to finish before running the next one. It's good to keep all of the various commands saved in a notepad to make your life easier and speed up development! - You can modify some Gradle configuration settings in the gradle.properties file in the root of the project directory. While this isn't necessary for the Academy task, it can be informative to have a look at what sort of settings have been declared in this file.
- Adding flags onto your Gradle commands can modify the behaviour, for example
gradle build -x test will do a regular gradle build but not run any unit tests.
Additional Resources
Did you know that you can log in (or sign up) to the Community to unlock further resources in the Community and on our Documentation site?
For more information about the Quantexa Academy, see Introduction to the Quantexa Academy.
Head over to our Academy Topic for support, announcements, and discussions.
