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. |
Project Checkout and Setup
Let's check out the project and switch to a Gradle build branch. There is no need to install Gradle or worry about the version - the right version will be automatically installed for you.
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 below). 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. |
Let's try out a few basics.
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.
Project configuration is in _lucene-solr/gradle.properties. This is where our project defaults live and they can be overridden for your 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
Moving beyond the basics.
TBD
Related articles appear here based on the labels you select. Click to edit the macro and add or change labels.
|