Hi Jacques,
I don't recall a conversation on the mailing list about breaking up
entityengine.xml, however Eugen did suggest creating some templates in the
context of the PR related to this thread (
https://github.com/apache/ofbiz-framework/pull/246) which I then
implemented for Postgres and Derby (in the PR).
On Thu, 14 Jan 2021 at 15:21, Jacques Le Roux <jacques.le.r...@les7arts.com>
wrote:
> Hi Daniel, James,
>
> Did we not recently discuss about splitting entityengine.xml and could not
> get a consensus? (I searched but did not find it)
>
> Thanks
>
> Jacques
>
> Le 14/01/2021 à 15:21, Daniel Watford a écrit :
> > Hi Eugen,
> >
> > I like the approach of a config directory which can be used to override
> > configuration files already compiled into a distribution
> (distTar/distZip).
> > It's probably worth opening a separate ticket for that since it would be
> > analogous to how the /lib directory is currently used for gradle builds.
> >
> > But my main question was intended to deal with how ofbiz administrators
> > identify and retrieve the database driver libraries for their
> deployments.
> >
> > In your case did you find a list of recommended versions for use with
> Ofbiz
> > or did you have a driver that you often use with your DBMS? Did it take
> > much time to choose the driver?
> >
> > Even if it was easy for you to figure out the driver version, do you
> think
> > other less experienced ofbiz administrators would struggle? Having the
> > ofbiz project declare, in code, what library versions are known to work
> > with various DBMS would reduce the effort required for all
> administrators.
> >
> > I agree that we probably don't want to change the content of
> configurations
> > at build time, but it might be appropriate to break entityengine.xml into
> > smaller DBMS specific files and then only include one of those files in a
> > binary distribution specific to a particular DBMS, hopefully making it a
> > bit easier for ofbiz administrators to get started.
> >
> > My overall aim is to reduce the amount of additional library downloads
> and
> > configuration an ofbiz administrator needs to perform in order to get
> > started. Every step should help get closer to externalising
> configuration,
> > as I believe you are already working towards, which should make deploying
> > and upgrading ofbiz running in containers a bit easier.
> >
> > Thanks,
> >
> > Dan.
> >
> > On Tue, 12 Jan 2021 at 12:21, Eugen Stan <eugen.s...@netdava.com> wrote:
> >
> >> Hello Daniel,
> >>
> >> I'll re-post with updates my github comment here since I imagine not
> >> everyone will read the PR comments.
> >>
> >>
> >> I think trying to meddle with those configs at build time is brittle and
> >> would complicate the build.
> >>
> >> It would help to have the ability to add jars and configuration files to
> >> the classpath - since that is where ofbiz looks for.
> >>
> >> So the idea is to make it easy for people to add things at the BEGINING
> >> of the classpath so they can override ofbiz configurations (and / or
> >> libraries ?!)
> >>
> >> I believe this can achieved for both gradle deploy and binary
> >> (ofbiz.tar) deploy with minimal changes.
> >>
> >> If you could add the code snippet bellow to build.gradle then people can
> >> add files to config/ and lib-extra/ directories and they will be
> >> available for ofbiz when it starts.
> >>
> >> I've tested this and it works for my ofbiz docker build (I'm planning an
> >> article these next 2 days and will share it. Spoiler: it works on ARM -
> >> raspberry pi 4 ;) ).
> >>
> >> I'm also adding the database drivers post build to lib-extra .
> >>
> >> That way I can keep the ofbiz source unchanged and still get what I
> need.
> >>
> >> (I don't have windows to test the classpath ).
> >>
> >> tasks.startScripts {
> >> doLast {
> >> // Alter the start script for Unix systems.
> >> unixScript.text =
> >> unixScript.text.replace('CLASSPATH=$APP_HOME/lib',
> >>
> >> 'CLASSPATH=$APP_HOME/config/:$APP_HOME/lib-extra/*:$APP_HOME/lib')
> >>
> >> // Alter the start script for Windows systems.
> >> // windowsScript.text =
> >> // windowsScript.text.replace('CLASSPATH=$APP_HOME/lib',
> >> //
> >> 'CLASSPATH=$APP_HOME\\conf\\:$APP_HOME/lib-extra/*:$APP_HOME/lib')
> >> }
> >> }
> >>
> >>
> >> For adding things to the classpath when running gradle there is
> >> something in place:
> >>
> >> // Libraries downloaded manually
> >> implementation fileTree(dir: file("${rootDir}/lib"), include:
> >> '**/*.jar')
> >>
> >>
> >>
> >> --
> >> Eugen Stan
> >> +40720 898 747 / netdava.com
> >>
> >
>
--
Daniel Watford
