Page History

Starting with Solr 9, we have changed our build process to be Gradle, Ant is no longer supported. Versions of Solr through Solr 8x are built only with Ant. This page is intended to help people use Gradle to build Solr, with special attention to tips for people already familiar with the Ant build process.

Solr versions through 8x must be built with Ant.

I want to especially thank Dawid Weiss for all his work on this, without his help and guidance (ok, his willingness to do most of the heavy lifting), we wouldn't be able to even consider transitioning to Gradle yet or even in the foreseeable future.

...

1. Install Gradle, see: https://docs.gradle.org/current/userguide/installation.html
2. Get a current version of Lucene/Solr with the usual "git clone https://github.com/apache/lucene-solr.git dest"
3. cd dest
4. ./gradlew help
5. ./gradlew helpAnt - For people already familiar with building Solr with Ant, this command will show Gradle tasks that are equivalent to selected Ant targets.At this point, Gradle is installed and running and you're able to start using it regularly.

...

• Gradle runs fastest when it uses a daemon. The first time you use gradle, it'll take some time (usually 10-20 seconds) to start the daemon and build caches. You'll see a message about "starting daemon". Subsequent runs should mostly skip this step
  • You may want to change org.gradle.daemon.idletimeout=900000 in your gradle.properties file (written the first time you run gradle) to a longer interval (this is in ms) to avoid restarting the daemon as frequently.
• The gradle build will fail on un-suppressed warnings. Trunk compiles cleanly, all warnings are suppressed or have been fixed (mostly suppressed). The first option if your new code generates more warnings is to change the code so it doesn't. Failing that add a SuppressWarnings annotation, but please try to fix the code first.
  • If you're working on code and can remove some of these suppressions, please do. It was too big a task to try to fix all the warnings by fixing the code all at once. We should improve from here.
• The gradle validation checks fail on log messages that follow potentially wasteful patterns. ./gradlew helpValidateLogCalls describes how to avoid these errors. This is part of ./gradlew check.
  • The validation is a bit harsh, if you have a logging call that is flagged but you've inspected and know is correct, add //logok as a comment
  Test classes are not compiled by the assemble and classes tasks and are not part of the packaging. The testClasses task will compile test classes
  • . But please read through ./gradlew helpValidateLogCalls for guidelines, it's more complex than it appears at first blush.
• It's not necessary to run the idea task before opening the project, just "open or import" and choose the root directory of your source tree.
• The output directories have changed for artifacts and test results. Pay close attention to the messages on the screen at the end of a task execution, they'll tell you exactly where to look.

IntelliJ IDE

IntelliJ integration is useful. There's nothing special about our support for Idea, it's just the one that's been exercised most. In particular the gradle window lets you easily execute tasks. In the case of failures because of the -Werror flag and just click to the source. The classes and testClasses tasks are particularly useful here as they just compile the Java code without the extra work the assemble task does.

...

• When switching back and forth between Gradle on trunk and 8x where you have to use ant, there are some Gradle-specific files that will be on your 8x tree. These should be ignored by the build system and Ant. You can delete them freely if you want. Note that when you go back  to using If you do, be aware that the next time you run Gradle it'll write a new "gradle.properties" file if it's not there so any older edits will be lost.
  
  • Gradle writes a new "gradle.properties" file at the root of your source tree that you may have to re-edit if you've changed it.if it's not there already, sometimes this can surprise you
• I've occasionally seen gradle stop with a message about thrashing memory when running the check task. There are two short-term solutions here: 
  • ./gradlew --stop will halt the daemon, releasing memory
  • Increase the memory allocated to Gradle by editing the settings in your gradle.properties file.
  • On the TODO list is to figure out why 3G (the current default which I sometimes bump even higher) and address whatever is causing that.

...