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
