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
