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 <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
