lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: Gradle build effort (respin, please read)
Date Tue, 03 Dec 2019 21:25:17 GMT
Here’s what I have in ~/.gradle/ that seems to at least be in the right
ballpark. Based on Mark’s “intro to the gradle build” page:

// 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/
// we set to false so that a CI system with no setting will not use a daemon by default

// allows tasks to be executed in parallel, across modules

// max parallel jobs to run at once, including both tasks and tests.
// default is number of CPU cores which is often too high - you should start by setting it
to half the number of cores, especially if you have hyperthreading
org.gradle.workers.max = 6

// number of jvms to distribute tests across in parallel
// defaults to number of CPU cores / 2 - you should just set this the same as org.gradle.workers.max
// NOTE: gradle does not try to balance tests across jvms yet:
tests_jvms = 6

// enables gradles build cache, which will reuse cached build outputs when it can

// experimental gradle feature - does not currently work with our version constraints plugin:
// also known to have other issues and not known to really speed anything up anyhow

// how much ram the gradle daemon or process can use

> On Dec 3, 2019, at 3:57 PM, Dawid Weiss <> wrote:
> That's aligned with my intuition -- logical cores / 2. Sadly I don't
> see how we may compute the number of workers dynamically (you can do
> this with test forks per project but not with the overall number of
> workers). I asked about it [1]. This is perhaps one of the few
> settings you could override globally via ~/.gradle/
> because it really applies to your hardware (corrects the overestimated
> default by Gradle).
> org.gradle.workers.max=[cpu cures]/2
> D.
> [1]
> On Tue, Dec 3, 2019 at 9:19 PM David Smiley <> wrote:
>> FWIW on a 6 year old MacBook Pro with a Quad-core i7, it seems max-workers of 2 is
about right, clocking in at 21:32.  3 took 20:17; not much better.
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> On Tue, Dec 3, 2019 at 9:13 AM Erick Erickson <> wrote:
>>> David Smiley:
>>> gradlew -p solr/packaging assemble
>>> couple of things:
>>> 1> The place you run bin/solr from is different
>>> 2> I didn’t need to specify the -p parameter and it defaulted to ‘...solr/packaging/build/solr-9.0.0-SNAPSHOT',
>>> Once I got over having to switch to a different dir than I was accustomed to,
I realized that by not mixing the build output with source, things are _much_ cleaner. After
a “gradlew clean”, the packaging directory only contains a build.gradle file.
>>>> On Dec 3, 2019, at 4:48 AM, Jan Høydahl <> wrote:
>>>> gradlew -p solr/packaging assemble
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message