I would had tend to be agree with you with the first step done.
At this time, only [curl,wget] is necessary, and download realease at
the fisrt gradlew command call.
We take the jar, put it directly at the good place and continue the job.
If the person haven't [curl,wget], it's in general more easier to load
it instead java jre, and if no Internet is present this solve the
problem because he can't continue anyway to download OFBiz's dependencies :)
Nicolas
On 25/06/2019 13:53, Taher Alkhateeb wrote:
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
