ofbiz configuration management ideas

[Ed Summers]

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

[David E Jones]

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

[Walter Vaughan]

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.

A few of us ( mostly who are utilizing Opentaps add-ons AFAIK ) are utilizing
"svk". What this does allows us to do is download the daily changes from the
parent project and maintain our local customizations in a more organized fashion.

Leon Torres ([hidden email]) I believe is the expert on it this
topic for opensourcestrategies. I'd expect a few hours of contracted training
with them will have you up, running, and happy.

The *only* problem that drives me slightly crazy is that the svn generated
merges aren't foolproof. It's more like 99 44/100% foolproof. But it typically
takes only a minute or two to figure it out once in a while, or writing your
local customizations so they are more "svn visible" so it's not creating a ton
of extra work.

YMMV

==
Walter

[jonwimp]

Walter,

 > The *only* problem that drives me slightly crazy is that the svn
 > generated merges aren't foolproof. It's more like 99 44/100% foolproof.
 > But it typically takes only a minute or two to figure it out once in a
 > while, or writing your local customizations so they are more "svn
 > visible" so it's not creating a ton of extra work.

A more regular (higher frequency) merge routine will mean less work.

You can also write scripts to flag merge sections that hit sections you last updated, and to
ignore (pass-through) those merge sections that are nowhere close to your active development.

For potential functional conflicts (eg. changing codes in file A will affect file B because B uses
A), you have to rely on regression tests. A good way to do this is to always apply merges into an
"interim" branch, test it over time, debug whatever conflicts there are, and then bring that
"interim" branch back to your main branch. Think of the "interim" branch as a massive set of
changes by an indepent outsourced team (OFBiz community, in this case).

If you're adventurous, you can also try building a functional dependencies map, and use scripts to
flag merge sections that potentially hit sections in your active development, BOTH in terms of
actual physical file conflicts as well as functional conflicts. If you do develop this map, it'll
be a great documentation for OFBiz, by the way. So far, I've only relied on some search routines
to build sub-maps on-demand.

I've never tried SVK before. But looking at its merge functions (star-merge, cherry picking), it
seems very similar to some scripts I've developed. I'll try it soon.

Jonathon

Walter Vaughan wrote:

> 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.
>
> A few of us ( mostly who are utilizing Opentaps add-ons AFAIK ) are
> utilizing "svk". What this does allows us to do is download the daily
> changes from the parent project and maintain our local customizations in
> a more organized fashion.
>
> Leon Torres ([hidden email]) I believe is the expert on
> it this topic for opensourcestrategies. I'd expect a few hours of
> contracted training with them will have you up, running, and happy.
>
> The *only* problem that drives me slightly crazy is that the svn
> generated merges aren't foolproof. It's more like 99 44/100% foolproof.
> But it typically takes only a minute or two to figure it out once in a
> while, or writing your local customizations so they are more "svn
> visible" so it's not creating a ton of extra work.
>
> YMMV
>
> ==
> Walter
>
>

[Ed Summers]

Thanks very much for all the useful replies. For the moment it sounds
like the easiest way to start is to bundle our customizations as
components, and then check out, compile, test, and deploy into the
hot-deploy directory of an ofbiz instance. Many thanks for the
pointers to exampleext and ecomclone for extension examples--and for
encouraging commits back to the mothership :-)

//Ed