You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Let's try out the new Lucene/Solr Gradle build!

Before we begin, I recommend using https://github.com/dougborg/gdub as this lets you run targets from submodules rather than having to do everything top level with gradlew.
Where you might normally do ./gradlew solr:core:test from the root directory, gdub lets you do cd solr/core; gw test.


Project Checkout and Setup

Let's check out the project and switch to a Gradle build branch.

  1. git clone https://github.com/apache/lucene-solr.git _lucene-solr
  2. cd _lucene-solr
  3. git checkout -t origin/jira/SOLR-13452_gradle_7
  4. gw eclipse
  5. In Eclipse, File→Import→Import existing projects into workspace, select the root of the project directory we just checked out, choose to include nested projects.


I like to check out the project in a directory that starts with underscore (_lucene-solr). Eclipse is very finicky about wanting the root project name to match it's folder name, so this saves some hassle while causing the root project to show up first in Eclipse (see above).

This is nice behavior because as you can see, our non Lucene/Solr specific projects come first (_lucene-solr, buildSrc, dev-tools), then we have the Lucene projects and then the Solr projects.

Some Basics

Let's try out a few basics.

  1. gw tasks                           // list the available tasks we can run
  2. gw clean build -x test  // build everything and run checks, but skip unit tests
  3. gw clean build               // do it again with unit tests
  4. gw clean test --tests *MinimalSchemaTest  // run a single test
  5. gw check                         // runs various checks like forbiddenApis, illegal source patterns, license headers, etc. Depends on test task and is run as part of build task.


The root of the build is at _lucene-solr/build.gradle. This is where common things that are applied to multiple sub projects across Lucene and Solr live. This is where you might exclude a dependency from the entire project or add a task for all of the projects.

Each sub project will then have it's own build.gradle where things are customized or added.

There are also a few aggregate projects, for example, _lucene-solr/solr/build.gradle is where the Solr packageDist task lives. A task by the same name is in the Lucene aggregate project's build.gradle. These aggregate projects do not produce artifacts or get published.

Notes

  • All versions except those used in buildSrc are specified in the root versions.props file.
  • You can see the actual dependencies and versions that get pulled in in the root versions.lock file.
  • The buildSrc directory is a special directory to Gradle that is it's own root project that can have plugins that we can access from our root project.
  • We also abuse buildSrc as a subproject of our root project to share resources.

Configuration

Project configuration is in _lucene-solr/gradle.properties. This is where our project defaults live and they can be overridden for you local env in ~/.gradle/gradle.properties.

gradle.properties:

version=9.0.0 // the project version

// whether or not to use the Gradle daemon - if true, keeps the build process around for reuse for up to 3 hours so that startup times are removed and hotspot has a chance to rock - you should generally set this to true in your ~/.gradle/gradle.properties
// we set to false so that a CI system with no setting will not use a daemon by default
org.gradle.daemon=false

// allows task and modules to be executed in parallel
org.gradle.parallel=true

// max parallel jobs to run at once, including both tasks and tests.
// default is number of CPU cores
# org.gradle.workers.max=2

// number of jvms to distribute tests across in parallel
// defaults to number of CPU cores / 2
// NOTE: gradle does not try to balance tests across jvms yet: https://github.com/gradle/gradle/issues/2669
# tests_jvms=5

// enables gradles build cache, which will reuse cached build outputs when it can
org.gradle.caching=true

// experimental gradle feature - does not currently work with our version constraints plugin: https://github.com/palantir/gradle-consistent-versions/pull/145
org.gradle.configureondemand=false

// how much ram the gradle daemon or process can use
org.gradle.jvmargs=-Xmx1g

More Advanced

Moving beyond the basics.

  1. gw regenerate                       // rebuilds all of our generated source and resource files - doing this for every module requires some dependencies, you can see which here
  2. gw publishToMavenLocal  // publish all modules to local ~/.m2 Maven folder
  3. gw packageDist                    // generate packaged distributions for Lucene and Solr in their respective dist directories

Pointers




  • No labels