dweiss commented on PR #16543: URL: https://github.com/apache/lucene/pull/16543#issuecomment-5388337068
> I hoped we would either replace or maybe add a little to our WrapperDownloader. As an ASF project + gradle build, we need _something_ -- just trying to keep that _something_ narrow. I don't see why this new IntranetGradle does _both_ wrapper downloading and gradle distribution downloading. I wanted to keep it separate from WrapperDownloader because... well, it is hacky. WrapperDownloader is simple, that other class is hairy because gradle is dumb not to offer this by default... This is the only reason - to keep this separate just to signal that it's something we do that we shouldn't really be doing (gradle should be allowing it). > Maybe you disagree but if I'm going to set env vars to choose my gradle wrapper in some way, I'd rather no sha256 be verified, and/or allow me to have yet another env var to specify whatever the sha is for it. Everyone is so obsessed about security these days that I thought this wouldn't hurt. It ensures gradle distribution you point at (even if it's hosted somewhere else) is identical to that expected from the official server. I personally don't care that much about it but it seems like a reasonable thing to do (?). > I think most of all I want to make the wrapper distribution something in my control/env. I can have it on my machine somewhere but the build here needs to know where it is. _If_ I specify my gradle wrapper, Lucene shouldn't further insist what version and/or sha256 it is. I'm elecrting to choose the wrapper. Get it. I think it's going to hurt you if they change something in an incompatible way - the wrapper jar is part of each distribution (major or minor) and it does change from time to time (what they change - I've no idea but the checksum changes [1]). Typically, this jar would be versioned alongside the rest of the sources - the decision to download it dynamically was driven by ASF requirements not to ship binaries with the source code, so the downloading/ sha check is a workaround but it still works as if the wrapper were versioned - for each commit it is fixed to a particular binary. The simplest way to dodge checksum checking would be a small adjustment to gradlew scripts in which - if the env URLs are provided, we use them, download and install the jar/gradle distro and skip the original WrapperDownloader (which does checksum checking)... This said, I think it's better to keep those checksums - this will avoid potential odd surprises in the future. If you live behind a corporate firewall then it's fairly easy to create a directory structure for each gradle version needed + the corresponding wrapper (what I tried to show in the description of this patch). This is a one-time effort, the directory structure stays the same on disk and you can keep the env pointer URLs constant (they can use the replaceable gradleVersion part). [1] https://gradle.org/release-checksums/ -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
