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
