dweiss commented on a change in pull request #275:
URL: https://github.com/apache/solr/pull/275#discussion_r699602425
##########
File path: build.gradle
##########
@@ -183,6 +184,7 @@ apply from: file('gradle/hacks/solr.findbugs.gradle')
apply from: file('gradle/hacks/wipe-temp.gradle')
apply from: file('gradle/hacks/hashmapAssertions.gradle')
apply from: file('gradle/hacks/turbocharge-jvm-opts.gradle')
+apply from: file('gradle/hacks/dummy-outputs.gradle')
Review comment:
I'd rather keep it consistent with Lucene, if you don't mind. Not a
native speaker but is something wrong with the "dummy"? I am aware of other
senses but this literal definition suits me just fine in this context "an
object designed to resemble and serve as a substitute for the real or usual
one."?
##########
File path: gradle/generation/javacc.gradle
##########
@@ -129,17 +115,33 @@ configure(project(":solr:core")) {
// We always regenerate, no need to declare outputs.
class JavaCCTask extends DefaultTask {
- @Input
+ @InputFile
File javaccFile
Review comment:
It doesn't have to be. It can be plain Java API. We're not being fancy
with the lazy API here so I don't think we need to make things complicated?
There is a semantic difference between Input and InputFile - this was a bug.
https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:up_to_date_checks
##########
File path: gradle/generation/local-settings.gradle
##########
@@ -35,26 +35,48 @@ configure(rootProject) {
def testsJvms = (int) Math.max(1d, Math.min(cpus * 0.5d, 12))
// Write the defaults for this machine.
- rootProject.file("gradle.properties").write(
- [
- "# These settings have been generated automatically on the
first run.",
- "# See gradlew :helpLocalSettings for more information.",
- "systemProp.file.encoding=UTF-8",
- "org.gradle.jvmargs=-Xmx3g", // TODO figure out why "gradlew
check" runs out of memory if 2g
- "org.gradle.parallel=true",
- "org.gradle.priority=normal",
- "org.gradle.warning.mode=none", // Silence gradle warnings.
We'll deal with them when we upgrade the wrapper.
- "",
- "# You may disable the background daemon if it consumes too
much memory.",
- "org.gradle.daemon=true",
- "org.gradle.daemon.idletimeout=900000", // timeout after 15
mins.
- "",
- "# Maximum number of parallel gradle workers.",
- "org.gradle.workers.max=${maxWorkers}",
- "",
- "# Maximum number of test JVMs forked per test task.",
- "tests.jvms=${testsJvms}"
- ].join("\n"), "UTF-8")
+ rootProject.file("gradle.properties").write("""
Review comment:
I wondered about this too, but in the end opted for simplicity. This
initial generated settings file is meant to provide the defaults and pointers
about where other things can be tweaked. But it is meant to be tweaked to your
(the developer's) needs and I know some folks are doing just that. Manipulating
their changes would only create more headaches. You can always wipe this file
and let it regenerate if you want it refreshed entirely.
I think these days you could also use init scripts to set up your local Solr
builds completely independently from the repository structure [1]. I haven't
toyed with this though.
https://docs.gradle.org/current/userguide/init_scripts.html#sec:using_an_init_script
##########
File path: gradle/java/jar-manifest.gradle
##########
@@ -61,8 +61,9 @@ subprojects {
"Specification-Version" : project.baseVersion,
"Specification-Title" : title,
- "X-Compile-Source-JDK" :
"${project.sourceCompatibility}",
- "X-Compile-Target-JDK" :
"${project.targetCompatibility}",
+ // Evaluate these properties lazily so that the
defaults are applied properly.
+ "X-Compile-Source-JDK" : "${->
project.sourceCompatibility}",
Review comment:
I think you're familiar with it, you just don't know it. :) I recall I
head-scratched over the very same thing... It's a gstring (lazily evaluated
string) with a snippet of gradle code which happens to be a parameterless
closure. The jar plugin is actually better now and supports lazy providers...
So this could be modified entirely. I just copied the solution that worked in
Lucene.
##########
File path: gradle/java/jar-manifest.gradle
##########
@@ -61,8 +61,9 @@ subprojects {
"Specification-Version" : project.baseVersion,
"Specification-Title" : title,
- "X-Compile-Source-JDK" :
"${project.sourceCompatibility}",
- "X-Compile-Target-JDK" :
"${project.targetCompatibility}",
+ // Evaluate these properties lazily so that the
defaults are applied properly.
+ "X-Compile-Source-JDK" : "${->
project.sourceCompatibility}",
Review comment:
This doc explains the difference, btw.
https://docs.groovy-lang.org/latest/html/documentation/#_special_case_of_interpolating_closure_expressions
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
