The best approach is to isolate your add-ons into a separate component, which is usually easiest to just drop into (checkout into) the hot-deploy directory.
For applications you want to change the best thing to do is use the various inherit and override facilities in the framework tools. There are some examples of this in the exampleext component, and in the ecomclone webapp. In general, start with getting a good understanding of the OFBiz framework, and then take advantage of all of the tools there that are meant to solve these problems and make it possible to minimize dependencies between your code and OFBiz. Another HUGE HUGE tip for keeping your changes and add-ons clean and efficient is to get involved in contribution to OFBiz. This will make it easy for you to change and add things in OFBiz for anything that is generic in order to make your long term maintenance easier, more pleasant, and way cheaper and more productive. -David Ed Summers wrote:
I'm new to ofbiz and was wondering if I could get some feedback on how folks typically put their code under revision control and then build and deploy their applications. I would like to enable layering in my code with the latest/greatest ofbiz code as it becomes available--instead of putting the whole lot under revision control and having to merge in changes. I'm under the impression that any code or configuration I write should be able to live in /applications? But it also looks like some configuration files outside of /applications might need to be modified as well (framework/component-load.xml, etc). I was thinking a typical build could rely on a ofbiz installation in say /opt/ofbiz and then an ant or maven task could checkout the relevant code into ~/work/my-app, compile, run unittests and then deploy to /opt/ofbiz as appropriate. Any guidance/stories on what works for you, or pointers into the documentation would be appreciated. Sincerely, //Ed
