You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2023/11/27 12:41:16 UTC
SvnCheckout Gradle plugin soon no longer usable with GitHub
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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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<ja...@les7arts.com>
>> 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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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<ja...@les7arts.com>
> 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
Posted by Daniel Watford <da...@foomoo.co.uk>.
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 <ja...@les7arts.com>
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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <ja...@les7arts.com>
> 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
Posted by Daniel Watford <da...@foomoo.co.uk>.
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 <ja...@les7arts.com>
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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Posted by Eugen Stan <eu...@netdava.com>.
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
> <https://issues.apache.org/jira/browse/OFBIZ-12726?src=confmacro> 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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <https://issues.apache.org/jira/browse/OFBIZ-12726?src=confmacro> 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.stan@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 <ja...@les7arts.com> 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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <ja...@les7arts.com>
> 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.roux@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 <eu...@netdava.com>
>> 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.stan@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 <
>> jacques.le.roux@les7arts.com>
>>>>> >> 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
>>>>
>>>>
>>>> --
>>>> Daniel Watford
>
Re: SvnCheckout Gradle plugin soon no longer usable with GitHub
Posted by Daniel Watford <da...@foomoo.co.uk>.
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 <ja...@les7arts.com>
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.roux@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 <eu...@netdava.com>
> 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.stan@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 <
> jacques.le.roux@les7arts.com>
> >>> >> 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
> >>
> >>
> >>
> >> --
> >> Daniel Watford
>
--
Daniel Watford
Re: SvnCheckout Gradle plugin soon no longer usable with GitHub
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <ja...@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 <eu...@netdava.com> 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.stan@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 <ja...@les7arts.com>
>>> >> 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
>>
>>
>>
>> --
>> Daniel Watford
Re: SvnCheckout Gradle plugin soon no longer usable with GitHub
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <ja...@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 <eu...@netdava.com> 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.stan@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 <ja...@les7arts.com>
>> >> 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
>
>
>
> --
> Daniel Watford
Re: SvnCheckout Gradle plugin soon no longer usable with GitHub
Posted by Daniel Watford <da...@foomoo.co.uk>.
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 <ja...@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 anewif [ -d "plugins" ]
> then rm -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 <eu...@netdava.com> 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.stan@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 <ja...@les7arts.com>
>> >> 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
>
>
--
Daniel Watford
Re: SvnCheckout Gradle plugin soon no longer usable with GitHub
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <eu...@netdava.com> 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.stan@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 <ja...@les7arts.com>
> >> 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
Posted by Daniel Watford <da...@foomoo.co.uk>.
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 <eu...@netdava.com> 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.stan@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 <ja...@les7arts.com>
> >> 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
Posted by Eugen Stan <eu...@netdava.com>.
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.stan@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 <ja...@les7arts.com>
>> 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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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.stan@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 <ja...@les7arts.com> 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
Posted by eu...@netdava.com.
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 <ja...@les7arts.com> 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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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