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.r...@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.r...@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.r...@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.r...@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
