Thanks Michael,
I remember this discussion. My aim here is to replace the consensual advice we
had with pre Gradle version, still at
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65865831#AddressingCustomRequirementsInOFBiz-PatchManagementUsingAntTargets
I think we can suggest more than one solution and people can then pick the one fitting more for them. Maybe you could begin to add yours in the
current AddressingCustomRequirementsInOFBiz page.
I'll suggest the same for Gil's with OFBIZ-9498.
Hope it clarifies things
Jacques
Le 17/11/2017 à 22:18, Michael Brohl a écrit :
Hi Jacques,
it takes some effort to make an OFBiz standard compatible patch of the mechanism because we have several additions to the configurations. I would
take the effort if the community wants to adapt it but it's too much work for just giving an idea.
I have explained the mechanism in [1]. There it is based on Ant but we already
use it in projects with Gradle.
We were looking for other solutions during the migration to Gradle but haven't found a better approach considering all pros and cons (database
configuration, environment variables etc.). We use it for years on our test- and production environments and it makes the handling of different
system specific configurations very easy.
We are thinking about the introduction of an additional configuration level so that we have the base configuration (containing all properties), a
project configuration level and the system specific configurations. This helps us to additionally maintain projects using different sets of plugins.
I'm happy to explain more if something is unclear.
Regards,
Michael
[1]
https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
Am 03.11.17 um 11:39 schrieb Jacques Le Roux:
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
