Hi Nicolas,
Inline....
Le 25/06/2019 à 11:49, Nicolas Malin a écrit :
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.
Normally the wrapper version in tools corresponds to an OFBiz package, then no
worries at all.
I'd address below the unlikely issue of multiple wrapper versions for an OFBiz
package.
If it's your concern, you have a point with that, we missed it so far and I
thank you for pushing us to think more. BTW same compliment to Swapnil :)
I can't foresee other possible problems, do you have something else in mind?
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.
This is indeed a potential concern if a Gradle version has a (high) vulnerability. We would then (absolutely) need to upgrade Gradle and release new
OFBiz packages for supported branches.This said, it would be indeed an issue in the future for users still using a "not longer supported" OFBiz
released package. Do you see other reasons for discrepancy between the wrapper in tools and an OFBiz package?
I say potential because a high Gradle vulnerability never happened so far and even a low Gradle vulnerability is a very rare thing. It happened once
2+ years ago, only in Gradle 2.12 (04/2016), that we never used[1]. Of course this does not mean that another vulnerability could not happen in future...
Currently the idea is to keep a version of the wrapper by branch as it's done in tools[2]. And already used in Buildbot[3], even if there for the
moment it only overwrites the same version by branch.
I suggest that we not only keep a version by branch but, if necessary, also by versions used by a release package. So, for instance, if we need to
update 16.11.06 to use a newer version of the wrapper we would keep this version in tools as[4], would create scripts specifically for it and embed
them in the package. Using ofbiz/tools/gradle/wrapper/v3.2.1/*, as you suggest, fits also with me :)
[1] https://www.cvedetails.com/vulnerability-list/vendor_id-16071/Gradle.html
(Gradle Enterprise is another thing and not OFBiz responsibility)
[2] https://svn.apache.org/repos/asf/ofbiz/tools/Buildbot/Gradle/Wrapper
[3]
https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/ofbiz.conf
[4]
https://svn.apache.org/repos/asf/ofbiz/tools/Buildbot/Gradle/Wrapper/16.11.06
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
I think I mostly rephrased your proposition to be sure we are on the same page,
and for people to get a clear idea of the situation.
I see only one future problem getting wrappers directly from Gradle community in released OFBiz packages: when it become impossible (eg v2.13). We
don't know when it will happen, we just know that it will happen! Having them saved in our repo is peace of mind...
Again thanks for the discussion :)
Jacques
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
