[ https://issues.apache.org/jira/browse/SOLR-16432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17609075#comment-17609075 ]
Shawn Heisey edited comment on SOLR-16432 at 9/25/22 2:34 AM: -------------------------------------------------------------- {quote}don't commit the attached patch as is {quote} I didn't look very closely at the patch, so I missed that it had affected more than gradle itself. I am not surprised that it wasn't right as-is, which is why I didn't just commit it. I was right to think it needed some discussion. {code} final jeopardy music while looking at the patch in more detail {code} I see what you mean. Looks like some of the changes that the patch undoes are related to making the build work when there are spaces in directory names. I would call that part a bug in the gradle system that needs to be fixed upstream. I did not try the build on Windows after upgrading gradle. I bet that if I had, it would have failed due the space in JAVA_HOME. Does gradle not have some mechanism for putting local tweaks in the build system without editing the gradle-supplied scripts themselves? Imagining something with one or more .d directory structures so the upstream files can be upgraded without blowing away local changes. Like /etc/sudoers.d, /etc/apt/sources.list.d, etc. was (Author: elyograg): {quote}don't commit the attached patch as is {quote} I didn't look very closely at the patch, so I missed that it had affected more than gradle itself. I am not surprised that it wasn't right as-is, which is why I didn't just commit it. I was right to think it needed some discussion. {code:java} final jeopardy music while looking at the patch in more detail {code} I see what you mean. Looks like some of the changes that the patch undoes are related to making the build work when there are spaces in directory names. I would call that part a bug in the gradle system that needs to be fixed upstream. I did not try the build on Windows after upgrading gradle. I bet that if I had, it would have failed due the space in JAVA_HOME. Does gradle not have some mechanism for putting local tweaks in the build system without editing the gradle-supplied scripts themselves? Imagining something with one or more .d directory structures so the upstream files can be upgraded without blowing away local changes. Like /etc/sudoers.d, /etc/apt/sources.list.d, etc. > Upgrade the gradle wrapper in the build from 7.2.0 to 7.5.1 or later > -------------------------------------------------------------------- > > Key: SOLR-16432 > URL: https://issues.apache.org/jira/browse/SOLR-16432 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build > Affects Versions: 9.1, main (10.0) > Reporter: Shawn Heisey > Assignee: Shawn Heisey > Priority: Minor > Attachments: solr-upgrade-gradle-7.5.1.patch > > > To upgrade the build system to the latest gradle version, I ran the following > command after installing the gradle snap on my system: > {code:java} > gradle wrapper --gradle-version 7.5.1{code} > Then I had to update the version number to 7.5.1 in two files relative to the > root of the repo's working dir: > {code:java} > gradle/validation/check-environment.gradle > gradle/wrapper/gradle-wrapper.jar.version{code} > Doing that resulted in the attached patch. > I tested with "./gradlew precommit -Pvalidation.git.failOnModified=false" on > branch_9x and main with OpenJDK 17 after I did this upgrade. Both passed. > Does it need any more validation before committing to main? Is it something > that should be backported to branch_9x? > This gradle upgrade gets us Java 18 support, but not Java 19. > -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org