http://ofbiz.116.s1.nabble.com/OFBIZ-12081-DB-driver-download-and-configuration-based-on-gradle-property-tp4762286p4763788.html
Did we not recently discuss about splitting entityengine.xml and could not get a consensus? (I searched but did not find it)
> 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 <
[hidden email]> 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
>>
>