You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Nicolas Malin <ni...@nereide.fr> on 2019/06/22 14:53:22 UTC
[DISCUSSION] where download gradle-wrapper.jar ?
Hello,
With the commit r1861766 on trunk[1], I removed gradle-wrapper.jar from
source (OFBIZ-10145[2]) and now we download it at the first time when
you run 'gradlew'. It's fast download (55ko) so normally transparent
You can try yourself after update your trunk, it's esay :) .
Jacques and me have a different vision on where we should download the
jar and before continue to propagate the deleting on stable branches, I
like to get your opinion.
Jacques suggests to store the gradle-wrapper.jar 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 ?
Nicolas
[1]
https://svn.apache.org/viewvc?diff_format=h&view=revision&revision=1861766
[2] https://issues.apache.org/jira/browse/OFBIZ-10145
[3]
https://svn.apache.org/repos/asf/ofbiz/tools/Buildbot/Gradle/Wrapper/trunk/
[4] https://github.com/gradle/gradle/tree/v5.0.0/gradle/wrapper
--
logoNrd <https://nereide.fr/>
Nicolas Malin
The apache way <http://theapacheway.com/> : *Charity* Apache’s mission
is providing software for the public good.
information@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54
Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way
<http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks Nicolas,
The reason I finally decided to get this way is commented here: https://s.apache.org/Vsy3
In few words, we can no longer find the 2.13 wrapper version at https://github.com/gradle/gradle/tree/v2.13/gradle/wrapper like we still can for 3.2.1
and 5.0
Our stable release relies on it. It's a blocker. And I fear the same could happen in future for newer OFBiz releases. That's why I prefer to keep
copies in our repo.
BTW, Swapnil raised a new issue yesterday. With the current solution what to do for our users when we upgrade Gradle on the trunk?
I suggested a simple solution, so better to read at least the last comments, thanks.
As always, all ideas are welcome
Jacques
Le 22/06/2019 à 16:53, Nicolas Malin a écrit :
> Hello,
>
> With the commit r1861766 on trunk[1], I removed gradle-wrapper.jar from source (OFBIZ-10145[2]) and now we download it at the first time when you
> run 'gradlew'. It's fast download (55ko) so normally transparent
>
> You can try yourself after update your trunk, it's esay :) .
>
> Jacques and me have a different vision on where we should download the jar and before continue to propagate the deleting on stable branches, I like
> to get your opinion.
>
> Jacques suggests to store the gradle-wrapper.jar 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 ?
>
>
> Nicolas
>
> [1] https://svn.apache.org/viewvc?diff_format=h&view=revision&revision=1861766
> [2] https://issues.apache.org/jira/browse/OFBIZ-10145
> [3] https://svn.apache.org/repos/asf/ofbiz/tools/Buildbot/Gradle/Wrapper/trunk/
> [4] https://github.com/gradle/gradle/tree/v5.0.0/gradle/wrapper
>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 25/06/2019 à 13:53, Taher Alkhateeb a écrit :
> powershell is a necessity on any
> Microsoft platform.
Hi Taher,
Actually we need Powershell anyway. Dos script does not allow to get files from Internet. We need Invoke-WebRequest for that (aliased as wget in[1])
This is not an issue. Invoke-WebRequest was put in with Powershell 3.0 which is available in Windows 7[2] and anyway you can still follow[3]
[1] https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/gradle/init-gradle-wrapper.ps1
[2] https://en.wikipedia.org/wiki/PowerShell#PowerShell_3.0
[3] https://codehollow.com/2016/02/invoke-webrequests-via-powershell/
HTH
Jacques
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Nicolas Malin <ni...@nereide.fr>.
Hello,
I think also it's a good compromise. At the beginning I would implement
the alternative from 17.12, so you confirm my feeling.
I see the following step :
* publish 16.11.06 without gradle-wrapper.jar and the documentation
updated to initialize it
* prepare the release 17.12, 18.12 and trunk with a script to download
gradle-wrapper.jar related
* publish 17.12.01 without gradle-wrapper.jar, the documentation
updated to initialize it and the helper script.
I will check your proposition for le 16.11 and if my stepping is ok your
you I can works on release branch to finalise this long task :)
Nicolas
On 7/31/19 12:29 PM, Jacopo Cappellato wrote:
> Hi Jacques,
> I saw your comment, thanks.
>
> However, at least for the upcoming 16.11 release, my preference is to
> minimize the changes/additions and stick to one solid workflow: install
> JDK + install Gradle + run "gradle wrapper".
> In this way we will avoid the concerns of using our branch repo for serving
> files and we will buy some time to think and test these alternative
> solutions.
>
> Jacopo
>
>
> On Tue, Jul 30, 2019 at 4:41 PM Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Hi Jacopo,
>>
>> I put a suggestion to keep init-gradle-wrapper scripts in Jira.
>>
>> It would need a simplification of init-gradle-wrapper.sh, to simply load
>> the wrapper from the branch repo.
>>
>> Jacques
>>
>> Le 30/07/2019 à 11:59, Jacopo Cappellato a écrit :
>>> As regards the preparation for the new release from 16.11 please have a
>>> look at my last comment (and patch) in OFBIZ-10145:
>>>
>>>
>> https://issues.apache.org/jira/browse/OFBIZ-10145?focusedCommentId=16895978&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16895978
>>> This approach should be inline with what was suggested by Mathieu Lirzin
>>> and seconded by others.
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>>
>>>
>>> On Wed, Jul 10, 2019 at 11:54 AM Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>>> Thanks Swapnil, @All,
>>>>
>>>> In Builbot config, I have reverted the commits related to grabbing
>> Gradle
>>>> Wrapper files from tools.
>>>> The Gradle Wrapper files will stay in branches and trunk, so not point
>>>> getting them during builds.
>>>> For the same reason, I have also removed the copies in
>>>> tools\Buildbot\Gradle\Wrapper.
>>>>
>>>> As we know all we be handled during RM. I'll work on documentation soon.
>>>> I'll also provide an init-gradle-wrapper.ps1 script in OFBIZ-10145.
>>>> To be used as an alternative to Gradle Wrapper manual installation in
>> new
>>>> R16+ released packages.
>>>>
>>>> Jacques
>>>>
>>>> Le 10/07/2019 à 07:17, Swapnil M Mane a écrit :
>>>>> Thanks so much, Jacques and Nicolas for your help in this, highly
>>>>> appreciated.
>>>>> Also, thank you, everyone involved in the efforts!
>>>>>
>>>>>
>>>>> Best Regards,
>>>>> Swapnil M Mane,
>>>>> ofbiz.apache.org
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 9, 2019 at 8:22 PM Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com>
>>>>> wrote:
>>>>>
>>>>>> Le 04/07/2019 à 12:06, Jacques Le Roux a écrit :
>>>>>>> Le 04/07/2019 à 11:07, Nicolas Malin a écrit :
>>>>>>>> On 03/07/2019 14:27, Jacques Le Roux wrote:
>>>>>>>>> Le 02/07/2019 à 09:45, Jacques Le Roux a écrit :
>>>>>>>>>> Le 02/07/2019 à 08:46, Jacopo Cappellato a écrit :
>>>>>>>>>>> On Tue, Jul 2, 2019 at 7:14 AM Jacques Le Roux <
>>>>>> jacques.le.roux@les7arts.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> [...]
>>>>>>>>>>>> It's only a RM issue. It's when packaging that we are tying
>> OFBiz
>>>>>> code
>>>>>>>>>>>> with a Gradle version.
>>>>>>>>>>>>
>>>>>>>>>>>> It's only then that we need to modify the gradlew script, to
>> call
>>>> an
>>>>>>>>>>>> init-gradle-wrapper script if the wrapper is missing.
>>>>>>>>>>>>
>>>>>>>>>>>> What do you think folks? Notably you Jacopo, with your RM hat
>> on?
>>>>>>>>>>> I think that the direction we are heading is to not include it in
>>>> the
>>>>>>>>>>> releases and add instructions in the release's README file to
>> tell
>>>>>> the user
>>>>>>>>>>> how to download it.
>>>>>>>>>>> So we could keep the wrappers (if we like) in the trunk and/or
>>>>>> release
>>>>>>>>>>> branches and remove them when we package/publish a new release.
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>> Keeping the wrapper in branches is certainly easier for demos,
>>>>>> Buildbot and working copies.
>>>>>>>>>> For the releases, my proposition was to alleviate the charge on
>>>> users
>>>>>> and their customers.
>>>>>>>>>> I'm not against letting them grab it. Maybe we could deliver an
>>>>>> init-gradle-wrapper script version which would do the work for them
>>>>>>>>>> But again we would need to maintain it and it's benign to grab the
>>>>>> wrapper files and put them in OFBiz-root-dir/gradle/wrapper folder.
>>>>>>>>>> Back to basic :)
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> OK, if nobody is against, I'll revert all related changes in trunk
>>>>>> (including Nicolas's and Mathieu's) and Buildbot in 3 days, and will
>>>> close
>>>>>>>>> OFBIZ-10145.
>>>>>>>>>
>>>>>>>>> No maintenance will be needed, all will be handled during the RM
>>>> phase
>>>>>> as Jacopo initially suggested.
>>>>>>>>> We will need to keep only the "Manual setting" section (w/o its
>>>> title)
>>>>>> in the main README.adoc. And to clearly document the RM phase.
>>>>>>>>> Thank you to all who discussed and provided ideas and code.
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>> No problem to revert on trunk however I'm in favor to keep an
>>>>>> init-gradle-wrapper to help first discovery without complex
>> preparation
>>>> and
>>>>>> the
>>>>>>>> script maintenance is really easy.
>>>>>>>>
>>>>>>>> So we can have on documentation advisable part with install gradle
>>>> from
>>>>>> official source and other part for unfamiliar people with quick start
>>>>>>>> through init-gradle-wrapper.
>>>>>>>>
>>>>>>>> After I'm always disturbed to have a different process to initialize
>>>>>> OFBiz between release branch and released package but I can live very
>>>> well
>>>>>>>> with it.
>>>>>>>>
>>>>>>>> Nicolas
>>>>>>>>
>>>>>>>>
>>>>>>> This can even exist for Windows: +1
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> At revision: 1862745 I have removed all changes done for OFBIZ-10145 <
>>>>>> https://issues.apache.org/jira/browse/OFBIZ-10145> so far. The
>> wrapper
>>>>>> stays in
>>>>>> branches and trunk. Now all should be handled during the Release
>>>>>> Management phase.
>>>>>>
>>>>>> I'll soon tackle the documentation changes...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Nicolas Malin <ni...@nereide.fr>.
Jacques, in line
On 8/1/19 1:08 PM, Jacques Le Roux wrote:
> I also read there:
>
> <<Release Policy specifies that binary packages provided by third
> parties which meet certain criteria may be distributed alongside
> official source
> packages. Such packages are sometimes referred to as "convenience
> binaries" to distinguish them from other binary packages.>>
>
> It gave me another idea. I think we (the OFBiz community) could agree
> that the Gradle wrapper files are "convenience binaries provided by
> third parties which meet certain criteria". Then we can discuss (or
> ask legal) if "distributed alongside official source packages"
> includes downloading them later. That would avoid OFBiz repo in the
> very rare case where the wrapper would not be available in Gradle
> "repo". But it a bit more complicated and not sure it's worth
> following this way
I write my previous message before this your proposition :) , I agree !
we (I) can ask the the board :
"[1] All official releases MUST be uploaded to the official distribution
channel, |www.apache.org/dist|.
Content suitable for the official distribution channel includes:
* Official releases
* "Convenience binaries"
* Cryptographic signatures and checksums
* The KEYS file
* README, CHANGES and similar documents describing distributed content
If an Apache PMC wishes to publish additional materials through the
official distribution channel and there is any question about the
suitability of said materials, the PMC MUST consult with the Board.
"
If you are on case "Convenience binaries", we can share through dist, I
ask the board to confirm that with are on the way, woulfd be a confidence
Nicolas
[1] http://www.apache.org/dev/release-distribution
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Jacopo,
Inline too
Le 01/08/2019 à 07:34, Jacopo Cappellato a écrit :
> Hi Jacques,
>
> please see inline:
>
> On Wed, Jul 31, 2019 at 6:52 PM Jacques Le Roux <
> jacques.le.roux@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
The download would be from OFBiz repo not from https://dist.apache.org/repos/dist/.
This said I get the idea, and it gave me another: as a priority we should download the wrapper from Gradle "repo", and if it's not longer there, use
OFBiz repo. Later would be very rare.
I'll add that in OFBIZ-10145, in order to provide new init-gradle-wrapper scripts for hopefully next releases...
>
>
>> 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.
I also read there:
<<Release Policy specifies that binary packages provided by third parties which meet certain criteria may be distributed alongside official source
packages. Such packages are sometimes referred to as "convenience binaries" to distinguish them from other binary packages.>>
It gave me another idea. I think we (the OFBiz community) could agree that the Gradle wrapper files are "convenience binaries provided by third
parties which meet certain criteria". Then we can discuss (or ask legal) if "distributed alongside official source packages" includes downloading them
later. That would avoid OFBiz repo in the very rare case where the wrapper would not be available in Gradle "repo". But it a bit more complicated and
not sure it's worth following this way
> - MUST NOT be advertised to anyone outside of the project development
> community.
I don't think we would advertise it
> - MAY be distributed to consenting members of a development community."
Again the idea of putting the Gradle wrapper files surges here. Again seems convoluted. I believe Gradle will not soon remove from their "repo" the
wrapper versions which are used by R17 and R18.
Anyway it's not mine to decide but the 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
>>
I must add here that I'm not doing that for myself but to ease UX. That's why it's not something I'm much opinionated about, after all it's only sugar
for users...
Nevertheless, we could also have the init scripts in the branches (to be removed when releasing if we don't agree with my proposition) for devs, like
at least Nicolas and I, who want an easiest experience when installing for customers...
I can't think at anything else :)
Jacques
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 06/08/2019 à 11:40, Jacopo Cappellato a écrit :
> On Mon, Aug 5, 2019 at 7:08 PM Jacques Le Roux <ja...@les7arts.com>
> wrote:
>
>> And to be clear: we don't need to muck around testing if a version is not
>> on Gradle Github.
>>
>> We can directly take it from Bintray, et voilà :) Can't be simpler!
>
> I agree that Bintray seems a good idea: my only concern is about the
> license of the binary file; are we allowed to create one and license it
> with an compatible license?
>
> Jacopo
I'm not sure about the issue you think about. If I refer at https://github.com/gradle/gradle/issues/2852 there should be no issues. It's plain ASL2
licensed like all the rest of Gradle, isn'it?
The users will possibly download it after they downloaded the package.
Do I miss something?
Jacques
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacopo Cappellato <ja...@gmail.com>.
On Mon, Aug 5, 2019 at 7:08 PM Jacques Le Roux <ja...@les7arts.com>
wrote:
> And to be clear: we don't need to muck around testing if a version is not
> on Gradle Github.
>
> We can directly take it from Bintray, et voilà :) Can't be simpler!
I agree that Bintray seems a good idea: my only concern is about the
license of the binary file; are we allowed to create one and license it
with an compatible license?
Jacopo
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
And to be clear: we don't need to muck around testing if a version is not on Gradle Github.
We can directly take it from Bintray, et voilà :) Can't be simpler!
Le 05/08/2019 à 12:03, Jacques Le Roux a écrit :
> Hi Nicolas,
>
> I think your idea of using Bintray is the best ! Simple, no question to ask to anybody.-
>
> This also answers to the message you specifically sent to me :)
>
> Jacques
>
> Le 05/08/2019 à 10:03, Nicolas Malin a écrit :
>> 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.roux@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
>>>>
>>
>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Nicolas,
I think your idea of using Bintray is the best ! Simple, no question to ask to anybody.-
This also answers to the message you specifically sent to me :)
Jacques
Le 05/08/2019 à 10:03, Nicolas Malin a écrit :
> 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.roux@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
>>>
>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Nicolas Malin <ni...@nereide.fr>.
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.roux@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
>>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacopo Cappellato <ja...@gmail.com>.
Hi Jacques,
please see inline:
On Wed, Jul 31, 2019 at 6:52 PM Jacques Le Roux <
jacques.le.roux@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
>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
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.
From the legal perspective, I don't see any issues.
But I'm not much opinionated for R16 either. Let's do it this way then.
Jacques
Le 31/07/2019 à 12:29, Jacopo Cappellato a écrit :
> Hi Jacques,
> I saw your comment, thanks.
>
> However, at least for the upcoming 16.11 release, my preference is to
> minimize the changes/additions and stick to one solid workflow: install
> JDK + install Gradle + run "gradle wrapper".
> In this way we will avoid the concerns of using our branch repo for serving
> files and we will buy some time to think and test these alternative
> solutions.
>
> Jacopo
>
>
> On Tue, Jul 30, 2019 at 4:41 PM Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Hi Jacopo,
>>
>> I put a suggestion to keep init-gradle-wrapper scripts in Jira.
>>
>> It would need a simplification of init-gradle-wrapper.sh, to simply load
>> the wrapper from the branch repo.
>>
>> Jacques
>>
>> Le 30/07/2019 à 11:59, Jacopo Cappellato a écrit :
>>> As regards the preparation for the new release from 16.11 please have a
>>> look at my last comment (and patch) in OFBIZ-10145:
>>>
>>>
>> https://issues.apache.org/jira/browse/OFBIZ-10145?focusedCommentId=16895978&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16895978
>>> This approach should be inline with what was suggested by Mathieu Lirzin
>>> and seconded by others.
>>>
>>> Regards,
>>>
>>> Jacopo
>>>
>>>
>>>
>>> On Wed, Jul 10, 2019 at 11:54 AM Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>>> Thanks Swapnil, @All,
>>>>
>>>> In Builbot config, I have reverted the commits related to grabbing
>> Gradle
>>>> Wrapper files from tools.
>>>> The Gradle Wrapper files will stay in branches and trunk, so not point
>>>> getting them during builds.
>>>> For the same reason, I have also removed the copies in
>>>> tools\Buildbot\Gradle\Wrapper.
>>>>
>>>> As we know all we be handled during RM. I'll work on documentation soon.
>>>> I'll also provide an init-gradle-wrapper.ps1 script in OFBIZ-10145.
>>>> To be used as an alternative to Gradle Wrapper manual installation in
>> new
>>>> R16+ released packages.
>>>>
>>>> Jacques
>>>>
>>>> Le 10/07/2019 à 07:17, Swapnil M Mane a écrit :
>>>>> Thanks so much, Jacques and Nicolas for your help in this, highly
>>>>> appreciated.
>>>>> Also, thank you, everyone involved in the efforts!
>>>>>
>>>>>
>>>>> Best Regards,
>>>>> Swapnil M Mane,
>>>>> ofbiz.apache.org
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 9, 2019 at 8:22 PM Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com>
>>>>> wrote:
>>>>>
>>>>>> Le 04/07/2019 à 12:06, Jacques Le Roux a écrit :
>>>>>>> Le 04/07/2019 à 11:07, Nicolas Malin a écrit :
>>>>>>>> On 03/07/2019 14:27, Jacques Le Roux wrote:
>>>>>>>>> Le 02/07/2019 à 09:45, Jacques Le Roux a écrit :
>>>>>>>>>> Le 02/07/2019 à 08:46, Jacopo Cappellato a écrit :
>>>>>>>>>>> On Tue, Jul 2, 2019 at 7:14 AM Jacques Le Roux <
>>>>>> jacques.le.roux@les7arts.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> [...]
>>>>>>>>>>>> It's only a RM issue. It's when packaging that we are tying
>> OFBiz
>>>>>> code
>>>>>>>>>>>> with a Gradle version.
>>>>>>>>>>>>
>>>>>>>>>>>> It's only then that we need to modify the gradlew script, to
>> call
>>>> an
>>>>>>>>>>>> init-gradle-wrapper script if the wrapper is missing.
>>>>>>>>>>>>
>>>>>>>>>>>> What do you think folks? Notably you Jacopo, with your RM hat
>> on?
>>>>>>>>>>> I think that the direction we are heading is to not include it in
>>>> the
>>>>>>>>>>> releases and add instructions in the release's README file to
>> tell
>>>>>> the user
>>>>>>>>>>> how to download it.
>>>>>>>>>>> So we could keep the wrappers (if we like) in the trunk and/or
>>>>>> release
>>>>>>>>>>> branches and remove them when we package/publish a new release.
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>> Keeping the wrapper in branches is certainly easier for demos,
>>>>>> Buildbot and working copies.
>>>>>>>>>> For the releases, my proposition was to alleviate the charge on
>>>> users
>>>>>> and their customers.
>>>>>>>>>> I'm not against letting them grab it. Maybe we could deliver an
>>>>>> init-gradle-wrapper script version which would do the work for them
>>>>>>>>>> But again we would need to maintain it and it's benign to grab the
>>>>>> wrapper files and put them in OFBiz-root-dir/gradle/wrapper folder.
>>>>>>>>>> Back to basic :)
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> OK, if nobody is against, I'll revert all related changes in trunk
>>>>>> (including Nicolas's and Mathieu's) and Buildbot in 3 days, and will
>>>> close
>>>>>>>>> OFBIZ-10145.
>>>>>>>>>
>>>>>>>>> No maintenance will be needed, all will be handled during the RM
>>>> phase
>>>>>> as Jacopo initially suggested.
>>>>>>>>> We will need to keep only the "Manual setting" section (w/o its
>>>> title)
>>>>>> in the main README.adoc. And to clearly document the RM phase.
>>>>>>>>> Thank you to all who discussed and provided ideas and code.
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>> No problem to revert on trunk however I'm in favor to keep an
>>>>>> init-gradle-wrapper to help first discovery without complex
>> preparation
>>>> and
>>>>>> the
>>>>>>>> script maintenance is really easy.
>>>>>>>>
>>>>>>>> So we can have on documentation advisable part with install gradle
>>>> from
>>>>>> official source and other part for unfamiliar people with quick start
>>>>>>>> through init-gradle-wrapper.
>>>>>>>>
>>>>>>>> After I'm always disturbed to have a different process to initialize
>>>>>> OFBiz between release branch and released package but I can live very
>>>> well
>>>>>>>> with it.
>>>>>>>>
>>>>>>>> Nicolas
>>>>>>>>
>>>>>>>>
>>>>>>> This can even exist for Windows: +1
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> At revision: 1862745 I have removed all changes done for OFBIZ-10145 <
>>>>>> https://issues.apache.org/jira/browse/OFBIZ-10145> so far. The
>> wrapper
>>>>>> stays in
>>>>>> branches and trunk. Now all should be handled during the Release
>>>>>> Management phase.
>>>>>>
>>>>>> I'll soon tackle the documentation changes...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacopo Cappellato <ja...@gmail.com>.
Hi Jacques,
I saw your comment, thanks.
However, at least for the upcoming 16.11 release, my preference is to
minimize the changes/additions and stick to one solid workflow: install
JDK + install Gradle + run "gradle wrapper".
In this way we will avoid the concerns of using our branch repo for serving
files and we will buy some time to think and test these alternative
solutions.
Jacopo
On Tue, Jul 30, 2019 at 4:41 PM Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Hi Jacopo,
>
> I put a suggestion to keep init-gradle-wrapper scripts in Jira.
>
> It would need a simplification of init-gradle-wrapper.sh, to simply load
> the wrapper from the branch repo.
>
> Jacques
>
> Le 30/07/2019 à 11:59, Jacopo Cappellato a écrit :
> > As regards the preparation for the new release from 16.11 please have a
> > look at my last comment (and patch) in OFBIZ-10145:
> >
> >
> https://issues.apache.org/jira/browse/OFBIZ-10145?focusedCommentId=16895978&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16895978
> >
> > This approach should be inline with what was suggested by Mathieu Lirzin
> > and seconded by others.
> >
> > Regards,
> >
> > Jacopo
> >
> >
> >
> > On Wed, Jul 10, 2019 at 11:54 AM Jacques Le Roux <
> > jacques.le.roux@les7arts.com> wrote:
> >
> >> Thanks Swapnil, @All,
> >>
> >> In Builbot config, I have reverted the commits related to grabbing
> Gradle
> >> Wrapper files from tools.
> >> The Gradle Wrapper files will stay in branches and trunk, so not point
> >> getting them during builds.
> >> For the same reason, I have also removed the copies in
> >> tools\Buildbot\Gradle\Wrapper.
> >>
> >> As we know all we be handled during RM. I'll work on documentation soon.
> >> I'll also provide an init-gradle-wrapper.ps1 script in OFBIZ-10145.
> >> To be used as an alternative to Gradle Wrapper manual installation in
> new
> >> R16+ released packages.
> >>
> >> Jacques
> >>
> >> Le 10/07/2019 à 07:17, Swapnil M Mane a écrit :
> >>> Thanks so much, Jacques and Nicolas for your help in this, highly
> >>> appreciated.
> >>> Also, thank you, everyone involved in the efforts!
> >>>
> >>>
> >>> Best Regards,
> >>> Swapnil M Mane,
> >>> ofbiz.apache.org
> >>>
> >>>
> >>>
> >>> On Tue, Jul 9, 2019 at 8:22 PM Jacques Le Roux <
> >> jacques.le.roux@les7arts.com>
> >>> wrote:
> >>>
> >>>> Le 04/07/2019 à 12:06, Jacques Le Roux a écrit :
> >>>>> Le 04/07/2019 à 11:07, Nicolas Malin a écrit :
> >>>>>> On 03/07/2019 14:27, Jacques Le Roux wrote:
> >>>>>>> Le 02/07/2019 à 09:45, Jacques Le Roux a écrit :
> >>>>>>>> Le 02/07/2019 à 08:46, Jacopo Cappellato a écrit :
> >>>>>>>>> On Tue, Jul 2, 2019 at 7:14 AM Jacques Le Roux <
> >>>> jacques.le.roux@les7arts.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> [...]
> >>>>>>>>>> It's only a RM issue. It's when packaging that we are tying
> OFBiz
> >>>> code
> >>>>>>>>>> with a Gradle version.
> >>>>>>>>>>
> >>>>>>>>>> It's only then that we need to modify the gradlew script, to
> call
> >> an
> >>>>>>>>>> init-gradle-wrapper script if the wrapper is missing.
> >>>>>>>>>>
> >>>>>>>>>> What do you think folks? Notably you Jacopo, with your RM hat
> on?
> >>>>>>>>> I think that the direction we are heading is to not include it in
> >> the
> >>>>>>>>> releases and add instructions in the release's README file to
> tell
> >>>> the user
> >>>>>>>>> how to download it.
> >>>>>>>>> So we could keep the wrappers (if we like) in the trunk and/or
> >>>> release
> >>>>>>>>> branches and remove them when we package/publish a new release.
> >>>>>>>>>
> >>>>>>>>> Jacopo
> >>>>>>>> Keeping the wrapper in branches is certainly easier for demos,
> >>>> Buildbot and working copies.
> >>>>>>>> For the releases, my proposition was to alleviate the charge on
> >> users
> >>>> and their customers.
> >>>>>>>> I'm not against letting them grab it. Maybe we could deliver an
> >>>> init-gradle-wrapper script version which would do the work for them
> >>>>>>>> But again we would need to maintain it and it's benign to grab the
> >>>> wrapper files and put them in OFBiz-root-dir/gradle/wrapper folder.
> >>>>>>>> Back to basic :)
> >>>>>>>>
> >>>>>>>> Jacques
> >>>>>>>>
> >>>>>>>>
> >>>>>>> OK, if nobody is against, I'll revert all related changes in trunk
> >>>> (including Nicolas's and Mathieu's) and Buildbot in 3 days, and will
> >> close
> >>>>>>> OFBIZ-10145.
> >>>>>>>
> >>>>>>> No maintenance will be needed, all will be handled during the RM
> >> phase
> >>>> as Jacopo initially suggested.
> >>>>>>> We will need to keep only the "Manual setting" section (w/o its
> >> title)
> >>>> in the main README.adoc. And to clearly document the RM phase.
> >>>>>>> Thank you to all who discussed and provided ideas and code.
> >>>>>>>
> >>>>>>> Jacques
> >>>>>>>
> >>>>>> No problem to revert on trunk however I'm in favor to keep an
> >>>> init-gradle-wrapper to help first discovery without complex
> preparation
> >> and
> >>>> the
> >>>>>> script maintenance is really easy.
> >>>>>>
> >>>>>> So we can have on documentation advisable part with install gradle
> >> from
> >>>> official source and other part for unfamiliar people with quick start
> >>>>>> through init-gradle-wrapper.
> >>>>>>
> >>>>>> After I'm always disturbed to have a different process to initialize
> >>>> OFBiz between release branch and released package but I can live very
> >> well
> >>>>>> with it.
> >>>>>>
> >>>>>> Nicolas
> >>>>>>
> >>>>>>
> >>>>> This can even exist for Windows: +1
> >>>>>
> >>>>> Jacques
> >>>>>
> >>>>>
> >>>> Hi,
> >>>>
> >>>> At revision: 1862745 I have removed all changes done for OFBIZ-10145 <
> >>>> https://issues.apache.org/jira/browse/OFBIZ-10145> so far. The
> wrapper
> >>>> stays in
> >>>> branches and trunk. Now all should be handled during the Release
> >>>> Management phase.
> >>>>
> >>>> I'll soon tackle the documentation changes...
> >>>>
> >>>> Jacques
> >>>>
> >>>>
>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Jacopo,
I put a suggestion to keep init-gradle-wrapper scripts in Jira.
It would need a simplification of init-gradle-wrapper.sh, to simply load the wrapper from the branch repo.
Jacques
Le 30/07/2019 à 11:59, Jacopo Cappellato a écrit :
> As regards the preparation for the new release from 16.11 please have a
> look at my last comment (and patch) in OFBIZ-10145:
>
> https://issues.apache.org/jira/browse/OFBIZ-10145?focusedCommentId=16895978&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16895978
>
> This approach should be inline with what was suggested by Mathieu Lirzin
> and seconded by others.
>
> Regards,
>
> Jacopo
>
>
>
> On Wed, Jul 10, 2019 at 11:54 AM Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Thanks Swapnil, @All,
>>
>> In Builbot config, I have reverted the commits related to grabbing Gradle
>> Wrapper files from tools.
>> The Gradle Wrapper files will stay in branches and trunk, so not point
>> getting them during builds.
>> For the same reason, I have also removed the copies in
>> tools\Buildbot\Gradle\Wrapper.
>>
>> As we know all we be handled during RM. I'll work on documentation soon.
>> I'll also provide an init-gradle-wrapper.ps1 script in OFBIZ-10145.
>> To be used as an alternative to Gradle Wrapper manual installation in new
>> R16+ released packages.
>>
>> Jacques
>>
>> Le 10/07/2019 à 07:17, Swapnil M Mane a écrit :
>>> Thanks so much, Jacques and Nicolas for your help in this, highly
>>> appreciated.
>>> Also, thank you, everyone involved in the efforts!
>>>
>>>
>>> Best Regards,
>>> Swapnil M Mane,
>>> ofbiz.apache.org
>>>
>>>
>>>
>>> On Tue, Jul 9, 2019 at 8:22 PM Jacques Le Roux <
>> jacques.le.roux@les7arts.com>
>>> wrote:
>>>
>>>> Le 04/07/2019 à 12:06, Jacques Le Roux a écrit :
>>>>> Le 04/07/2019 à 11:07, Nicolas Malin a écrit :
>>>>>> On 03/07/2019 14:27, Jacques Le Roux wrote:
>>>>>>> Le 02/07/2019 à 09:45, Jacques Le Roux a écrit :
>>>>>>>> Le 02/07/2019 à 08:46, Jacopo Cappellato a écrit :
>>>>>>>>> On Tue, Jul 2, 2019 at 7:14 AM Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> [...]
>>>>>>>>>> It's only a RM issue. It's when packaging that we are tying OFBiz
>>>> code
>>>>>>>>>> with a Gradle version.
>>>>>>>>>>
>>>>>>>>>> It's only then that we need to modify the gradlew script, to call
>> an
>>>>>>>>>> init-gradle-wrapper script if the wrapper is missing.
>>>>>>>>>>
>>>>>>>>>> What do you think folks? Notably you Jacopo, with your RM hat on?
>>>>>>>>> I think that the direction we are heading is to not include it in
>> the
>>>>>>>>> releases and add instructions in the release's README file to tell
>>>> the user
>>>>>>>>> how to download it.
>>>>>>>>> So we could keep the wrappers (if we like) in the trunk and/or
>>>> release
>>>>>>>>> branches and remove them when we package/publish a new release.
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>> Keeping the wrapper in branches is certainly easier for demos,
>>>> Buildbot and working copies.
>>>>>>>> For the releases, my proposition was to alleviate the charge on
>> users
>>>> and their customers.
>>>>>>>> I'm not against letting them grab it. Maybe we could deliver an
>>>> init-gradle-wrapper script version which would do the work for them
>>>>>>>> But again we would need to maintain it and it's benign to grab the
>>>> wrapper files and put them in OFBiz-root-dir/gradle/wrapper folder.
>>>>>>>> Back to basic :)
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>> OK, if nobody is against, I'll revert all related changes in trunk
>>>> (including Nicolas's and Mathieu's) and Buildbot in 3 days, and will
>> close
>>>>>>> OFBIZ-10145.
>>>>>>>
>>>>>>> No maintenance will be needed, all will be handled during the RM
>> phase
>>>> as Jacopo initially suggested.
>>>>>>> We will need to keep only the "Manual setting" section (w/o its
>> title)
>>>> in the main README.adoc. And to clearly document the RM phase.
>>>>>>> Thank you to all who discussed and provided ideas and code.
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>> No problem to revert on trunk however I'm in favor to keep an
>>>> init-gradle-wrapper to help first discovery without complex preparation
>> and
>>>> the
>>>>>> script maintenance is really easy.
>>>>>>
>>>>>> So we can have on documentation advisable part with install gradle
>> from
>>>> official source and other part for unfamiliar people with quick start
>>>>>> through init-gradle-wrapper.
>>>>>>
>>>>>> After I'm always disturbed to have a different process to initialize
>>>> OFBiz between release branch and released package but I can live very
>> well
>>>>>> with it.
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>
>>>>> This can even exist for Windows: +1
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>> Hi,
>>>>
>>>> At revision: 1862745 I have removed all changes done for OFBIZ-10145 <
>>>> https://issues.apache.org/jira/browse/OFBIZ-10145> so far. The wrapper
>>>> stays in
>>>> branches and trunk. Now all should be handled during the Release
>>>> Management phase.
>>>>
>>>> I'll soon tackle the documentation changes...
>>>>
>>>> Jacques
>>>>
>>>>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacopo Cappellato <ja...@gmail.com>.
As regards the preparation for the new release from 16.11 please have a
look at my last comment (and patch) in OFBIZ-10145:
https://issues.apache.org/jira/browse/OFBIZ-10145?focusedCommentId=16895978&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16895978
This approach should be inline with what was suggested by Mathieu Lirzin
and seconded by others.
Regards,
Jacopo
On Wed, Jul 10, 2019 at 11:54 AM Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Thanks Swapnil, @All,
>
> In Builbot config, I have reverted the commits related to grabbing Gradle
> Wrapper files from tools.
> The Gradle Wrapper files will stay in branches and trunk, so not point
> getting them during builds.
> For the same reason, I have also removed the copies in
> tools\Buildbot\Gradle\Wrapper.
>
> As we know all we be handled during RM. I'll work on documentation soon.
> I'll also provide an init-gradle-wrapper.ps1 script in OFBIZ-10145.
> To be used as an alternative to Gradle Wrapper manual installation in new
> R16+ released packages.
>
> Jacques
>
> Le 10/07/2019 à 07:17, Swapnil M Mane a écrit :
> > Thanks so much, Jacques and Nicolas for your help in this, highly
> > appreciated.
> > Also, thank you, everyone involved in the efforts!
> >
> >
> > Best Regards,
> > Swapnil M Mane,
> > ofbiz.apache.org
> >
> >
> >
> > On Tue, Jul 9, 2019 at 8:22 PM Jacques Le Roux <
> jacques.le.roux@les7arts.com>
> > wrote:
> >
> >> Le 04/07/2019 à 12:06, Jacques Le Roux a écrit :
> >>> Le 04/07/2019 à 11:07, Nicolas Malin a écrit :
> >>>> On 03/07/2019 14:27, Jacques Le Roux wrote:
> >>>>> Le 02/07/2019 à 09:45, Jacques Le Roux a écrit :
> >>>>>> Le 02/07/2019 à 08:46, Jacopo Cappellato a écrit :
> >>>>>>> On Tue, Jul 2, 2019 at 7:14 AM Jacques Le Roux <
> >> jacques.le.roux@les7arts.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> [...]
> >>>>>>>> It's only a RM issue. It's when packaging that we are tying OFBiz
> >> code
> >>>>>>>> with a Gradle version.
> >>>>>>>>
> >>>>>>>> It's only then that we need to modify the gradlew script, to call
> an
> >>>>>>>> init-gradle-wrapper script if the wrapper is missing.
> >>>>>>>>
> >>>>>>>> What do you think folks? Notably you Jacopo, with your RM hat on?
> >>>>>>> I think that the direction we are heading is to not include it in
> the
> >>>>>>> releases and add instructions in the release's README file to tell
> >> the user
> >>>>>>> how to download it.
> >>>>>>> So we could keep the wrappers (if we like) in the trunk and/or
> >> release
> >>>>>>> branches and remove them when we package/publish a new release.
> >>>>>>>
> >>>>>>> Jacopo
> >>>>>> Keeping the wrapper in branches is certainly easier for demos,
> >> Buildbot and working copies.
> >>>>>> For the releases, my proposition was to alleviate the charge on
> users
> >> and their customers.
> >>>>>> I'm not against letting them grab it. Maybe we could deliver an
> >> init-gradle-wrapper script version which would do the work for them
> >>>>>> But again we would need to maintain it and it's benign to grab the
> >> wrapper files and put them in OFBiz-root-dir/gradle/wrapper folder.
> >>>>>> Back to basic :)
> >>>>>>
> >>>>>> Jacques
> >>>>>>
> >>>>>>
> >>>>> OK, if nobody is against, I'll revert all related changes in trunk
> >> (including Nicolas's and Mathieu's) and Buildbot in 3 days, and will
> close
> >>>>> OFBIZ-10145.
> >>>>>
> >>>>> No maintenance will be needed, all will be handled during the RM
> phase
> >> as Jacopo initially suggested.
> >>>>> We will need to keep only the "Manual setting" section (w/o its
> title)
> >> in the main README.adoc. And to clearly document the RM phase.
> >>>>> Thank you to all who discussed and provided ideas and code.
> >>>>>
> >>>>> Jacques
> >>>>>
> >>>> No problem to revert on trunk however I'm in favor to keep an
> >> init-gradle-wrapper to help first discovery without complex preparation
> and
> >> the
> >>>> script maintenance is really easy.
> >>>>
> >>>> So we can have on documentation advisable part with install gradle
> from
> >> official source and other part for unfamiliar people with quick start
> >>>> through init-gradle-wrapper.
> >>>>
> >>>> After I'm always disturbed to have a different process to initialize
> >> OFBiz between release branch and released package but I can live very
> well
> >>>> with it.
> >>>>
> >>>> Nicolas
> >>>>
> >>>>
> >>> This can even exist for Windows: +1
> >>>
> >>> Jacques
> >>>
> >>>
> >> Hi,
> >>
> >> At revision: 1862745 I have removed all changes done for OFBIZ-10145 <
> >> https://issues.apache.org/jira/browse/OFBIZ-10145> so far. The wrapper
> >> stays in
> >> branches and trunk. Now all should be handled during the Release
> >> Management phase.
> >>
> >> I'll soon tackle the documentation changes...
> >>
> >> Jacques
> >>
> >>
>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks Swapnil, @All,
In Builbot config, I have reverted the commits related to grabbing Gradle Wrapper files from tools.
The Gradle Wrapper files will stay in branches and trunk, so not point getting them during builds.
For the same reason, I have also removed the copies in tools\Buildbot\Gradle\Wrapper.
As we know all we be handled during RM. I'll work on documentation soon.
I'll also provide an init-gradle-wrapper.ps1 script in OFBIZ-10145.
To be used as an alternative to Gradle Wrapper manual installation in new R16+ released packages.
Jacques
Le 10/07/2019 à 07:17, Swapnil M Mane a écrit :
> Thanks so much, Jacques and Nicolas for your help in this, highly
> appreciated.
> Also, thank you, everyone involved in the efforts!
>
>
> Best Regards,
> Swapnil M Mane,
> ofbiz.apache.org
>
>
>
> On Tue, Jul 9, 2019 at 8:22 PM Jacques Le Roux <ja...@les7arts.com>
> wrote:
>
>> Le 04/07/2019 à 12:06, Jacques Le Roux a écrit :
>>> Le 04/07/2019 à 11:07, Nicolas Malin a écrit :
>>>> On 03/07/2019 14:27, Jacques Le Roux wrote:
>>>>> Le 02/07/2019 à 09:45, Jacques Le Roux a écrit :
>>>>>> Le 02/07/2019 à 08:46, Jacopo Cappellato a écrit :
>>>>>>> On Tue, Jul 2, 2019 at 7:14 AM Jacques Le Roux <
>> jacques.le.roux@les7arts.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> [...]
>>>>>>>> It's only a RM issue. It's when packaging that we are tying OFBiz
>> code
>>>>>>>> with a Gradle version.
>>>>>>>>
>>>>>>>> It's only then that we need to modify the gradlew script, to call an
>>>>>>>> init-gradle-wrapper script if the wrapper is missing.
>>>>>>>>
>>>>>>>> What do you think folks? Notably you Jacopo, with your RM hat on?
>>>>>>> I think that the direction we are heading is to not include it in the
>>>>>>> releases and add instructions in the release's README file to tell
>> the user
>>>>>>> how to download it.
>>>>>>> So we could keep the wrappers (if we like) in the trunk and/or
>> release
>>>>>>> branches and remove them when we package/publish a new release.
>>>>>>>
>>>>>>> Jacopo
>>>>>> Keeping the wrapper in branches is certainly easier for demos,
>> Buildbot and working copies.
>>>>>> For the releases, my proposition was to alleviate the charge on users
>> and their customers.
>>>>>> I'm not against letting them grab it. Maybe we could deliver an
>> init-gradle-wrapper script version which would do the work for them
>>>>>> But again we would need to maintain it and it's benign to grab the
>> wrapper files and put them in OFBiz-root-dir/gradle/wrapper folder.
>>>>>> Back to basic :)
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>> OK, if nobody is against, I'll revert all related changes in trunk
>> (including Nicolas's and Mathieu's) and Buildbot in 3 days, and will close
>>>>> OFBIZ-10145.
>>>>>
>>>>> No maintenance will be needed, all will be handled during the RM phase
>> as Jacopo initially suggested.
>>>>> We will need to keep only the "Manual setting" section (w/o its title)
>> in the main README.adoc. And to clearly document the RM phase.
>>>>> Thank you to all who discussed and provided ideas and code.
>>>>>
>>>>> Jacques
>>>>>
>>>> No problem to revert on trunk however I'm in favor to keep an
>> init-gradle-wrapper to help first discovery without complex preparation and
>> the
>>>> script maintenance is really easy.
>>>>
>>>> So we can have on documentation advisable part with install gradle from
>> official source and other part for unfamiliar people with quick start
>>>> through init-gradle-wrapper.
>>>>
>>>> After I'm always disturbed to have a different process to initialize
>> OFBiz between release branch and released package but I can live very well
>>>> with it.
>>>>
>>>> Nicolas
>>>>
>>>>
>>> This can even exist for Windows: +1
>>>
>>> Jacques
>>>
>>>
>> Hi,
>>
>> At revision: 1862745 I have removed all changes done for OFBIZ-10145 <
>> https://issues.apache.org/jira/browse/OFBIZ-10145> so far. The wrapper
>> stays in
>> branches and trunk. Now all should be handled during the Release
>> Management phase.
>>
>> I'll soon tackle the documentation changes...
>>
>> Jacques
>>
>>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Swapnil M Mane <sw...@apache.org>.
Thanks so much, Jacques and Nicolas for your help in this, highly
appreciated.
Also, thank you, everyone involved in the efforts!
Best Regards,
Swapnil M Mane,
ofbiz.apache.org
On Tue, Jul 9, 2019 at 8:22 PM Jacques Le Roux <ja...@les7arts.com>
wrote:
> Le 04/07/2019 à 12:06, Jacques Le Roux a écrit :
> > Le 04/07/2019 à 11:07, Nicolas Malin a écrit :
> >> On 03/07/2019 14:27, Jacques Le Roux wrote:
> >>> Le 02/07/2019 à 09:45, Jacques Le Roux a écrit :
> >>>> Le 02/07/2019 à 08:46, Jacopo Cappellato a écrit :
> >>>>> On Tue, Jul 2, 2019 at 7:14 AM Jacques Le Roux <
> jacques.le.roux@les7arts.com>
> >>>>> wrote:
> >>>>>
> >>>>>> [...]
> >>>>>
> >>>>>> It's only a RM issue. It's when packaging that we are tying OFBiz
> code
> >>>>>> with a Gradle version.
> >>>>>>
> >>>>>> It's only then that we need to modify the gradlew script, to call an
> >>>>>> init-gradle-wrapper script if the wrapper is missing.
> >>>>>>
> >>>>>> What do you think folks? Notably you Jacopo, with your RM hat on?
> >>>>>
> >>>>> I think that the direction we are heading is to not include it in the
> >>>>> releases and add instructions in the release's README file to tell
> the user
> >>>>> how to download it.
> >>>>> So we could keep the wrappers (if we like) in the trunk and/or
> release
> >>>>> branches and remove them when we package/publish a new release.
> >>>>>
> >>>>> Jacopo
> >>>>
> >>>> Keeping the wrapper in branches is certainly easier for demos,
> Buildbot and working copies.
> >>>>
> >>>> For the releases, my proposition was to alleviate the charge on users
> and their customers.
> >>>>
> >>>> I'm not against letting them grab it. Maybe we could deliver an
> init-gradle-wrapper script version which would do the work for them
> >>>>
> >>>> But again we would need to maintain it and it's benign to grab the
> wrapper files and put them in OFBiz-root-dir/gradle/wrapper folder.
> >>>>
> >>>> Back to basic :)
> >>>>
> >>>> Jacques
> >>>>
> >>>>
> >>> OK, if nobody is against, I'll revert all related changes in trunk
> (including Nicolas's and Mathieu's) and Buildbot in 3 days, and will close
> >>> OFBIZ-10145.
> >>>
> >>> No maintenance will be needed, all will be handled during the RM phase
> as Jacopo initially suggested.
> >>>
> >>> We will need to keep only the "Manual setting" section (w/o its title)
> in the main README.adoc. And to clearly document the RM phase.
> >>>
> >>> Thank you to all who discussed and provided ideas and code.
> >>>
> >>> Jacques
> >>>
> >> No problem to revert on trunk however I'm in favor to keep an
> init-gradle-wrapper to help first discovery without complex preparation and
> the
> >> script maintenance is really easy.
> >>
> >> So we can have on documentation advisable part with install gradle from
> official source and other part for unfamiliar people with quick start
> >> through init-gradle-wrapper.
> >>
> >> After I'm always disturbed to have a different process to initialize
> OFBiz between release branch and released package but I can live very well
> >> with it.
> >>
> >> Nicolas
> >>
> >>
> > This can even exist for Windows: +1
> >
> > Jacques
> >
> >
> Hi,
>
> At revision: 1862745 I have removed all changes done for OFBIZ-10145 <
> https://issues.apache.org/jira/browse/OFBIZ-10145> so far. The wrapper
> stays in
> branches and trunk. Now all should be handled during the Release
> Management phase.
>
> I'll soon tackle the documentation changes...
>
> Jacques
>
>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 04/07/2019 à 12:06, Jacques Le Roux a écrit :
> Le 04/07/2019 à 11:07, Nicolas Malin a écrit :
>> On 03/07/2019 14:27, Jacques Le Roux wrote:
>>> Le 02/07/2019 à 09:45, Jacques Le Roux a écrit :
>>>> Le 02/07/2019 à 08:46, Jacopo Cappellato a écrit :
>>>>> On Tue, Jul 2, 2019 at 7:14 AM Jacques Le Roux <ja...@les7arts.com>
>>>>> wrote:
>>>>>
>>>>>> [...]
>>>>>
>>>>>> It's only a RM issue. It's when packaging that we are tying OFBiz code
>>>>>> with a Gradle version.
>>>>>>
>>>>>> It's only then that we need to modify the gradlew script, to call an
>>>>>> init-gradle-wrapper script if the wrapper is missing.
>>>>>>
>>>>>> What do you think folks? Notably you Jacopo, with your RM hat on?
>>>>>
>>>>> I think that the direction we are heading is to not include it in the
>>>>> releases and add instructions in the release's README file to tell the user
>>>>> how to download it.
>>>>> So we could keep the wrappers (if we like) in the trunk and/or release
>>>>> branches and remove them when we package/publish a new release.
>>>>>
>>>>> Jacopo
>>>>
>>>> Keeping the wrapper in branches is certainly easier for demos, Buildbot and working copies.
>>>>
>>>> For the releases, my proposition was to alleviate the charge on users and their customers.
>>>>
>>>> I'm not against letting them grab it. Maybe we could deliver an init-gradle-wrapper script version which would do the work for them
>>>>
>>>> But again we would need to maintain it and it's benign to grab the wrapper files and put them in OFBiz-root-dir/gradle/wrapper folder.
>>>>
>>>> Back to basic :)
>>>>
>>>> Jacques
>>>>
>>>>
>>> OK, if nobody is against, I'll revert all related changes in trunk (including Nicolas's and Mathieu's) and Buildbot in 3 days, and will close
>>> OFBIZ-10145.
>>>
>>> No maintenance will be needed, all will be handled during the RM phase as Jacopo initially suggested.
>>>
>>> We will need to keep only the "Manual setting" section (w/o its title) in the main README.adoc. And to clearly document the RM phase.
>>>
>>> Thank you to all who discussed and provided ideas and code.
>>>
>>> Jacques
>>>
>> No problem to revert on trunk however I'm in favor to keep an init-gradle-wrapper to help first discovery without complex preparation and the
>> script maintenance is really easy.
>>
>> So we can have on documentation advisable part with install gradle from official source and other part for unfamiliar people with quick start
>> through init-gradle-wrapper.
>>
>> After I'm always disturbed to have a different process to initialize OFBiz between release branch and released package but I can live very well
>> with it.
>>
>> Nicolas
>>
>>
> This can even exist for Windows: +1
>
> Jacques
>
>
Hi,
At revision: 1862745 I have removed all changes done for OFBIZ-10145 <https://issues.apache.org/jira/browse/OFBIZ-10145> so far. The wrapper stays in
branches and trunk. Now all should be handled during the Release Management phase.
I'll soon tackle the documentation changes...
Jacques
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 04/07/2019 à 11:07, Nicolas Malin a écrit :
> On 03/07/2019 14:27, Jacques Le Roux wrote:
>> Le 02/07/2019 à 09:45, Jacques Le Roux a écrit :
>>> Le 02/07/2019 à 08:46, Jacopo Cappellato a écrit :
>>>> On Tue, Jul 2, 2019 at 7:14 AM Jacques Le Roux <ja...@les7arts.com>
>>>> wrote:
>>>>
>>>>> [...]
>>>>
>>>>> It's only a RM issue. It's when packaging that we are tying OFBiz code
>>>>> with a Gradle version.
>>>>>
>>>>> It's only then that we need to modify the gradlew script, to call an
>>>>> init-gradle-wrapper script if the wrapper is missing.
>>>>>
>>>>> What do you think folks? Notably you Jacopo, with your RM hat on?
>>>>
>>>> I think that the direction we are heading is to not include it in the
>>>> releases and add instructions in the release's README file to tell the user
>>>> how to download it.
>>>> So we could keep the wrappers (if we like) in the trunk and/or release
>>>> branches and remove them when we package/publish a new release.
>>>>
>>>> Jacopo
>>>
>>> Keeping the wrapper in branches is certainly easier for demos, Buildbot and working copies.
>>>
>>> For the releases, my proposition was to alleviate the charge on users and their customers.
>>>
>>> I'm not against letting them grab it. Maybe we could deliver an init-gradle-wrapper script version which would do the work for them
>>>
>>> But again we would need to maintain it and it's benign to grab the wrapper files and put them in OFBiz-root-dir/gradle/wrapper folder.
>>>
>>> Back to basic :)
>>>
>>> Jacques
>>>
>>>
>> OK, if nobody is against, I'll revert all related changes in trunk (including Nicolas's and Mathieu's) and Buildbot in 3 days, and will close
>> OFBIZ-10145.
>>
>> No maintenance will be needed, all will be handled during the RM phase as Jacopo initially suggested.
>>
>> We will need to keep only the "Manual setting" section (w/o its title) in the main README.adoc. And to clearly document the RM phase.
>>
>> Thank you to all who discussed and provided ideas and code.
>>
>> Jacques
>>
> No problem to revert on trunk however I'm in favor to keep an init-gradle-wrapper to help first discovery without complex preparation and the script
> maintenance is really easy.
>
> So we can have on documentation advisable part with install gradle from official source and other part for unfamiliar people with quick start
> through init-gradle-wrapper.
>
> After I'm always disturbed to have a different process to initialize OFBiz between release branch and released package but I can live very well with
> it.
>
> Nicolas
>
>
This can even exist for Windows: +1
Jacques
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Nicolas Malin <ni...@nereide.fr>.
On 03/07/2019 14:27, Jacques Le Roux wrote:
> Le 02/07/2019 à 09:45, Jacques Le Roux a écrit :
>> Le 02/07/2019 à 08:46, Jacopo Cappellato a écrit :
>>> On Tue, Jul 2, 2019 at 7:14 AM Jacques Le Roux
>>> <ja...@les7arts.com>
>>> wrote:
>>>
>>>> [...]
>>>
>>>> It's only a RM issue. It's when packaging that we are tying OFBiz code
>>>> with a Gradle version.
>>>>
>>>> It's only then that we need to modify the gradlew script, to call an
>>>> init-gradle-wrapper script if the wrapper is missing.
>>>>
>>>> What do you think folks? Notably you Jacopo, with your RM hat on?
>>>
>>> I think that the direction we are heading is to not include it in the
>>> releases and add instructions in the release's README file to tell
>>> the user
>>> how to download it.
>>> So we could keep the wrappers (if we like) in the trunk and/or release
>>> branches and remove them when we package/publish a new release.
>>>
>>> Jacopo
>>
>> Keeping the wrapper in branches is certainly easier for demos,
>> Buildbot and working copies.
>>
>> For the releases, my proposition was to alleviate the charge on users
>> and their customers.
>>
>> I'm not against letting them grab it. Maybe we could deliver an
>> init-gradle-wrapper script version which would do the work for them
>>
>> But again we would need to maintain it and it's benign to grab the
>> wrapper files and put them in OFBiz-root-dir/gradle/wrapper folder.
>>
>> Back to basic :)
>>
>> Jacques
>>
>>
> OK, if nobody is against, I'll revert all related changes in trunk
> (including Nicolas's and Mathieu's) and Buildbot in 3 days, and will
> close OFBIZ-10145.
>
> No maintenance will be needed, all will be handled during the RM phase
> as Jacopo initially suggested.
>
> We will need to keep only the "Manual setting" section (w/o its title)
> in the main README.adoc. And to clearly document the RM phase.
>
> Thank you to all who discussed and provided ideas and code.
>
> Jacques
>
No problem to revert on trunk however I'm in favor to keep an
init-gradle-wrapper to help first discovery without complex preparation
and the script maintenance is really easy.
So we can have on documentation advisable part with install gradle from
official source and other part for unfamiliar people with quick start
through init-gradle-wrapper.
After I'm always disturbed to have a different process to initialize
OFBiz between release branch and released package but I can live very
well with it.
Nicolas
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 02/07/2019 à 09:45, Jacques Le Roux a écrit :
> Le 02/07/2019 à 08:46, Jacopo Cappellato a écrit :
>> On Tue, Jul 2, 2019 at 7:14 AM Jacques Le Roux <ja...@les7arts.com>
>> wrote:
>>
>>> [...]
>>
>>> It's only a RM issue. It's when packaging that we are tying OFBiz code
>>> with a Gradle version.
>>>
>>> It's only then that we need to modify the gradlew script, to call an
>>> init-gradle-wrapper script if the wrapper is missing.
>>>
>>> What do you think folks? Notably you Jacopo, with your RM hat on?
>>
>> I think that the direction we are heading is to not include it in the
>> releases and add instructions in the release's README file to tell the user
>> how to download it.
>> So we could keep the wrappers (if we like) in the trunk and/or release
>> branches and remove them when we package/publish a new release.
>>
>> Jacopo
>
> Keeping the wrapper in branches is certainly easier for demos, Buildbot and working copies.
>
> For the releases, my proposition was to alleviate the charge on users and their customers.
>
> I'm not against letting them grab it. Maybe we could deliver an init-gradle-wrapper script version which would do the work for them
>
> But again we would need to maintain it and it's benign to grab the wrapper files and put them in OFBiz-root-dir/gradle/wrapper folder.
>
> Back to basic :)
>
> Jacques
>
>
OK, if nobody is against, I'll revert all related changes in trunk (including Nicolas's and Mathieu's) and Buildbot in 3 days, and will close OFBIZ-10145.
No maintenance will be needed, all will be handled during the RM phase as Jacopo initially suggested.
We will need to keep only the "Manual setting" section (w/o its title) in the main README.adoc. And to clearly document the RM phase.
Thank you to all who discussed and provided ideas and code.
Jacques
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 02/07/2019 à 08:46, Jacopo Cappellato a écrit :
> On Tue, Jul 2, 2019 at 7:14 AM Jacques Le Roux <ja...@les7arts.com>
> wrote:
>
>> [...]
>
>> It's only a RM issue. It's when packaging that we are tying OFBiz code
>> with a Gradle version.
>>
>> It's only then that we need to modify the gradlew script, to call an
>> init-gradle-wrapper script if the wrapper is missing.
>>
>> What do you think folks? Notably you Jacopo, with your RM hat on?
>
> I think that the direction we are heading is to not include it in the
> releases and add instructions in the release's README file to tell the user
> how to download it.
> So we could keep the wrappers (if we like) in the trunk and/or release
> branches and remove them when we package/publish a new release.
>
> Jacopo
Keeping the wrapper in branches is certainly easier for demos, Buildbot and working copies.
For the releases, my proposition was to alleviate the charge on users and their customers.
I'm not against letting them grab it. Maybe we could deliver an init-gradle-wrapper script version which would do the work for them
But again we would need to maintain it and it's benign to grab the wrapper files and put them in OFBiz-root-dir/gradle/wrapper folder.
Back to basic :)
Jacques
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacopo Cappellato <ja...@gmail.com>.
On Tue, Jul 2, 2019 at 7:14 AM Jacques Le Roux <ja...@les7arts.com>
wrote:
> [...]
> It's only a RM issue. It's when packaging that we are tying OFBiz code
> with a Gradle version.
>
> It's only then that we need to modify the gradlew script, to call an
> init-gradle-wrapper script if the wrapper is missing.
>
> What do you think folks? Notably you Jacopo, with your RM hat on?
I think that the direction we are heading is to not include it in the
releases and add instructions in the release's README file to tell the user
how to download it.
So we could keep the wrappers (if we like) in the trunk and/or release
branches and remove them when we package/publish a new release.
Jacopo
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 02/07/2019 à 07:13, Jacques Le Roux a écrit :
> Then the connexion to get the wrapper is only once during the installation, the scaling issue is peanuts.
If ever we worry about the load on the ASF svn (or git) server (really we should not), why not use Gradle Github as suggested Nicolas?
My concern was that sometimes the wrapper disappears there. But that should be only in a far future for old, no longer supported, OFBiz releases.
If we do so we could also use https://services.gradle.org/distributions to verify the wrapper checksum.
Sincerely I don't think it's needed, I just mention it as a second argument.
Jacques
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
A last thing that you pointed to in OFBIZ-10145 Swapnil.
Security issue with a Gradle version used in an already released package.
Like with other security issues we have no other way than letting the user upgrade OFBiz.
So we don't need to "allow imperceptible Gradle upgrade".
Then the connexion to get the wrapper is only once during the installation, the scaling issue is peanuts.
I trust we all agree to keep the wrapper in the trunk. It's not an issue there. We can revert the changes we did in trunk.
It's only a RM issue. It's when packaging that we are tying OFBiz code with a Gradle version.
It's only then that we need to modify the gradlew script, to call an init-gradle-wrapper script if the wrapper is missing.
What do you think folks? Notably you Jacopo, with your RM hat on?
Jacques
Le 01/07/2019 à 13:36, Swapnil M Mane a écrit :
> Thanks, everyone for sharing your kind thoughts.
> I am also inclined towards allowing users to follow the standard Gradle
> installation process.
>
> We tried our best to make the user's life easier by avoiding their
> intervention in downloading respective Gradle (resulting the changes in
> gradlew and gradlew.bat files and writing init-gradle-wrapper script),
> but, it seems this will brings various complexities and maintenance issues
> to us like
> -- Upgrading the Gradle version
> -- Distribution of the wrapper jar
>
> So IMO, let's keep things simple and let the users follow standard Gradle
> installation.
>
>
> Best Regards,
> Swapnil M Mane,
> ofbiz.apache.org
>
>
>
> On Mon, Jul 1, 2019 at 1:52 PM Jacques Le Roux <ja...@les7arts.com>
> wrote:
>
>> Le 01/07/2019 à 06:53, Jacopo Cappellato a écrit :
>>> On Sun, Jun 30, 2019 at 5:31 PM Mathieu Lirzin <
>> mathieu.lirzin@nereide.fr>
>>> wrote:
>>>
>>>> [...]
>>>> As a consequence, I would recommend keeping the wrapper jar in our VCS
>>>> repository, and simply remove it along side the “gradlew” scripts from
>>>> our release archives. We would then provide preliminary build
>>>> instructions stating the required version of Gradle and let users choose
>>>> how they want to install it [1].
>>>>
>>>> [1] https://docs.gradle.org/current/userguide/installation.html
>>> I tend to agree with Mathieu.
>>> The above approach would also cover another concern I had with some of
>> the
>>> proposals: since release files can be downloaded by a potentially large
>>> number of users, they must be distributed thru the mirror network [*];
>>> distributing the wrapper jar from our svn, git or website would not scale
>>> up well and could cause excessive load on these server.
>>>
>>> Jacopo
>>>
>>> [*] https://www.apache.org/dev/release-distribution
>> After working on a Buildbot solution, I suggested this way because I
>> thought it would be easy for our users, and maybe our own tranquillity.
>>
>> I did not think about scaling. We speak about 55 Kb, the connexions would
>> be very short, so not much at the same time.
>>
>> It started from this Mark Thomas's remark in LEGAL-288:
>>
>> <<The JARs are small and will be downloaded as part of the source tree
>> so I don't think Infra would have any objections.>>
>>
>> Though with my last proposition, to allow imperceptible Gradle upgrade,
>> this download would be for each call to OFBiz gradlew anywhere. That's
>> indeed
>> something to consider.
>>
>> Nicolas suggested to get the wrapper from Git. That can be done, but needs
>> a solution when it disappears there. And it's maybe not fair to them.
>>
>> I agree, the easiest way for us is certainly to let users follow the
>> standard Gradle installation process as they do for Java.
>>
>> I'm not against that, just another step that we tried to avoid to our
>> users and their customers.
>>
>> For working copies checked out (including Buildbot and demos) we can keep
>> the wrapper where it is.
>>
>> Following LEGAL-288, that's what I initially described in OFBIZ-10145. It
>> was a nice tour :)
>>
>> Can we conclude?
>>
>> Jacques
>>
>>
>>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Swapnil M Mane <sw...@apache.org>.
Thanks, everyone for sharing your kind thoughts.
I am also inclined towards allowing users to follow the standard Gradle
installation process.
We tried our best to make the user's life easier by avoiding their
intervention in downloading respective Gradle (resulting the changes in
gradlew and gradlew.bat files and writing init-gradle-wrapper script),
but, it seems this will brings various complexities and maintenance issues
to us like
-- Upgrading the Gradle version
-- Distribution of the wrapper jar
So IMO, let's keep things simple and let the users follow standard Gradle
installation.
Best Regards,
Swapnil M Mane,
ofbiz.apache.org
On Mon, Jul 1, 2019 at 1:52 PM Jacques Le Roux <ja...@les7arts.com>
wrote:
> Le 01/07/2019 à 06:53, Jacopo Cappellato a écrit :
> > On Sun, Jun 30, 2019 at 5:31 PM Mathieu Lirzin <
> mathieu.lirzin@nereide.fr>
> > wrote:
> >
> >> [...]
> >> As a consequence, I would recommend keeping the wrapper jar in our VCS
> >> repository, and simply remove it along side the “gradlew” scripts from
> >> our release archives. We would then provide preliminary build
> >> instructions stating the required version of Gradle and let users choose
> >> how they want to install it [1].
> >>
> >> [1] https://docs.gradle.org/current/userguide/installation.html
> >
> > I tend to agree with Mathieu.
> > The above approach would also cover another concern I had with some of
> the
> > proposals: since release files can be downloaded by a potentially large
> > number of users, they must be distributed thru the mirror network [*];
> > distributing the wrapper jar from our svn, git or website would not scale
> > up well and could cause excessive load on these server.
> >
> > Jacopo
> >
> > [*] https://www.apache.org/dev/release-distribution
>
> After working on a Buildbot solution, I suggested this way because I
> thought it would be easy for our users, and maybe our own tranquillity.
>
> I did not think about scaling. We speak about 55 Kb, the connexions would
> be very short, so not much at the same time.
>
> It started from this Mark Thomas's remark in LEGAL-288:
>
> <<The JARs are small and will be downloaded as part of the source tree
> so I don't think Infra would have any objections.>>
>
> Though with my last proposition, to allow imperceptible Gradle upgrade,
> this download would be for each call to OFBiz gradlew anywhere. That's
> indeed
> something to consider.
>
> Nicolas suggested to get the wrapper from Git. That can be done, but needs
> a solution when it disappears there. And it's maybe not fair to them.
>
> I agree, the easiest way for us is certainly to let users follow the
> standard Gradle installation process as they do for Java.
>
> I'm not against that, just another step that we tried to avoid to our
> users and their customers.
>
> For working copies checked out (including Buildbot and demos) we can keep
> the wrapper where it is.
>
> Following LEGAL-288, that's what I initially described in OFBIZ-10145. It
> was a nice tour :)
>
> Can we conclude?
>
> Jacques
>
>
>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 01/07/2019 à 06:53, Jacopo Cappellato a écrit :
> On Sun, Jun 30, 2019 at 5:31 PM Mathieu Lirzin <ma...@nereide.fr>
> wrote:
>
>> [...]
>> As a consequence, I would recommend keeping the wrapper jar in our VCS
>> repository, and simply remove it along side the “gradlew” scripts from
>> our release archives. We would then provide preliminary build
>> instructions stating the required version of Gradle and let users choose
>> how they want to install it [1].
>>
>> [1] https://docs.gradle.org/current/userguide/installation.html
>
> I tend to agree with Mathieu.
> The above approach would also cover another concern I had with some of the
> proposals: since release files can be downloaded by a potentially large
> number of users, they must be distributed thru the mirror network [*];
> distributing the wrapper jar from our svn, git or website would not scale
> up well and could cause excessive load on these server.
>
> Jacopo
>
> [*] https://www.apache.org/dev/release-distribution
After working on a Buildbot solution, I suggested this way because I thought it would be easy for our users, and maybe our own tranquillity.
I did not think about scaling. We speak about 55 Kb, the connexions would be very short, so not much at the same time.
It started from this Mark Thomas's remark in LEGAL-288:
<<The JARs are small and will be downloaded as part of the source tree so I don't think Infra would have any objections.>>
Though with my last proposition, to allow imperceptible Gradle upgrade, this download would be for each call to OFBiz gradlew anywhere. That's indeed
something to consider.
Nicolas suggested to get the wrapper from Git. That can be done, but needs a solution when it disappears there. And it's maybe not fair to them.
I agree, the easiest way for us is certainly to let users follow the standard Gradle installation process as they do for Java.
I'm not against that, just another step that we tried to avoid to our users and their customers.
For working copies checked out (including Buildbot and demos) we can keep the wrapper where it is.
Following LEGAL-288, that's what I initially described in OFBIZ-10145. It was a nice tour :)
Can we conclude?
Jacques
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacopo Cappellato <ja...@gmail.com>.
On Sun, Jun 30, 2019 at 5:31 PM Mathieu Lirzin <ma...@nereide.fr>
wrote:
> [...]
> As a consequence, I would recommend keeping the wrapper jar in our VCS
> repository, and simply remove it along side the “gradlew” scripts from
> our release archives. We would then provide preliminary build
> instructions stating the required version of Gradle and let users choose
> how they want to install it [1].
>
> [1] https://docs.gradle.org/current/userguide/installation.html
I tend to agree with Mathieu.
The above approach would also cover another concern I had with some of the
proposals: since release files can be downloaded by a potentially large
number of users, they must be distributed thru the mirror network [*];
distributing the wrapper jar from our svn, git or website would not scale
up well and could cause excessive load on these server.
Jacopo
[*] https://www.apache.org/dev/release-distribution
>
>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Mathieu, Nicolas,
@Mathieu, I disagree. IMO this is part of the release process and can be handled by the RM (Release Manager).
When releasing, all the RM has to do is to verify the version in the wrapper is the right one. It it's not, s/he must upgrade Gradle locally and save
the wrapper files in tools.
This saving must be done just after the upgrade. Else the local wrapper files will be overwritten by the ones in tools at the next use of the gradlew
script (yes, I got caught by that :/).
There should be trivial side effect in gradlew scripts due to the Gradle upgrade. Currently only the test on wrapper presence in
init-gradle-wrapper.sh and the ASL2 license header are removed.
It's only one block, easy to put back from repo. This will be documented for the RM as mentioned in OFBIZ-10145.
I'm not the release manager but all committers can do the same for the trunk. And that's what I did.
After applying the last waiting gradlew.bat.patch in OFBIZ-10145 I was able to follow this way.
BTW, I was mislead by Gradle versions names in URL (sometimes?) inconsistent. You have
https://github.com/gradle/gradle/tree/v5.5.0/gradle/wrapper (5.5.0) (used as RELEASE value in init-gradle-wrapper.sh)
but
https://services.gradle.org/distributions/gradle-5.5-bin.zip (5.5)
So to update Gradle it's
|gradlew wrapper --gradle-version=5.5 --distribution-type=all|
not
gradlew wrapper --gradle-version 5.5.0|--distribution-type=all|
All is better for IDE, default is bin[1].
@Mathieu, I found a trivial issue in your last commits and fixed it: repeated "-Xms64m" in gradlew scripts.
@Nicolas, the version of init-gradle-wrapper.ps1 you committed used HTTPS. I have changed that to HTTP, not everyone has an HTTPS access to the tools
repo.
Anyway, using the last command worked for me on Windows.
I committed the trunk and tools changes.
[1] https://mrhaki.blogspot.com/2016/09/gradle-goodness-specify-wrapper-version.html
Jacques
Le 30/06/2019 à 17:31, Mathieu Lirzin a écrit :
> Hello Nicolas,
>
> Nicolas Malin <ni...@nereide.fr> writes:
>
>> 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.
> ‘grep’ and ‘whereis’ are currently needed in a Unix environment too. ;-)
>
>> We take the jar, put it directly at the good place and continue the job.
> Unfortunately this is not that simple. Here are two important
> requirements that the current version of “init-gradle-wrapper.sh” is not
> handling:
>
> 1) The integrity of downloaded jar must be checked (via
> checksum). This is important both for reliability and security
> reasons. If we don't do that our users are vulnerable to DNS
> spoofing.
>
> 2) The downloaded jar needs to be automatically upgraded. Currently
> when committers are upgrading Gradle (like I just did in revision
> 1862326) the users must delete their “gradle-wrapper.jar”
> manually to not keep using their local outdated version which
> might be incompatible.
>
> In fact the more I think about the problem we are trying to solve, the
> more I am convinced we should not try to write our own additional layer
> of build system which if done seriously will lead to complex code.
>
> Gradle wrapper is suppposed to be a convenience both for maintainers and
> users to facilitate the use of a single and consistent version of
> Gradle. IMO with the requirement of not distributing
> “gradle-wrapper.jar” in our releases this is becoming a burden for
> maintainers and an unreliable solution for users.
>
> As a consequence, I would recommend keeping the wrapper jar in our VCS
> repository, and simply remove it along side the “gradlew” scripts from
> our release archives. We would then provide preliminary build
> instructions stating the required version of Gradle and let users choose
> how they want to install it [1].
>
> [1] https://docs.gradle.org/current/userguide/installation.html
>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Hello Nicolas,
Nicolas Malin <ni...@nereide.fr> writes:
> 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.
‘grep’ and ‘whereis’ are currently needed in a Unix environment too. ;-)
> We take the jar, put it directly at the good place and continue the job.
Unfortunately this is not that simple. Here are two important
requirements that the current version of “init-gradle-wrapper.sh” is not
handling:
1) The integrity of downloaded jar must be checked (via
checksum). This is important both for reliability and security
reasons. If we don't do that our users are vulnerable to DNS
spoofing.
2) The downloaded jar needs to be automatically upgraded. Currently
when committers are upgrading Gradle (like I just did in revision
1862326) the users must delete their “gradle-wrapper.jar”
manually to not keep using their local outdated version which
might be incompatible.
In fact the more I think about the problem we are trying to solve, the
more I am convinced we should not try to write our own additional layer
of build system which if done seriously will lead to complex code.
Gradle wrapper is suppposed to be a convenience both for maintainers and
users to facilitate the use of a single and consistent version of
Gradle. IMO with the requirement of not distributing
“gradle-wrapper.jar” in our releases this is becoming a burden for
maintainers and an unreliable solution for users.
As a consequence, I would recommend keeping the wrapper jar in our VCS
repository, and simply remove it along side the “gradlew” scripts from
our release archives. We would then provide preliminary build
instructions stating the required version of Gradle and let users choose
how they want to install it [1].
[1] https://docs.gradle.org/current/userguide/installation.html
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Nicolas Malin <ni...@nereide.fr>.
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 <ni...@nereide.fr> 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
>>>> <ma...@nereide.fr> wrote:
>>>>> Mathieu Lirzin <ma...@nereide.fr> writes:
>>>>>
>>>>>> Nicolas Malin <ni...@nereide.fr> 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
>>>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Taher Alkhateeb <sl...@gmail.com>.
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 <ni...@nereide.fr> 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
> >> <ma...@nereide.fr> wrote:
> >>> Mathieu Lirzin <ma...@nereide.fr> writes:
> >>>
> >>>> Nicolas Malin <ni...@nereide.fr> 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
> >
> >
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 26/06/2019 à 16:17, Jacques Le Roux a écrit :
> Using ofbiz/tools/gradle/wrapper/v3.2.1/*, as you suggest, fits also with me :)
It's actually a (slightly) better solution, because then there no duplication (we speak about Kb here). Though it's maybe less clear than named
revisions. Anyway it's the community to decide
Jacques
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
>>> <ma...@nereide.fr> wrote:
>>>> Mathieu Lirzin <ma...@nereide.fr> writes:
>>>>
>>>>> Nicolas Malin <ni...@nereide.fr> 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
>>
>>
>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Nicolas Malin <ni...@nereide.fr>.
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
>> <ma...@nereide.fr> wrote:
>>> Mathieu Lirzin <ma...@nereide.fr> writes:
>>>
>>>> Nicolas Malin <ni...@nereide.fr> 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
>
>
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Yes, as long as we don't release it there are no problems with that.
Jacques
Le 23/06/2019 à 17:38, Taher Alkhateeb a écrit :
> I think the gradle-wrapper.jar should be maintained inside the code
> base as an exceptional thing, otherwise it would be quite painful to
> administer the system.
>
> 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.
>
> On Sun, Jun 23, 2019 at 4:58 PM Mathieu Lirzin
> <ma...@nereide.fr> wrote:
>> Mathieu Lirzin <ma...@nereide.fr> writes:
>>
>>> Nicolas Malin <ni...@nereide.fr> writes:
>>>
>>>> Jacques suggests to store the gradle-wrapper.jar 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
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Taher Alkhateeb <sl...@gmail.com>.
I think the gradle-wrapper.jar should be maintained inside the code
base as an exceptional thing, otherwise it would be quite painful to
administer the system.
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.
On Sun, Jun 23, 2019 at 4:58 PM Mathieu Lirzin
<ma...@nereide.fr> wrote:
>
> Mathieu Lirzin <ma...@nereide.fr> writes:
>
> > Nicolas Malin <ni...@nereide.fr> writes:
> >
> >> Jacques suggests to store the gradle-wrapper.jar 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
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Mathieu Lirzin <ma...@nereide.fr> writes:
> Nicolas Malin <ni...@nereide.fr> writes:
>
>> Jacques suggests to store the gradle-wrapper.jar 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
Re: [DISCUSSION] where download gradle-wrapper.jar ?
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Hello,
Nicolas Malin <ni...@nereide.fr> writes:
> With the commit r1861766 on trunk[1], I removed gradle-wrapper.jar
> from source (OFBIZ-10145[2]) and now we download it at the first time
> when you run 'gradlew'. It's fast download (55ko) so normally
> transparent
>
> You can try yourself after update your trunk, it's esay :) .
The “gradlew-wrapper.jar” should not have been removed from ‘trunk’ in
the first place. Sorry for repeating myself but the requirements of not
distributing this jar is concerning only the *releases archives* not the
*repositories* as stated in LEGAL-288 [1].
For convenience it has been proposed to patch the “gradlew” script
included in *release archive* instead of providing only the instructions
telling the user how to download the wrapper manually.
The act of patching the “gradlew” script should be done at release time,
and we should not commit the patched script in our VCS repository since
as Swapnil [2] explained it doesn't play well with the standard way of
upgrading Gradle:
$ ./gradlew wrapper --gradle-version=5.4.1 --distribution-type=bin
I don't have an opinion regarding how the patching process should be
documented in the release instructions.
[1] https://issues.apache.org/jira/browse/LEGAL-288?focusedCommentId=15980830&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-15980830
[2] https://issues.apache.org/jira/browse/OFBIZ-10145?focusedCommentId=16869382&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16869382
> Jacques and me have a different vision on where we should download the
> jar and before continue to propagate the deleting on stable branches,
> I like to get your opinion.
Can you add “gradlew-wrapper.jar” back in ‘trunk’ instead? :-)
> Jacques suggests to store the gradle-wrapper.jar 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?
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37