Thanks Jacopo for spot these rules.
Currently with the script helper, I used the github location [1] to
download the wrapper and if failed backup used own svn.
If use the svn as sparse is a problem I can have different solution :
* No use backup, if github gradle wrapper isn't available, they can
use manual process
* Load gradle wrapper on own dist as backup and before ask the board
for this solution
* Load the wrapper on bintray [2], because we download after all jar
from here
if you have a felling about this, it will be nice :)
[1] https://github.com/gradle/gradle/tree/v5.0.0/gradle/wrapper
[2]
https://bintray.com/bintray/jcenter/org.gradle%3Agradle-wrapper#files/org/gradle/gradle-wrapper/
Nicolas
On 8/1/19 7:34 AM, Jacopo Cappellato wrote:
Hi Jacques,
please see inline:
On Wed, Jul 31, 2019 at 6:52 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Hi Jacopo,
I still don't see what the concerns could be.
From the performance perspective: the (55 Ko!) download would be done
only once by instance installed; and when only used instead of the manual
procedure.
I am quoting from [*]:
"PLEASE NOTE The SVN directories under https://dist.apache.org/repos/dist/
are not to be used to link to releases on download pages or elsewhere.
Download pages must use the ASF mirror system [...]"
[*] http://www.apache.org/dev/release-publishing.html#distribution
From the legal perspective, I don't see any issues.
For the legal perspective, considering that we would distribute from svn
files that are not part of a release, this may be relevant [**]:
"Unreleased materials, in original or derived form... [...]:
- MUST NOT be distributed through channels which encourage use by anyone
outside the project development community.
- MUST NOT be advertised to anyone outside of the project development
community.
- MAY be distributed to consenting members of a development community."
[**] http://www.apache.org/dev/release-distribution#unreleased
Jacopo
But I'm not much opinionated for R16 either. Let's do it this way then.
Jacques
