Details
-
Task
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
https://lists.apache.org/thread/fnjc7jmn7kbhbsk40g14cc6526yrnpxz
From: Chris Hostetter Date: Wed, 8 Jun 2022 14:35:47 -0700 (MST) To: Solr Dev <dev@solr.apache.org> Message-ID: <alpine.DEB.2.21.2206081359000.25213@slate> Subject: Obscenely long gradle compile times? (related to error-prone plugin?) $ git clean -fxd && ./gradlew tasks && ./gradlew compileTestJava The first gradlew command (to force it to download a fresh gradle-wrapper.jar and run ':localSettings' only took 21s -- but the second invocation (to pick up the local settings in a new daemon) took "19m 31s" ! (note that's just compilation - not running any tests) ... When I hacked ./gradle/validation/error-prone.gradle to hardcode 'def skipErrorProne = true' the entire "git clean -fxd ... && ./gradlew compileTestJava" command started taking ~1 minute.
Date: Wed, 8 Jun 2022 16:31:34 -0700 (MST) From: Chris Hostetter FYI: https://issues.apache.org/jira/browse/LUCENE-9879 ... Seems like Solr should probably follow Lucene's lead here ?
Date: Thu, 9 Jun 2022 10:52:03 +0200 From: Uwe Schindler Hi Chris, in later PRs done by Dawid and me we improved the whole thing even more. Instead of linking this to property tests.nightly (which would run it too seldom), we added another project property. In addition the Lucene build now detects if it is ran in a CI environment (it looks for env vars) and then enables it. This makes sure the error-prone is running always on Github pull requests or on Jenkins, but normal developers can enable it explicitly and its not ran by default: https://github.com/apache/lucene/blob/1dceff12c8bb764255927be55e46f4d435f47aed/gradle/globals.gradle https://github.com/apache/lucene/blob/1dceff12c8bb764255927be55e46f4d435f47aed/gradle/validation/error-prone.gradle
Attachments
Attachments
Issue Links
- relates to
-
LUCENE-10510 Check module access prior to running gjf/spotless/errorprone tasks
-
- Closed
-
-
-
- Closed
-
- links to