[jira] [Comment Edited] (SOLR-16432) Upgrade the gradle wrapper in the build from 7.2.0 to 7.5.1 or later

["Shawn Heisey (Jira)" <ji...@apache.org>]

    [ 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-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org