Hello, Nicolas Malin <[email protected]> writes:
> With the commit r1861766 on trunk[1], I removed gradle-wrapper.jar > from source (OFBIZ-10145[2]) and now we download it at the first time > when you run 'gradlew'. It's fast download (55ko) so normally > transparent > > You can try yourself after update your trunk, it's esay :) . The “gradlew-wrapper.jar” should not have been removed from ‘trunk’ in the first place. Sorry for repeating myself but the requirements of not distributing this jar is concerning only the *releases archives* not the *repositories* as stated in LEGAL-288 [1]. For convenience it has been proposed to patch the “gradlew” script included in *release archive* instead of providing only the instructions telling the user how to download the wrapper manually. The act of patching the “gradlew” script should be done at release time, and we should not commit the patched script in our VCS repository since as Swapnil [2] explained it doesn't play well with the standard way of upgrading Gradle: $ ./gradlew wrapper --gradle-version=5.4.1 --distribution-type=bin I don't have an opinion regarding how the patching process should be documented in the release instructions. [1] https://issues.apache.org/jira/browse/LEGAL-288?focusedCommentId=15980830&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-15980830 [2] https://issues.apache.org/jira/browse/OFBIZ-10145?focusedCommentId=16869382&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16869382 > Jacques and me have a different vision on where we should download the > jar and before continue to propagate the deleting on stable branches, > I like to get your opinion. Can you add “gradlew-wrapper.jar” back in ‘trunk’ instead? :-) > Jacques suggests to store the gradle-wrapper.jar on own tools > repository source[3] and download through viewvc with one wrapper by > stable branch. > I suggest to download it from gradle community on github and store the > release to download in own code source[4] > > Your opinion ? or other idea ? IMO storing Gradle binary releases in our own infrastructure is too much trouble. If we don't trust Gradle binaries to continue to be available in the future, we maybe should use another build system instead of keeping trying to keep our copies of its binary releases. No? -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
