Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Le 05/01/2024 à 09:25, Daniel Watford a écrit :

git clone --depth 1 --branch $branch
https://github.com/apache/ofbiz-plugins.git  plugins


Hi Daniel,

It needs also --single-branch:
    git clone --depth 1 --single-branch --branch $branch 
https://github.com/apache/ofbiz-plugins.git plugins

It's really fast and sparse

Thanks for the tip

Jacques

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Thanks Daniel,

I'll try that, did not know for the --$branch option

Jacques

Le 05/01/2024 à 09:25, Daniel Watford a écrit :

Hi Jacques,

I note your point about avoiding reply-all when replying to mailing lists.
Gmail seems to have reply-all as the default option - I'll try to avoid it
in future.

When you tried the "--depth=1" option to git clone, did you also include
the "--branch $branch" command line option?

The "--branch $branch" option will retrieve the branch that you are
interested in, avoiding the need for the subsequent. Presumably git clone
will default to the trunk branch if not other branch is specified, and
depth=1 will cause git clone to only retrieve enough data to provide a
single commit of that branch.

Please give the following a try to see if it will download the desired
branch, using the minimum possible data retrieval, in one step:

git clone --depth 1 --branch $branch
https://github.com/apache/ofbiz-plugins.git plugins



On Fri, 5 Jan 2024 at 07:21, Jacques Le Roux 
wrote:


Hi Daniel,

I understand that it easier to be alerted when you receive an email
directly to your email address (inbox).
For Thunderbird msg filtering convenience, and in general for other
reasons*, I prefer to answer only to the ML.
   This is true also for @Eugen, please don't send email directly to me,
TIA to both of you :)

* If you are interested about a previous (long and argumented) discussion
here you go: https://s.apache.org/556a0

This said, I tried with depth=1, and there is an issue. It does not switch
to the current branch. You get, eg "fatal: invalid reference: release22.01"
It works well when using --filter=tree:0 and you download only 6Mb vs 7Mb
with depth=1.

BTW "weirdly" (I have no idea about that) we don't get the depth=1 issue
when using sparse-checkout as in pullPluginSource.
Still I'll rather use --filter=tree:0 since it download a bit less of
data. So I'll push that for both scripts.

I must say that I did not completely read nor watched the article**, only
the the "Quick Summary"
I also only considered the download aspect. I think it's OK. If you have
more indications please tell us, TIA

**
https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/

Thanks for initiating this thread (to Eugen in Jira too)

Jacques

Le 04/01/2024 à 19:19, Jacques Le Roux a écrit :

Yes you are right Daniel, I remember having seen 7.62 Mb for trunk. I'll

change that tmrw :)

Le 04/01/2024 à 18:57, Daniel Watford a écrit :

Hi Jacques,

Using depth=1 means you only download the data you actually need,

rather than retrieving lots of data that is then immediately deleted.

I can't check right now, but from memory I think with depth=1, around

7MB of data was retrieved, compared to around 160MB without depth=1.

We should try and only retrieve needed data if doing so does not

introduce too much complexity.

Thanks,

Dan.

On Thu, 4 Jan 2024 at 09:43, Jacques Le Roux <

jacques.le.r...@les7arts.com> wrote:

 Hi Daniel,

 Reviews are always appreciated :)

 Inline...

 Le 04/01/2024 à 09:23, Daniel Watford a écrit :

 Hi Jacques,

 Sorry for not reviewing earlier, but for the

pullAllPluginsSource.sh you might consider simplifying a little with:

 # Whatever, create anew if [ -d"plugins" ]
  then rm -rf plugins
 fi # Get the branch used by the framework branch=$(git branch

--show-current) git clone --depth1 --branch$branch

https://github.com/apache/ofbiz-plugins.git  plugins

 # remove .git, in this case it's big useless information rm -rf

plugins/.git

 The above avoids creating the temp.txt file to detect the current

branch, and avoids changing directories.

 I'll commit that after your answer below about  depth=1



 FYI, pushd and popd are useful alternatives to cd in scripts -

https://en.wikipedia.org/wiki/Pushd_and_popd

 Thanks for the info, did not know it existed in cmd.exe.



 The git clone command has been altered to select the branch to

clone, and the depth=1 command line argument reduces the size of the clone
to

 the minimum needed for that single branch.

 I'm not sure it's useful because anyway I remove .git, don't you

think so?

 TIA

 Jacques


 Dan.

 On Wed, 3 Jan 2024 at 18:11, Eugen Stan 

wrote:

 Hi Jacques,

 I missed this thread for some reason (was collapsed in TB) and

only saw

 it now.

 I read the thread.
 Glad to see progress on fixing the SVN issue.

 Also inline:

 La 24.12.2023 13:05, Jacques Le Roux a scris:
 > Hi Eugen,
 >
 > I tend to agree with your vision that sounds quite

promising. I'm sorry

 > I got no time to review your PR yet. I hope to do so during

next year...

 It's good that it gets some attention.
 Even if the PR does not get merged as is but is used as

example for the

 idea the PR is meant for.

 > Of course, 

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Daniel Watford]

Hi Jacques,

I note your point about avoiding reply-all when replying to mailing lists.
Gmail seems to have reply-all as the default option - I'll try to avoid it
in future.

When you tried the "--depth=1" option to git clone, did you also include
the "--branch $branch" command line option?

The "--branch $branch" option will retrieve the branch that you are
interested in, avoiding the need for the subsequent. Presumably git clone
will default to the trunk branch if not other branch is specified, and
depth=1 will cause git clone to only retrieve enough data to provide a
single commit of that branch.

Please give the following a try to see if it will download the desired
branch, using the minimum possible data retrieval, in one step:

git clone --depth 1 --branch $branch
https://github.com/apache/ofbiz-plugins.git plugins



On Fri, 5 Jan 2024 at 07:21, Jacques Le Roux 
wrote:

> Hi Daniel,
>
> I understand that it easier to be alerted when you receive an email
> directly to your email address (inbox).
> For Thunderbird msg filtering convenience, and in general for other
> reasons*, I prefer to answer only to the ML.
>   This is true also for @Eugen, please don't send email directly to me,
> TIA to both of you :)
>
> * If you are interested about a previous (long and argumented) discussion
> here you go: https://s.apache.org/556a0
>
> This said, I tried with depth=1, and there is an issue. It does not switch
> to the current branch. You get, eg "fatal: invalid reference: release22.01"
> It works well when using --filter=tree:0 and you download only 6Mb vs 7Mb
> with depth=1.
>
> BTW "weirdly" (I have no idea about that) we don't get the depth=1 issue
> when using sparse-checkout as in pullPluginSource.
> Still I'll rather use --filter=tree:0 since it download a bit less of
> data. So I'll push that for both scripts.
>
> I must say that I did not completely read nor watched the article**, only
> the the "Quick Summary"
> I also only considered the download aspect. I think it's OK. If you have
> more indications please tell us, TIA
>
> **
> https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/
>
> Thanks for initiating this thread (to Eugen in Jira too)
>
> Jacques
>
> Le 04/01/2024 à 19:19, Jacques Le Roux a écrit :
> > Yes you are right Daniel, I remember having seen 7.62 Mb for trunk. I'll
> change that tmrw :)
> >
> > Le 04/01/2024 à 18:57, Daniel Watford a écrit :
> >> Hi Jacques,
> >>
> >> Using depth=1 means you only download the data you actually need,
> rather than retrieving lots of data that is then immediately deleted.
> >>
> >> I can't check right now, but from memory I think with depth=1, around
> 7MB of data was retrieved, compared to around 160MB without depth=1.
> >>
> >> We should try and only retrieve needed data if doing so does not
> introduce too much complexity.
> >>
> >> Thanks,
> >>
> >> Dan.
> >>
> >> On Thu, 4 Jan 2024 at 09:43, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
> >>
> >> Hi Daniel,
> >>
> >> Reviews are always appreciated :)
> >>
> >> Inline...
> >>
> >> Le 04/01/2024 à 09:23, Daniel Watford a écrit :
> >>> Hi Jacques,
> >>>
> >>> Sorry for not reviewing earlier, but for the
> pullAllPluginsSource.sh you might consider simplifying a little with:
> >>>
> >>> # Whatever, create anew if [ -d"plugins" ]
> >>>  then rm -rf plugins
> >>> fi # Get the branch used by the framework branch=$(git branch
> --show-current) git clone --depth1 --branch$branch
> >>> https://github.com/apache/ofbiz-plugins.git  plugins
> >>>
> >>> # remove .git, in this case it's big useless information rm -rf
> plugins/.git
> >>>
> >>> The above avoids creating the temp.txt file to detect the current
> branch, and avoids changing directories.
> >>
> >> I'll commit that after your answer below about  depth=1
> >>
> >>
> >>>
> >>> FYI, pushd and popd are useful alternatives to cd in scripts -
> https://en.wikipedia.org/wiki/Pushd_and_popd
> >>
> >> Thanks for the info, did not know it existed in cmd.exe.
> >>
> >>
> >>>
> >>> The git clone command has been altered to select the branch to
> clone, and the depth=1 command line argument reduces the size of the clone
> to
> >>> the minimum needed for that single branch.
> >>
> >> I'm not sure it's useful because anyway I remove .git, don't you
> think so?
> >>
> >> TIA
> >>
> >> Jacques
> >>
> >>>
> >>> Dan.
> >>>
> >>> On Wed, 3 Jan 2024 at 18:11, Eugen Stan 
> wrote:
> >>>
> >>> Hi Jacques,
> >>>
> >>> I missed this thread for some reason (was collapsed in TB) and
> only saw
> >>> it now.
> >>>
> >>> I read the thread.
> >>> Glad to see progress on fixing the SVN issue.
> >>>
> >>> Also inline:
> >>>
> >>> La 24.12.2023 13:05, Jacques Le Roux a scris:
> >>> > Hi Eugen,
> >>> >
> >>> > I tend to agree with your vision that sounds quite
> promising. 

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Le 05/01/2024 à 08:20, Jacques Le Roux a écrit :

* If you are interested about a previous (long and argumented) discussion here 
you go: https://s.apache.org/556a0


TL;DR, in that email are my principal reasons: 
https://lists.apache.org/thread/o73vxotkd2qgvmctoz6wxn1y05zdb1c5

TIA

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Daniel,

I understand that it easier to be alerted when you receive an email directly to 
your email address (inbox).
For Thunderbird msg filtering convenience, and in general for other reasons*, I 
prefer to answer only to the ML.
 This is true also for @Eugen, please don't send email directly to me, TIA to 
both of you :)

* If you are interested about a previous (long and argumented) discussion here 
you go: https://s.apache.org/556a0

This said, I tried with depth=1, and there is an issue. It does not switch to the current 
branch. You get, eg "fatal: invalid reference: release22.01"
It works well when using --filter=tree:0 and you download only 6Mb vs 7Mb with 
depth=1.

BTW "weirdly" (I have no idea about that) we don't get the depth=1 issue when 
using sparse-checkout as in pullPluginSource.
Still I'll rather use --filter=tree:0 since it download a bit less of data. So 
I'll push that for both scripts.

I must say that I did not completely read nor watched the article**, only the the 
"Quick Summary"
I also only considered the download aspect. I think it's OK. If you have more 
indications please tell us, TIA

** 
https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/

Thanks for initiating this thread (to Eugen in Jira too)

Jacques

Le 04/01/2024 à 19:19, Jacques Le Roux a écrit :

Yes you are right Daniel, I remember having seen 7.62 Mb for trunk. I'll change 
that tmrw :)

Le 04/01/2024 à 18:57, Daniel Watford a écrit :

Hi Jacques,

Using depth=1 means you only download the data you actually need, rather than 
retrieving lots of data that is then immediately deleted.

I can't check right now, but from memory I think with depth=1, around 7MB of 
data was retrieved, compared to around 160MB without depth=1.

We should try and only retrieve needed data if doing so does not introduce too 
much complexity.

Thanks,

Dan.

On Thu, 4 Jan 2024 at 09:43, Jacques Le Roux  
wrote:

    Hi Daniel,

    Reviews are always appreciated :)

    Inline...

    Le 04/01/2024 à 09:23, Daniel Watford a écrit :

    Hi Jacques,

    Sorry for not reviewing earlier, but for the pullAllPluginsSource.sh you 
might consider simplifying a little with:

    # Whatever, create anew if [ -d"plugins" ]
 then rm -rf plugins
    fi # Get the branch used by the framework branch=$(git branch --show-current) git clone --depth1 --branch$branch 
https://github.com/apache/ofbiz-plugins.git  plugins


    # remove .git, in this case it's big useless information rm -rf plugins/.git

    The above avoids creating the temp.txt file to detect the current branch, 
and avoids changing directories.


    I'll commit that after your answer below about  depth=1




    FYI, pushd and popd are useful alternatives to cd in scripts - 
https://en.wikipedia.org/wiki/Pushd_and_popd


    Thanks for the info, did not know it existed in cmd.exe.




    The git clone command has been altered to select the branch to clone, and 
the depth=1 command line argument reduces the size of the clone to
    the minimum needed for that single branch.


    I'm not sure it's useful because anyway I remove .git, don't you think so?

    TIA

    Jacques



    Dan.

    On Wed, 3 Jan 2024 at 18:11, Eugen Stan  wrote:

    Hi Jacques,

    I missed this thread for some reason (was collapsed in TB) and only saw
    it now.

    I read the thread.
    Glad to see progress on fixing the SVN issue.

    Also inline:

    La 24.12.2023 13:05, Jacques Le Roux a scris:
    > Hi Eugen,
    >
    > I tend to agree with your vision that sounds quite promising. I'm 
sorry
    > I got no time to review your PR yet. I hope to do so during next 
year...

    It's good that it gets some attention.
    Even if the PR does not get merged as is but is used as example for the
    idea the PR is meant for.

    > Of course, this architecture will need to be discussed more and
    > especially will not be part of the next release branch (24.01 ? 18.12
    > becoming really old).

    That is ok with me since I plan to use trunk anyway.
    So I guess the sooner we have OFBiz 24.01 the better :D .
    Are there otehr blockers for 24.01 besides the SVN issue?

    >
    > This said I was reading
    > 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
    > and stumbled upon
    > 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md
    >
    > Obviously some parts are obsolete since we rely now on Docker for 
demos.
    > Could you please review and possibly amend?

    Is this for me or for Daniel?
    I assume it's for Daniel (as I read in your next emails).

    > Last but not least, I guess we will need very soon to change something
    > in Docker config for demos ; since pullAllPluginsSource relies on soon
    > not usable SvnCheckout plugin?
    >
  

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Yes you are right Daniel, I remember having seen 7.62 Mb for trunk. I'll change 
that tmrw :)

Le 04/01/2024 à 18:57, Daniel Watford a écrit :

Hi Jacques,

Using depth=1 means you only download the data you actually need, rather than 
retrieving lots of data that is then immediately deleted.

I can't check right now, but from memory I think with depth=1, around 7MB of 
data was retrieved, compared to around 160MB without depth=1.

We should try and only retrieve needed data if doing so does not introduce too 
much complexity.

Thanks,

Dan.

On Thu, 4 Jan 2024 at 09:43, Jacques Le Roux  
wrote:

Hi Daniel,

Reviews are always appreciated :)

Inline...

Le 04/01/2024 à 09:23, Daniel Watford a écrit :

Hi Jacques,

Sorry for not reviewing earlier, but for the pullAllPluginsSource.sh you 
might consider simplifying a little with:

# Whatever, create anew if [ -d"plugins" ]
 then rm -rf plugins
fi # Get the branch used by the framework branch=$(git branch 
--show-current) git clone --depth1 --branch$branch 
https://github.com/apache/ofbiz-plugins.git  plugins

# remove .git, in this case it's big useless information rm -rf plugins/.git

The above avoids creating the temp.txt file to detect the current branch, 
and avoids changing directories.


I'll commit that after your answer below about  depth=1




FYI, pushd and popd are useful alternatives to cd in scripts - 
https://en.wikipedia.org/wiki/Pushd_and_popd


Thanks for the info, did not know it existed in cmd.exe.




The git clone command has been altered to select the branch to clone, and 
the depth=1 command line argument reduces the size of the clone to
the minimum needed for that single branch.


I'm not sure it's useful because anyway I remove .git, don't you think so?

TIA

Jacques



Dan.

On Wed, 3 Jan 2024 at 18:11, Eugen Stan  wrote:

Hi Jacques,

I missed this thread for some reason (was collapsed in TB) and only saw
it now.

I read the thread.
Glad to see progress on fixing the SVN issue.

Also inline:

La 24.12.2023 13:05, Jacques Le Roux a scris:
> Hi Eugen,
>
> I tend to agree with your vision that sounds quite promising. I'm 
sorry
> I got no time to review your PR yet. I hope to do so during next 
year...

It's good that it gets some attention.
Even if the PR does not get merged as is but is used as example for the
idea the PR is meant for.

> Of course, this architecture will need to be discussed more and
> especially will not be part of the next release branch (24.01 ? 18.12
> becoming really old).

That is ok with me since I plan to use trunk anyway.
So I guess the sooner we have OFBiz 24.01 the better :D .
Are there otehr blockers for 24.01 besides the SVN issue?

>
> This said I was reading
> 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
> and stumbled upon
> 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md
>
> Obviously some parts are obsolete since we rely now on Docker for 
demos.
> Could you please review and possibly amend?

Is this for me or for Daniel?
I assume it's for Daniel (as I read in your next emails).

> Last but not least, I guess we will need very soon to change something
> in Docker config for demos ; since pullAllPluginsSource relies on soon
> not usable SvnCheckout plugin?
>
> TIA
>
> Jacques
>
> Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :
>> Hi Jacques,
>>
>> Regarding the plugin workflow, the PR that I posted can offer
>> alternative ways to develop and consume plugins / components.
>> This would make plugin development by pulling sources in ofbiz
>> optional / obsolete even (a choice).
>>
>> If we move to have libraries that are published as jar files, then it
>> would be possible to develop plugins by depending on the specific
>> OFBiz bits.
>> It would also be possible to publish plugins / components as regular
>> java jars and consume them the same way.
>> So, in the future a custom OFBiz build could look something like 
this:
>>
>> build.gradle
>>
>> dependencies {
>>   implementation 'org.apache.ofbiz:entity-engine:24.0'
>>   implementation 'org.apache.ofbiz:service:24.0'
>>   implementation 'org.apache.ofbiz:accounting:24.0'
>>   implementation 'com.example:my-plugin:1.2.3'
>> }
>>
>>
>>
>>
>> On 23.12.2023 17:06, Jacques Le Roux 
>> wrote:
>>> It's ready for review before pushing and testing with GH and BB
 

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Daniel Watford]

Hi Jacques,

Using depth=1 means you only download the data you actually need, rather
than retrieving lots of data that is then immediately deleted.

I can't check right now, but from memory I think with depth=1, around 7MB
of data was retrieved, compared to around 160MB without depth=1.

We should try and only retrieve needed data if doing so does not introduce
too much complexity.

Thanks,

Dan.

On Thu, 4 Jan 2024 at 09:43, Jacques Le Roux 
wrote:

> Hi Daniel,
>
> Reviews are always appreciated :)
>
> Inline...
> Le 04/01/2024 à 09:23, Daniel Watford a écrit :
>
> Hi Jacques,
>
> Sorry for not reviewing earlier, but for the pullAllPluginsSource.sh you
> might consider simplifying a little with:
>
> # Whatever, create anewif [ -d "plugins" ]
> thenrm -rf pluginsfi# Get the branch used by the 
> frameworkbranch=$(git branch --show-current)git clone --depth 1 --branch 
> $branch https://github.com/apache/ofbiz-plugins.git plugins
> # remove .git, in this case it's big useless informationrm -rf plugins/.git
>
>
> The above avoids creating the temp.txt file to detect the current branch,
> and avoids changing directories.
>
> I'll commit that after your answer below about  depth=1
>
>
>
> FYI, pushd and popd are useful alternatives to cd in scripts -
> https://en.wikipedia.org/wiki/Pushd_and_popd
>
> Thanks for the info, did not know it existed in cmd.exe.
>
>
>
> The git clone command has been altered to select the branch to clone, and
> the depth=1 command line argument reduces the size of the clone to the
> minimum needed for that single branch.
>
> I'm not sure it's useful because anyway I remove .git, don't you think so?
>
> TIA
>
> Jacques
>
>
> Dan.
>
> On Wed, 3 Jan 2024 at 18:11, Eugen Stan  wrote:
>
>> Hi Jacques,
>>
>> I missed this thread for some reason (was collapsed in TB) and only saw
>> it now.
>>
>> I read the thread.
>> Glad to see progress on fixing the SVN issue.
>>
>> Also inline:
>>
>> La 24.12.2023 13:05, Jacques Le Roux a scris:
>> > Hi Eugen,
>> >
>> > I tend to agree with your vision that sounds quite promising. I'm sorry
>> > I got no time to review your PR yet. I hope to do so during next year...
>>
>> It's good that it gets some attention.
>> Even if the PR does not get merged as is but is used as example for the
>> idea the PR is meant for.
>>
>> > Of course, this architecture will need to be discussed more and
>> > especially will not be part of the next release branch (24.01 ? 18.12
>> > becoming really old).
>>
>> That is ok with me since I plan to use trunk anyway.
>> So I guess the sooner we have OFBiz 24.01 the better :D .
>> Are there otehr blockers for 24.01 besides the SVN issue?
>>
>> >
>> > This said I was reading
>> >
>> https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
>> > and stumbled upon
>> > https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md
>> >
>> > Obviously some parts are obsolete since we rely now on Docker for
>> demos.
>> > Could you please review and possibly amend?
>>
>> Is this for me or for Daniel?
>> I assume it's for Daniel (as I read in your next emails).
>>
>> > Last but not least, I guess we will need very soon to change something
>> > in Docker config for demos ; since pullAllPluginsSource relies on soon
>> > not usable SvnCheckout plugin?
>> >
>> > TIA
>> >
>> > Jacques
>> >
>> > Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :
>> >> Hi Jacques,
>> >>
>> >> Regarding the plugin workflow, the PR that I posted can offer
>> >> alternative ways to develop and consume plugins / components.
>> >> This would make plugin development by pulling sources in ofbiz
>> >> optional / obsolete even (a choice).
>> >>
>> >> If we move to have libraries that are published as jar files, then it
>> >> would be possible to develop plugins by depending on the specific
>> >> OFBiz bits.
>> >> It would also be possible to publish plugins / components as regular
>> >> java jars and consume them the same way.
>> >> So, in the future a custom OFBiz build could look something like this:
>> >>
>> >> build.gradle
>> >>
>> >> dependencies {
>> >>   implementation 'org.apache.ofbiz:entity-engine:24.0'
>> >>   implementation 'org.apache.ofbiz:service:24.0'
>> >>   implementation 'org.apache.ofbiz:accounting:24.0'
>> >>   implementation 'com.example:my-plugin:1.2.3'
>> >> }
>> >>
>> >>
>> >>
>> >>
>> >> On 23.12.2023 17:06, Jacques Le Roux 
>> >> wrote:
>> >>> It's ready for review before pushing and testing with GH and BB
>> >>>
>> >>> TIA
>> >>>
>> >>> Jacques
>> >>>
>> >>> Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
>> >>> > Hi,
>> >>> >
>> >>> > I have created https://issues.apache.org/jira/browse/OFBIZ-12868
>> >>> for > that... WIP...
>> >>> >
>> >>> > HTH
>> >>> >
>> >>> > Jacques
>> >>> >
>> >>> > Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
>> >>> >> Hi,
>> >>> >>
>> >>> >> As you may have noticed*, the SvnCheckout Gradle plugin will not
>> >>> be >> usable after January 8, 2024.
>> 

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Eugen Stan]

Hi,

Inline:

La 04.01.2024 12:03, Jacques Le Roux a scris:


That is ok with me since I plan to use trunk anyway.
So I guess the sooner we have OFBiz 24.01 the better :D .
Are there otehr blockers for 24.01 besides the SVN issue?


There is OFBIZ-12726 
 that I 
set as a blocker. I think we could continue with the workaround for now, 
the community to decide... 24.01 or such is now pressing...


I think the workaround woks fine for JDk-17 but won't work for JDK-21.
If we start splitting the modules we might make the testing part a bit 
more manageable.

I think testing should be done using standard junit tooling.
I might take a look at this once we start breaking up smaller parts.





This said I was reading 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
and stumbled upon 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md


Obviously some parts are obsolete since we rely now on Docker for 
demos. Could you please review and possibly amend?


Is this for me or for Daniel?
I assume it's for Daniel (as I read in your next emails).

Last but not least, I guess we will need very soon to change 
something in Docker config for demos ; since pullAllPluginsSource 
relies on soon not usable SvnCheckout plugin?


Yes indeed I confused, I finally handled Docker with the task 
https://issues.apache.org/jira/browse/OFBIZ-12876
For the READMEs it's more on my side than Daniel's. I'll clean the whole 
thing with https://issues.apache.org/jira/browse/OFBIZ-12863
For demos, we have now 
https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker




I did not know about ofbiz-tools :) .

Thanks,
--
Eugen Stan

+40770 941 271  / https://www.netdava.com

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Eugen,

Inline too...

Le 03/01/2024 à 19:10, Eugen Stan a écrit :

Hi Jacques,

I missed this thread for some reason (was collapsed in TB) and only saw it now.

I read the thread.
Glad to see progress on fixing the SVN issue.


I think it's eventually done, with maybe some syntax improvements




Also inline:

La 24.12.2023 13:05, Jacques Le Roux a scris:

Hi Eugen,

I tend to agree with your vision that sounds quite promising. I'm sorry I got 
no time to review your PR yet. I hope to do so during next year...


It's good that it gets some attention.
Even if the PR does not get merged as is but is used as example for the idea 
the PR is meant for.

Of course, this architecture will need to be discussed more and especially will not be part of the next release branch (24.01 ? 18.12 becoming 
really old).


That is ok with me since I plan to use trunk anyway.
So I guess the sooner we have OFBiz 24.01 the better :D .
Are there otehr blockers for 24.01 besides the SVN issue?


There is OFBIZ-12726  that I set as a blocker. I think we could continue with the 
workaround for now, the community to decide... 24.01 or such is now pressing...







This said I was reading 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
and stumbled upon 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md

Obviously some parts are obsolete since we rely now on Docker for demos. Could 
you please review and possibly amend?


Is this for me or for Daniel?
I assume it's for Daniel (as I read in your next emails).

Last but not least, I guess we will need very soon to change something in Docker config for demos ; since pullAllPluginsSource relies on soon not 
usable SvnCheckout plugin?


Yes indeed I confused, I finally handled Docker with the task 
https://issues.apache.org/jira/browse/OFBIZ-12876
For the READMEs it's more on my side than Daniel's. I'll clean the whole thing 
with https://issues.apache.org/jira/browse/OFBIZ-12863
For demos, we have now 
https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker

Jacques




TIA

Jacques

Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :

Hi Jacques,

Regarding the plugin workflow, the PR that I posted can offer alternative ways 
to develop and consume plugins / components.
This would make plugin development by pulling sources in ofbiz optional / 
obsolete even (a choice).

If we move to have libraries that are published as jar files, then it would be 
possible to develop plugins by depending on the specific OFBiz bits.
It would also be possible to publish plugins / components as regular java jars 
and consume them the same way.
So, in the future a custom OFBiz build could look something like this:

build.gradle

dependencies {
  implementation 'org.apache.ofbiz:entity-engine:24.0'
  implementation 'org.apache.ofbiz:service:24.0'
  implementation 'org.apache.ofbiz:accounting:24.0'
  implementation 'com.example:my-plugin:1.2.3'
}




On 23.12.2023 17:06, Jacques Le Roux  wrote:

It's ready for review before pushing and testing with GH and BB

TIA

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
> Hi,
>
> I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for > 
that... WIP...
>
> HTH
>
> Jacques
>
> Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
>> Hi,
>>
>> As you may have noticed*, the SvnCheckout Gradle plugin will not be >> 
usable after January 8, 2024.
>>
>> So we need a replacement and it's clearly suggested by GitHub in the >> link 
below
>>
>> Jacques
>>
>> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Daniel,

Reviews are always appreciated :)

Inline...

Le 04/01/2024 à 09:23, Daniel Watford a écrit :

Hi Jacques,

Sorry for not reviewing earlier, but for the pullAllPluginsSource.sh you might 
consider simplifying a little with:

# Whatever, create anew if [ -d"plugins" ]
 then rm -rf plugins
fi # Get the branch used by the framework branch=$(git branch --show-current) 
git clone --depth1 --branch$branch https://github.com/apache/ofbiz-plugins.git  
plugins

# remove .git, in this case it's big useless information rm -rf plugins/.git

The above avoids creating the temp.txt file to detect the current branch, and 
avoids changing directories.


I'll commit that after your answer below about  depth=1




FYI, pushd and popd are useful alternatives to cd in scripts - 
https://en.wikipedia.org/wiki/Pushd_and_popd


Thanks for the info, did not know it existed in cmd.exe.




The git clone command has been altered to select the branch to clone, and the depth=1 command line argument reduces the size of the clone to the 
minimum needed for that single branch.


I'm not sure it's useful because anyway I remove .git, don't you think so?

TIA

Jacques



Dan.

On Wed, 3 Jan 2024 at 18:11, Eugen Stan  wrote:

Hi Jacques,

I missed this thread for some reason (was collapsed in TB) and only saw
it now.

I read the thread.
Glad to see progress on fixing the SVN issue.

Also inline:

La 24.12.2023 13:05, Jacques Le Roux a scris:
> Hi Eugen,
>
> I tend to agree with your vision that sounds quite promising. I'm sorry
> I got no time to review your PR yet. I hope to do so during next year...

It's good that it gets some attention.
Even if the PR does not get merged as is but is used as example for the
idea the PR is meant for.

> Of course, this architecture will need to be discussed more and
> especially will not be part of the next release branch (24.01 ? 18.12
> becoming really old).

That is ok with me since I plan to use trunk anyway.
So I guess the sooner we have OFBiz 24.01 the better :D .
Are there otehr blockers for 24.01 besides the SVN issue?

>
> This said I was reading
> 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
> and stumbled upon
> https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md
>
> Obviously some parts are obsolete since we rely now on Docker for demos.
> Could you please review and possibly amend?

Is this for me or for Daniel?
I assume it's for Daniel (as I read in your next emails).

> Last but not least, I guess we will need very soon to change something
> in Docker config for demos ; since pullAllPluginsSource relies on soon
> not usable SvnCheckout plugin?
>
> TIA
>
> Jacques
>
> Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :
>> Hi Jacques,
>>
>> Regarding the plugin workflow, the PR that I posted can offer
>> alternative ways to develop and consume plugins / components.
>> This would make plugin development by pulling sources in ofbiz
>> optional / obsolete even (a choice).
>>
>> If we move to have libraries that are published as jar files, then it
>> would be possible to develop plugins by depending on the specific
>> OFBiz bits.
>> It would also be possible to publish plugins / components as regular
>> java jars and consume them the same way.
>> So, in the future a custom OFBiz build could look something like this:
>>
>> build.gradle
>>
>> dependencies {
>>   implementation 'org.apache.ofbiz:entity-engine:24.0'
>>   implementation 'org.apache.ofbiz:service:24.0'
>>   implementation 'org.apache.ofbiz:accounting:24.0'
>>   implementation 'com.example:my-plugin:1.2.3'
>> }
>>
>>
>>
>>
>> On 23.12.2023 17:06, Jacques Le Roux 
>> wrote:
>>> It's ready for review before pushing and testing with GH and BB
>>>
>>> TIA
>>>
>>> Jacques
>>>
>>> Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
>>> > Hi,
>>> >
>>> > I have created https://issues.apache.org/jira/browse/OFBIZ-12868
>>> for > that... WIP...
>>> >
>>> > HTH
>>> >
>>> > Jacques
>>> >
>>> > Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
>>> >> Hi,
>>> >>
>>> >> As you may have noticed*, the SvnCheckout Gradle plugin will not
>>> be >> usable after January 8, 2024.
>>> >>
>>> >> So we need a replacement and it's clearly suggested by GitHub in
>>> the >> link below
>>> >>
>>> >> Jacques
>>> >>
>>> >> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz
>>>
>>

-- 
Eugen Stan


+40770 941 271  / https://www.netdava.com



--
Daniel Watford

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Daniel Watford]

Hi Jacques,

Sorry for not reviewing earlier, but for the pullAllPluginsSource.sh you
might consider simplifying a little with:

# Whatever, create anew
if [ -d "plugins" ]
then
rm -rf plugins
fi

# Get the branch used by the framework
branch=$(git branch --show-current)
git clone --depth 1 --branch $branch
https://github.com/apache/ofbiz-plugins.git plugins

# remove .git, in this case it's big useless information
rm -rf plugins/.git


The above avoids creating the temp.txt file to detect the current branch,
and avoids changing directories.

FYI, pushd and popd are useful alternatives to cd in scripts -
https://en.wikipedia.org/wiki/Pushd_and_popd

The git clone command has been altered to select the branch to clone, and
the depth=1 command line argument reduces the size of the clone to the
minimum needed for that single branch.

Dan.

On Wed, 3 Jan 2024 at 18:11, Eugen Stan  wrote:

> Hi Jacques,
>
> I missed this thread for some reason (was collapsed in TB) and only saw
> it now.
>
> I read the thread.
> Glad to see progress on fixing the SVN issue.
>
> Also inline:
>
> La 24.12.2023 13:05, Jacques Le Roux a scris:
> > Hi Eugen,
> >
> > I tend to agree with your vision that sounds quite promising. I'm sorry
> > I got no time to review your PR yet. I hope to do so during next year...
>
> It's good that it gets some attention.
> Even if the PR does not get merged as is but is used as example for the
> idea the PR is meant for.
>
> > Of course, this architecture will need to be discussed more and
> > especially will not be part of the next release branch (24.01 ? 18.12
> > becoming really old).
>
> That is ok with me since I plan to use trunk anyway.
> So I guess the sooner we have OFBiz 24.01 the better :D .
> Are there otehr blockers for 24.01 besides the SVN issue?
>
> >
> > This said I was reading
> >
> https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
> > and stumbled upon
> > https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md
> >
> > Obviously some parts are obsolete since we rely now on Docker for demos.
> > Could you please review and possibly amend?
>
> Is this for me or for Daniel?
> I assume it's for Daniel (as I read in your next emails).
>
> > Last but not least, I guess we will need very soon to change something
> > in Docker config for demos ; since pullAllPluginsSource relies on soon
> > not usable SvnCheckout plugin?
> >
> > TIA
> >
> > Jacques
> >
> > Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :
> >> Hi Jacques,
> >>
> >> Regarding the plugin workflow, the PR that I posted can offer
> >> alternative ways to develop and consume plugins / components.
> >> This would make plugin development by pulling sources in ofbiz
> >> optional / obsolete even (a choice).
> >>
> >> If we move to have libraries that are published as jar files, then it
> >> would be possible to develop plugins by depending on the specific
> >> OFBiz bits.
> >> It would also be possible to publish plugins / components as regular
> >> java jars and consume them the same way.
> >> So, in the future a custom OFBiz build could look something like this:
> >>
> >> build.gradle
> >>
> >> dependencies {
> >>   implementation 'org.apache.ofbiz:entity-engine:24.0'
> >>   implementation 'org.apache.ofbiz:service:24.0'
> >>   implementation 'org.apache.ofbiz:accounting:24.0'
> >>   implementation 'com.example:my-plugin:1.2.3'
> >> }
> >>
> >>
> >>
> >>
> >> On 23.12.2023 17:06, Jacques Le Roux 
> >> wrote:
> >>> It's ready for review before pushing and testing with GH and BB
> >>>
> >>> TIA
> >>>
> >>> Jacques
> >>>
> >>> Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
> >>> > Hi,
> >>> >
> >>> > I have created https://issues.apache.org/jira/browse/OFBIZ-12868
> >>> for > that... WIP...
> >>> >
> >>> > HTH
> >>> >
> >>> > Jacques
> >>> >
> >>> > Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
> >>> >> Hi,
> >>> >>
> >>> >> As you may have noticed*, the SvnCheckout Gradle plugin will not
> >>> be >> usable after January 8, 2024.
> >>> >>
> >>> >> So we need a replacement and it's clearly suggested by GitHub in
> >>> the >> link below
> >>> >>
> >>> >> Jacques
> >>> >>
> >>> >> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz
> >>>
> >>
>
> --
> Eugen Stan
>
> +40770 941 271  / https://www.netdava.com
>
>

-- 
Daniel Watford

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Eugen Stan]

Hi Jacques,

I missed this thread for some reason (was collapsed in TB) and only saw 
it now.


I read the thread.
Glad to see progress on fixing the SVN issue.

Also inline:

La 24.12.2023 13:05, Jacques Le Roux a scris:

Hi Eugen,

I tend to agree with your vision that sounds quite promising. I'm sorry 
I got no time to review your PR yet. I hope to do so during next year...


It's good that it gets some attention.
Even if the PR does not get merged as is but is used as example for the 
idea the PR is meant for.


Of course, this architecture will need to be discussed more and 
especially will not be part of the next release branch (24.01 ? 18.12 
becoming really old).


That is ok with me since I plan to use trunk anyway.
So I guess the sooner we have OFBiz 24.01 the better :D .
Are there otehr blockers for 24.01 besides the SVN issue?



This said I was reading 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
and stumbled upon 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md


Obviously some parts are obsolete since we rely now on Docker for demos. 
Could you please review and possibly amend?


Is this for me or for Daniel?
I assume it's for Daniel (as I read in your next emails).

Last but not least, I guess we will need very soon to change something 
in Docker config for demos ; since pullAllPluginsSource relies on soon 
not usable SvnCheckout plugin?


TIA

Jacques

Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :

Hi Jacques,

Regarding the plugin workflow, the PR that I posted can offer 
alternative ways to develop and consume plugins / components.
This would make plugin development by pulling sources in ofbiz 
optional / obsolete even (a choice).


If we move to have libraries that are published as jar files, then it 
would be possible to develop plugins by depending on the specific 
OFBiz bits.
It would also be possible to publish plugins / components as regular 
java jars and consume them the same way.

So, in the future a custom OFBiz build could look something like this:

build.gradle

dependencies {
  implementation 'org.apache.ofbiz:entity-engine:24.0'
  implementation 'org.apache.ofbiz:service:24.0'
  implementation 'org.apache.ofbiz:accounting:24.0'
  implementation 'com.example:my-plugin:1.2.3'
}




On 23.12.2023 17:06, Jacques Le Roux  
wrote:

It's ready for review before pushing and testing with GH and BB

TIA

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
> Hi,
>
> I have created https://issues.apache.org/jira/browse/OFBIZ-12868 
for > that... WIP...

>
> HTH
>
> Jacques
>
> Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
>> Hi,
>>
>> As you may have noticed*, the SvnCheckout Gradle plugin will not 
be >> usable after January 8, 2024.

>>
>> So we need a replacement and it's clearly suggested by GitHub in 
the >> link below

>>
>> Jacques
>>
>> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz





--
Eugen Stan

+40770 941 271  / https://www.netdava.com

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Daniel, All,

It's now used in necessary places: GH actions (Build, Docker and so Demos) and BB. So far all works as expected for all branches (18.12 being really a 
weight)


Note: with
https://github.com/apache/ofbiz-framework/commit/c7f606fe98621b8233d70e1c1f9793c525117c4c
I have updated AccountingDemoData.xml. Last time, in 2013, I put 10 years ahead.
This time, lazy, I put only 1 year, so it will need to be updated each new year 
(not needed in R18)...

There is still a minor issue with pullAllPluginsSource.sh when the releases 
branches don't exist. I'll fix it soon...

Jacques

Le 31/12/2023 à 11:41, Jacques Le Roux a écrit :

Hi Daniel,

There is a huge performance difference in favour of scripts and I found 
difficult to use the scripts from Gradle.
As you may have seen, I already crossed an issue (access denied) with BB I 
reported to Infra with https://issues.apache.org/jira/browse/INFRA-25327

This said it may certainly be possible to call the scripts from Gradle. I have 
tried that w/o success so far:

--

task pullPluginSource(group: ofbizPlugin, description: 'Download and install a 
plugin from source control') {

task pullPluginFromGit() {

if (project.hasProperty('pluginId')) {

if (os.contains('windows')) {

exec { commandLine 'cmd', '/c', 'pullPluginSource.bat', "${pluginId}" }

} else {

exec { commandLine './pullPluginSource.sh', "${pluginId}" }

}

}

}

dependsOn pullPluginFromGit

doLast {

gradlewSubprocess(['installPlugin', "-PpluginId=${pluginId}"])

}

}

task pullAllPluginsSource(group: ofbizPlugin,

description: 'Download and install all plugins from source control. Warning! 
deletes existing plugins') {

task pullAllPluginsFromGit() {

if (os.contains('windows')) {

exec { commandLine 'cmd', '/c', 'pullAllPluginsSource.bat' }

} else {

exec { commandLine './pullAllPluginsSource.sh' }

}

}

dependsOn pullAllPluginsFromGit

task installAllPlugins {

subdirs(file("${pluginsDir}"))

.filter(this.isComponentEnabled)

.filter { taskExistsInproject(":plugins:${it.name}", 'install') }

.forEach({ plugin ->

dependsOn ":plugins:${plugin.name}:install"

doLast { println "installed plugin ${plugin.name}" }

})

}

doLast {

gradlewSubprocess(['installAllPlugins'])

}

}

--

The scripts are at https://issues.apache.org/jira/browse/OFBIZ-12868

I know that "dependsOn" is no longer recommended with recent versions of 
Gradle, maybe the reason.

We have still a week before it will be a real blocker.

Jacques

Le 31/12/2023 à 11:13, Daniel Watford a écrit :

Hi Jacques,

Please could you confirm that the project's intention is to remove
the pullAllPluginsSource gradle task, rather than replace the components of
that task that fetch the source via SVN with something similar that fetches
via Git?

The reason for asking is that you mentioned in a comment on
https://issues.apache.org/jira/browse/OFBIZ-12868  that we might still use
the gradle tasks:


"To minimise the change, we could decide to still use the scripts but
called from Gradle... I have not yes tested the performance differences..."


If the intention is to keep the gradle tasks related to retrieving plugin
sources, but have those tasks call external scripts, then we should close
https://issues.apache.org/jira/browse/OFBIZ-12876  and have the docker image
builds continue to leverage gradle.

Thanks,

Dan.

On Tue, 26 Dec 2023 at 09:49, Jacques Le Roux
wrote:


Hi,

Though I believe we should get rid of the Gradle pullPluginSource and
pullAllPluginsSource tasks, this morning I tried to implement them using
the OS
scripts for pullPluginSource and pullAllPluginsSource w/o success.

If someone is interested I can put the diff at OFBIZ-12868

Juste let me know...

Jacques

Le 23/12/2023 à 12:13, Jacques Le Roux a écrit :

Hi,

OK, we need more effort here because GH and BB will break at January 8,

2024 and we need to test the changes before... In other words we have at

most 2 weeks available...

I have one question. It seems to me that the Gradle "installPlugin"

task, called by the pullPluginSource and pullAllPluginsSource tasks, is not

implement in any OOTB plugin.

I ask this question because, if it eventually unused, it's quite easier

and especially efficient/faster to use simple OS scripts than Gradle tasks

for pullPluginSource and pullAllPluginsSource

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :

Hi,

I have createdhttps://issues.apache.org/jira/browse/OFBIZ-12868 for

that... WIP...

HTH

Jacques

Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :

Hi,

As you may have noticed*, the SvnCheckout Gradle plugin will not be

usable after January 8, 2024.

So we need a replacement and it's clearly suggested by GitHub in 

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Daniel,

There is a huge performance difference in favour of scripts and I found 
difficult to use the scripts from Gradle.
As you may have seen, I already crossed an issue (access denied) with BB I 
reported to Infra with https://issues.apache.org/jira/browse/INFRA-25327

This said it may certainly be possible to call the scripts from Gradle. I have 
tried that w/o success so far:

--

task pullPluginSource(group: ofbizPlugin, description: 'Download and install a 
plugin from source control') {

task pullPluginFromGit() {

if (project.hasProperty('pluginId')) {

if (os.contains('windows')) {

exec { commandLine 'cmd', '/c', 'pullPluginSource.bat', "${pluginId}" }

} else {

exec { commandLine './pullPluginSource.sh', "${pluginId}" }

}

}

}

dependsOn pullPluginFromGit

doLast {

gradlewSubprocess(['installPlugin', "-PpluginId=${pluginId}"])

}

}

task pullAllPluginsSource(group: ofbizPlugin,

description: 'Download and install all plugins from source control. Warning! 
deletes existing plugins') {

task pullAllPluginsFromGit() {

if (os.contains('windows')) {

exec { commandLine 'cmd', '/c', 'pullAllPluginsSource.bat' }

} else {

exec { commandLine './pullAllPluginsSource.sh' }

}

}

dependsOn pullAllPluginsFromGit

task installAllPlugins {

subdirs(file("${pluginsDir}"))

.filter(this.isComponentEnabled)

.filter { taskExistsInproject(":plugins:${it.name}", 'install') }

.forEach({ plugin ->

dependsOn ":plugins:${plugin.name}:install"

doLast { println "installed plugin ${plugin.name}" }

})

}

doLast {

gradlewSubprocess(['installAllPlugins'])

}

}

--

The scripts are at https://issues.apache.org/jira/browse/OFBIZ-12868

I know that "dependsOn" is no longer recommended with recent versions of 
Gradle, maybe the reason.

We have still a week before it will be a real blocker.

Jacques

Le 31/12/2023 à 11:13, Daniel Watford a écrit :

Hi Jacques,

Please could you confirm that the project's intention is to remove
the pullAllPluginsSource gradle task, rather than replace the components of
that task that fetch the source via SVN with something similar that fetches
via Git?

The reason for asking is that you mentioned in a comment on
https://issues.apache.org/jira/browse/OFBIZ-12868  that we might still use
the gradle tasks:


"To minimise the change, we could decide to still use the scripts but
called from Gradle... I have not yes tested the performance differences..."


If the intention is to keep the gradle tasks related to retrieving plugin
sources, but have those tasks call external scripts, then we should close
https://issues.apache.org/jira/browse/OFBIZ-12876  and have the docker image
builds continue to leverage gradle.

Thanks,

Dan.

On Tue, 26 Dec 2023 at 09:49, Jacques Le Roux
wrote:


Hi,

Though I believe we should get rid of the Gradle pullPluginSource and
pullAllPluginsSource tasks, this morning I tried to implement them using
the OS
scripts for pullPluginSource and pullAllPluginsSource w/o success.

If someone is interested I can put the diff at OFBIZ-12868

Juste let me know...

Jacques

Le 23/12/2023 à 12:13, Jacques Le Roux a écrit :

Hi,

OK, we need more effort here because GH and BB will break at January 8,

2024 and we need to test the changes before... In other words we have at

most 2 weeks available...

I have one question. It seems to me that the Gradle "installPlugin"

task, called by the pullPluginSource and pullAllPluginsSource tasks, is not

implement in any OOTB plugin.

I ask this question because, if it eventually unused, it's quite easier

and especially efficient/faster to use simple OS scripts than Gradle tasks

for pullPluginSource and pullAllPluginsSource

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :

Hi,

I have createdhttps://issues.apache.org/jira/browse/OFBIZ-12868  for

that... WIP...

HTH

Jacques

Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :

Hi,

As you may have noticed*, the SvnCheckout Gradle plugin will not be

usable after January 8, 2024.

So we need a replacement and it's clearly suggested by GitHub in the

link below

Jacques

*https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Daniel Watford]

Hi Jacques,

Please could you confirm that the project's intention is to remove
the pullAllPluginsSource gradle task, rather than replace the components of
that task that fetch the source via SVN with something similar that fetches
via Git?

The reason for asking is that you mentioned in a comment on
https://issues.apache.org/jira/browse/OFBIZ-12868 that we might still use
the gradle tasks:

> "To minimise the change, we could decide to still use the scripts but
> called from Gradle... I have not yes tested the performance differences..."


If the intention is to keep the gradle tasks related to retrieving plugin
sources, but have those tasks call external scripts, then we should close
https://issues.apache.org/jira/browse/OFBIZ-12876 and have the docker image
builds continue to leverage gradle.

Thanks,

Dan.

On Tue, 26 Dec 2023 at 09:49, Jacques Le Roux 
wrote:

> Hi,
>
> Though I believe we should get rid of the Gradle pullPluginSource and
> pullAllPluginsSource tasks, this morning I tried to implement them using
> the OS
> scripts for pullPluginSource and pullAllPluginsSource w/o success.
>
> If someone is interested I can put the diff at OFBIZ-12868
>
> Juste let me know...
>
> Jacques
>
> Le 23/12/2023 à 12:13, Jacques Le Roux a écrit :
> > Hi,
> >
> > OK, we need more effort here because GH and BB will break at January 8,
> 2024 and we need to test the changes before... In other words we have at
> > most 2 weeks available...
> >
> > I have one question. It seems to me that the Gradle "installPlugin"
> task, called by the pullPluginSource and pullAllPluginsSource tasks, is not
> > implement in any OOTB plugin.
> >
> > I ask this question because, if it eventually unused, it's quite easier
> and especially efficient/faster to use simple OS scripts than Gradle tasks
> > for pullPluginSource and pullAllPluginsSource
> >
> > Jacques
> >
> > Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
> >> Hi,
> >>
> >> I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for
> that... WIP...
> >>
> >> HTH
> >>
> >> Jacques
> >>
> >> Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
> >>> Hi,
> >>>
> >>> As you may have noticed*, the SvnCheckout Gradle plugin will not be
> usable after January 8, 2024.
> >>>
> >>> So we need a replacement and it's clearly suggested by GitHub in the
> link below
> >>>
> >>> Jacques
> >>>
> >>> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz
>


-- 
Daniel Watford

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi,

Though I believe we should get rid of the Gradle pullPluginSource and pullAllPluginsSource tasks, this morning I tried to implement them using the OS 
scripts for pullPluginSource and pullAllPluginsSource w/o success.


If someone is interested I can put the diff at OFBIZ-12868

Juste let me know...

Jacques

Le 23/12/2023 à 12:13, Jacques Le Roux a écrit :

Hi,

OK, we need more effort here because GH and BB will break at January 8, 2024 and we need to test the changes before... In other words we have at 
most 2 weeks available...


I have one question. It seems to me that the Gradle "installPlugin" task, called by the pullPluginSource and pullAllPluginsSource tasks, is not 
implement in any OOTB plugin.


I ask this question because, if it eventually unused, it's quite easier and especially efficient/faster to use simple OS scripts than Gradle tasks 
for pullPluginSource and pullAllPluginsSource


Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :

Hi,

I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for that... 
WIP...

HTH

Jacques

Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :

Hi,

As you may have noticed*, the SvnCheckout Gradle plugin will not be usable 
after January 8, 2024.

So we need a replacement and it's clearly suggested by GitHub in the link below

Jacques

* https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Eugen,

Inline...

Le 24/12/2023 à 12:05, Jacques Le Roux a écrit :

Hi Eugen,

This said I was reading 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
and stumbled upon 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md

Obviously some parts are obsolete since we rely now on Docker for demos. Could 
you please review and possibly amend?


Please forgot that, I'll handle it.

Jacques

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Thanks Daniel!

Jacques

Le 26/12/2023 à 08:17, Daniel Watford a écrit :

Hi Jacques,

Dropping the pullAllPluginsSource gradle task will have the benefit of
simplifying the building of docker images. Please see the comment on the
topic here:
https://github.com/apache/ofbiz-framework/blob/0530a58d3a912520b7f9e46c5ccde98fd3737bf5/.github/workflows/docker-image.yaml#L126

I'll create and work a ticket over the next few days to amend the docker
image build process to use a git clone/checkout of the ofbiz-plugins
repository rather than use the pullAllPluginsSoruce gradle task. The ticket
will apply to the trunk, release18.12 and release22.01 branches.

Thanks,

Dan.


On Mon, 25 Dec 2023 at 08:34, Jacques Le Roux 
wrote:


Hi Eugen, Daniel,

Le 24/12/2023 à 12:05, Jacques Le Roux a écrit :

Last but not least, I guess we will need very soon to change something

in Docker config for demos ; since pullAllPluginsSource relies on soon not

usable SvnCheckout plugin?

Actually this last sentence was more directed to Daniel

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Daniel Watford]

Hi Jacques,

Dropping the pullAllPluginsSource gradle task will have the benefit of
simplifying the building of docker images. Please see the comment on the
topic here:
https://github.com/apache/ofbiz-framework/blob/0530a58d3a912520b7f9e46c5ccde98fd3737bf5/.github/workflows/docker-image.yaml#L126

I'll create and work a ticket over the next few days to amend the docker
image build process to use a git clone/checkout of the ofbiz-plugins
repository rather than use the pullAllPluginsSoruce gradle task. The ticket
will apply to the trunk, release18.12 and release22.01 branches.

Thanks,

Dan.


On Mon, 25 Dec 2023 at 08:34, Jacques Le Roux 
wrote:

> Hi Eugen, Daniel,
>
> Le 24/12/2023 à 12:05, Jacques Le Roux a écrit :
> > Last but not least, I guess we will need very soon to change something
> in Docker config for demos ; since pullAllPluginsSource relies on soon not
> > usable SvnCheckout plugin?
> Actually this last sentence was more directed to Daniel
>


-- 
Daniel Watford

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Eugen, Daniel,

Le 24/12/2023 à 12:05, Jacques Le Roux a écrit :
Last but not least, I guess we will need very soon to change something in Docker config for demos ; since pullAllPluginsSource relies on soon not 
usable SvnCheckout plugin?

Actually this last sentence was more directed to Daniel

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Eugen,

I tend to agree with your vision that sounds quite promising. I'm sorry I got 
no time to review your PR yet. I hope to do so during next year...

Of course, this architecture will need to be discussed more and especially will not be part of the next release branch (24.01 ? 18.12 becoming really 
old).


This said I was reading 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
and stumbled upon 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md

Obviously some parts are obsolete since we rely now on Docker for demos. Could 
you please review and possibly amend?

Last but not least, I guess we will need very soon to change something in Docker config for demos ; since pullAllPluginsSource relies on soon not 
usable SvnCheckout plugin?


TIA

Jacques

Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :

Hi Jacques,

Regarding the plugin workflow, the PR that I posted can offer alternative ways 
to develop and consume plugins / components.
This would make plugin development by pulling sources in ofbiz optional / 
obsolete even (a choice).

If we move to have libraries that are published as jar files, then it would be 
possible to develop plugins by depending on the specific OFBiz bits.
It would also be possible to publish plugins / components as regular java jars 
and consume them the same way.
So, in the future a custom OFBiz build could look something like this:

build.gradle

dependencies {
  implementation 'org.apache.ofbiz:entity-engine:24.0'
  implementation 'org.apache.ofbiz:service:24.0'
  implementation 'org.apache.ofbiz:accounting:24.0'
  implementation 'com.example:my-plugin:1.2.3'
}




On 23.12.2023 17:06, Jacques Le Roux  wrote:

It's ready for review before pushing and testing with GH and BB

TIA

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
> Hi,
>
> I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for > 
that... WIP...
>
> HTH
>
> Jacques
>
> Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
>> Hi,
>>
>> As you may have noticed*, the SvnCheckout Gradle plugin will not be >> 
usable after January 8, 2024.
>>
>> So we need a replacement and it's clearly suggested by GitHub in the >> link 
below
>>
>> Jacques
>>
>> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[eugen . stan]

Hi Jacques,

Regarding the plugin workflow, the PR that I posted can offer alternative ways 
to develop and consume plugins / components.
This would make plugin development by pulling sources in ofbiz optional / 
obsolete even (a choice).

If we move to have libraries that are published as jar files, then it would be 
possible to develop plugins by depending on the specific OFBiz bits.
It would also be possible to publish plugins / components as regular java jars and consume them the same way. 


So, in the future a custom OFBiz build could look something like this:

build.gradle

dependencies {
  implementation 'org.apache.ofbiz:entity-engine:24.0'
  implementation 'org.apache.ofbiz:service:24.0'
  implementation 'org.apache.ofbiz:accounting:24.0'
  implementation 'com.example:my-plugin:1.2.3'
}




On 23.12.2023 17:06, Jacques Le Roux  wrote:

It's ready for review before pushing and testing with GH and BB

TIA

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
> Hi,
>
> I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for 
> that... WIP...

>
> HTH
>
> Jacques
>
> Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
>> Hi,
>>
>> As you may have noticed*, the SvnCheckout Gradle plugin will not be 
>> usable after January 8, 2024.

>>
>> So we need a replacement and it's clearly suggested by GitHub in the 
>> link below

>>
>> Jacques
>>
>> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

It's ready for review before pushing and testing with GH and BB

TIA

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :

Hi,

I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for that... 
WIP...

HTH

Jacques

Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :

Hi,

As you may have noticed*, the SvnCheckout Gradle plugin will not be usable 
after January 8, 2024.

So we need a replacement and it's clearly suggested by GitHub in the link below

Jacques

* https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi,

OK, we need more effort here because GH and BB will break at January 8, 2024 and we need to test the changes before... In other words we have at most 
2 weeks available...


I have one question. It seems to me that the Gradle "installPlugin" task, called by the pullPluginSource and pullAllPluginsSource tasks, is not 
implement in any OOTB plugin.


I ask this question because, if it eventually unused, it's quite easier and especially efficient/faster to use simple OS scripts than Gradle tasks for 
pullPluginSource and pullAllPluginsSource


Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :

Hi,

I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for that... 
WIP...

HTH

Jacques

Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :

Hi,

As you may have noticed*, the SvnCheckout Gradle plugin will not be usable 
after January 8, 2024.

So we need a replacement and it's clearly suggested by GitHub in the link below

Jacques

* https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi,

I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for that... 
WIP...

HTH

Jacques

Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :

Hi,

As you may have noticed*, the SvnCheckout Gradle plugin will not be usable 
after January 8, 2024.

So we need a replacement and it's clearly suggested by GitHub in the link below

Jacques

* https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi,

As you may have noticed*, the SvnCheckout Gradle plugin will not be usable 
after January 8, 2024.

So we need a replacement and it's clearly suggested by GitHub in the link below

Jacques

* https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz