You can go ahead and give it a try, however the main problem you might face would perhaps be the complex logic that you need to add to "gradlew" and "gradlew.bat" scripts to download the jar if it does not exist. Now that wrapper jar is difficult to obtain because I think you can only get it from inside the compressed archive of a certain distribution.
So think about it, the logic in these two scripts (bash & windows batch) should have the following logic in it: 1 - download the correct compressed archive binary 2 - uncompress it 3 - copy the wrapper jar to the correct location The first two items above require installation of certain tools on the operating system like curl, wget, zip, etc ... which means they won't work out of the box and requirements to run ofbiz would go beyond simply installing java. That's what I meant by difficult and complex. Another downsize to heavy customization of these scripts is that the upgrade process of the wrapper in the new version becomes more involved because these scripts are auto generated by gradle, and so merging these changes into your custom logic might be more work. Now to reduce that complexity we might switch from a batch script to a powershell script instead, but that would mean converting the entire script to powershell and also means powershell is a necessity on any Microsoft platform. So if we bypass the wrapper script as an exceptional thing, it would be the easiest way to move forward and I think this was discussed elsewhere in the ASF before (perhaps LEGAL). To summarize, I'm not objecting to doing it if you would like to push in that direction, but it would perhaps be annoying and complex to implement. On Tue, Jun 25, 2019 at 12:49 PM Nicolas Malin <[email protected]> wrote: > > My vision is to have the code base near the building package as > possible. If we keep gradle-wrapper.jar for developing comfort, it's a > risk for me to generate an issue on release package due to not enough > test after package creation. > > > Le 23/06/2019 à 17:38, Taher Alkhateeb a écrit : > >> [...] > >> The gradle wrapper is difficult to download and obtain, and is usually > >> provided using a gradle command (installed gradle on the platform. So > >> it's best to just keep it in. > > Taher do you show any difficulties with the trunk to resolve > automatically and download the wrapper ? > > > Otherwise, I have a problem with the resolution on gradle-wrapper based > only on branches, with that the wrapper resolved would be always the up > to date related to branch code base. It's nice for demo, buildbot and > developer but open a potential problem for package. > > 16.05 works with gradle 3.2.1 for any reason we need to update the > wrapper to 4.0.0, 16.06 works with it but all previous package has been > a potential incompatibility.We can decide to say it's not own problem > however I prefer to offer a solution more flexible like store the > wrapper by version : ofbiz/tools/gradle/wrapper/v3.2.1/* as the gradle > community works. Also possibility to call wrapper verion by wrapper it > self, I really une preference to resolve direclty the wrapper on the > good version. > > On second time I prefer to resolve the wrapper from the origin community > (keep resolution near source code, have always source origin) but after > different remarks maybe we can couple gradle community and own > resolution form own repository as fallback. > > Nicolas > > > >> > >> On Sun, Jun 23, 2019 at 4:58 PM Mathieu Lirzin > >> <[email protected]> wrote: > >>> Mathieu Lirzin <[email protected]> writes: > >>> > >>>> Nicolas Malin <[email protected]> writes: > >>>> > >>>>> Jacques suggests to store the 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? > >>> I overlooked that we were not speaking of downloading the binary > >>> releases, but only of the “gradle-wrapper.jar” which should already be > >>> avaibable in our VCS branches in order to comply with Gradle wrapping > >>> recommendations as I advocated in my previous mail. > >>> > >>> Given that each release archive can point to its corresponding > >>> repository branch to find its associated “gradle-wrapper.jar”, it is > >>> basically free in term of maintenance. Then I agree with Jacques > >>> option. > >>> > >>> Sorry for the confusion. > >>> > >>> -- > >>> Mathieu Lirzin > >>> GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 > > > >
