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 <jacques.le.r...@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.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 <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 > -- Daniel Watford
