That's quite interesting Michael,
Would you share in a Jira? Then we could get to merge all experiences and find
a consensu.
Jacques
Le 03/11/2017 à 10:10, Michael Brohl a écrit :
Just an update triggered by the question from Swapnil [1]: our configuration mechanism mentioned below is now on Gradle so it would be compatible
with 16.11 and later.
Regards,
Michael
[1]
https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b122eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E
Am 05.07.17 um 17:56 schrieb Michael Brohl:
Hi Gil,
we have similar challenges and modified OFBiz to deal with it easily. We offered to contribute this long time ago (2008) but it was decided against
[1]. It was suggested to use patches instead but I think it's too complicated to manage several patch sets for different environments.
We now use a staged configure mechanism which uses a base build file, auto detected machine name and provided parameters to decide which
configurations should be pulled for the environment. It's currently Ant based and therefore does not fit into the current build mechanism (on the
todo list).
I like your approach also and I think it should be evaluated and discussed.
Best regards,
Michael Brohl
ecomify GmbH
www.ecomify.de
[1]
https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
Am 05.07.17 um 17:36 schrieb gil portenseigne:
Hello all,
Working with different hosting companies, we used to have issues when deploying OFBiz concerning technical configuration of the different
environments.
We are writing this mail to get feedback from the community and eventually
propose to improve OFBiz on this matter.
For a customer, we are working with 4 instances of a release 13.07 OFBiz, and are currently using a set of patches (with addonmanager...) to
manage environment specific configurations.
During each production deployment, the hosting company receive from our jenkins a precompiled archive containing OFBiz codebase, and then apply
the set of patches to configure it to the environment needs, recompile and relaunch...
This way of doing can cause issue when patch could not apply, after a codebase
modification (pretty rare but it happens).
We are not satisfied with this way of doing, we are currently thinking about using environment variables to configure technical environment
properties (those are on the hosting company responsibility), and to keep functional specifics into the code base.
If you have some experience or advice in this matter, you are welcome.
For our case, we currently have enhanced OFBiz to be able to get environment variable from the operating system within property file and some
other configuration files (with default value if not set).
Examples :
*In Property file :
password=${env:ONE_CONF:ofbiz} -> environment variable ONE_CONF or ofbiz if
unset
other_config=${env:OTHER_CONF:${partyId}} -> environment variable OTHER_CONF or
${partyId} if unset
*In entityengine.xml :
jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://127.0.0.1/ofbiz?autoReconnect=true}"
jdbc-username="${env:DB_POSTGRES_USER:ofbiz}"
jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/>
That allow us to keep functional parameters stored within git branches. Our jenkins now is able to build our 4 configured and compiled instances
and deliver it to the hosting company, that just have to set/check environment variable (database access, activeMQ, log location, instance id,
etc.) before starting OFBiz app. Now we cannot have configuration failure during deployment.
We will be glad to contribute it, if it's the good way to go !
Best Regards !
Gil Portenseigne
