I already told to Pierre that I have put in place a such process and it's documented at
https://cwiki.apache.org/confluence/display/OFBIZ/Addressing+Custom+Requirements+In+OFBiz#AddressingCustomRequirementsInOFBiz-Therearealso4deploymenttargetsavailableinthemainbuild.xml.
Unfortunately we have not yet migrated these Ant targets to Gradle tasks, same
for createComponent targets
If it's only changes in one file it's though easy to perform the process by
hand as you explained, Jacopo
Jacques
Le 16/08/2016 à 08:34, Jacopo Cappellato a écrit :
If the time it takes you to resolve the conflicts due to local changes to
your build.gradle file is too much then you could automate your process by
preparing a script to revert your local changes before updating the trunk
and then re-applying them after the update:
1) revert local changes (the script could also create a patch file with
your local modification before reverting them)
2) update the trunk
3) apply your local changes (e.g. by using the patch created in step #1)
This should minimize the occurrences of conflicts, that could still happen
in step #3, and at the same time make it easier to deal with them (in step
#3).
Hope it helps,
Jacopo
On Mon, Aug 15, 2016 at 8:32 PM, Pierre Smits <[email protected]>
wrote:
HI all,
Over the past few weeks I am experiencing conflicts after an svn upgrade
due to commits to build.gradle. These conflicts happen not only in my dev
environment, but also in the various CIs I have testing against trunk. Each
time this happens I lose precious time to fix all this.
Can we collaborate to get something in the code repo so that these
conflicts won't happen again?
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
