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 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 <eugen.s...@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.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 <jacques.le.r...@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
