SOLR-15602: upgrade to gradle 7.2, clean up gradle code a bit. #275
SOLR-15602: upgrade to gradle 7.2, clean up gradle code a bit. #275dweiss merged 9 commits intoapache:mainfrom
Conversation
build.gradle
Outdated
There was a problem hiding this comment.
nit: end of line whitespace
build.gradle
Outdated
There was a problem hiding this comment.
can we call this "placeholder-outputs" instead?
There was a problem hiding this 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."?
gradle/generation/javacc.gradle
Outdated
There was a problem hiding this comment.
should this be RegularFile?
There was a problem hiding this 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
There was a problem hiding this comment.
Do we need some kind of flag to regenerate this file if it exists but users are upgrading from an older gradle/jvm version?
There was a problem hiding this 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
gradle/globals.gradle
Outdated
There was a problem hiding this comment.
@markrmiller was updating this in #225 just in case that gets merged first
gradle/java/jar-manifest.gradle
Outdated
There was a problem hiding this comment.
I'm not familiar with this syntax and am having trouble searching for it. Can you help me find a reference?
There was a problem hiding this 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.
There was a problem hiding this comment.
This doc explains the difference, btw.
https://docs.groovy-lang.org/latest/html/documentation/#_special_case_of_interpolating_closure_expressions
…r tweaks to minJavaVersion location.
… to 1.11.0 so that jdk16 can work.
2 participants
No description provided.