Page History

...

There are 4 targets, to create/apply/reapply/revert patches for the framework, applications and specialpurpose: they are available in the ant script for auto generated hot-deploy components (see in framework/resources/templates/build.xml)

1. create-ofbiz-patches
2. revert-ofbiz-patches
3. apply-ofbiz-patches
4. reapply-ofbiz-patches

Use "ant -p" in one of your components created with create-component to know more about them...

There are also 4 deployment targets available in the main build.xml.

The reason is to allow to patch different staging areas where URLs and other parameters vary.

1. build-dev
2. build-test
3. build-qa
4. build-production

What they are: the 3 last ones are related with the hot-deploy components patches directories and their sub-directories: test, qa and production. Let me explain quickly how it supposed to work. Suppose you have:

1. A "dev" environment/area (most of the time on developers own machines) where the development is done, maybe using Derby DB for instance. Anyway an area where all production constraints are not yet taken into account.
2. A "test" area, something like the "dev" area but with a different environment (clustered, not the same DB, etc.) something not yet similar to production but near. Because most of the time you don't have yet a production area ready when you begin to test. This area remains in the hand of developpers. Load tests for instance can be done there.
3. A "QA" area, this comes later and is a duplicate of the production area where all tests are finally done. It's in the hand of QA engineers who qualify/guarantee the development to be production ready.
4. A "production" area, this is the latest stage available when the development is production ready (though it might appears before QA sometimes when the shareholders are in a hurry...). It's in the hand of sysops (or devops if you prefer).

The purpose of those targets is to adapt the source to the areas. Only the build-dev target is called by the main build target. The other targets complete the "create|apply|reapply|revert-ofbiz-patches" targets which target only the "dev" area or can be used in an early stage of the development.

How they work: depending on the target area, the build-test|qa|production targets simply scan all patches in all hot-deploy components (for instance in /hot-deploy/component-name/patches/test) and apply them. The "prepare-to-build-qa|production" targets have something specific. When you maintain URLs and misc. parameters variations inside properties files, it's often easier to directly maintain those files and copy them over in those areas than maintaining/updating patches for them which can be a repetitive and tedious task, those targets do it for you.

Now about the 1st build-dev target: sometimes you don't even create any hot-deploy components (eg. some projects might use OFBiz as a web services API with few modifications in OFBiz core), or you need to put patches somewhere before creating a hot-deploy-component, or your patches are common to all deployment areas and it does not make sense to maintain duplicates. Then to keep your OFBiz working copy free from modifications (which could else been put in one of your hot-deploy components patches directory, which is anyway not very logical but pragmatic),  you put your paches in the runtime/patches folder where "core" patches (those which change OFBiz as it's OOTB) are supposed to be. The "build-dev" target, purposely independent of other targets, is called by the main build target, exactly before anything else. The idea for the build-dev target is to keep patches with features separated (ie grouping different files changed for a feature in a patch), but you can, or may have to, do it on a file level, notably when 2 or more features impact the same file...

Then later, if you need to differentiate these files on different areas (URLs, ports in entityengine.xml comes to mind) you can move/duplicate them under the patches/test|qa|production directories of a hot-deploy component of your choice.

And last but not least, if you want to quickly get rid of the changes done using build-dev you can rely on revert-dev.