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
