Page History

...

1. Do not implement large blocks of artifacts (code, etc) on your own and then contribute them to OFBiz.
2. If you have a large block of code to contribute we can work with you on that, but it requires a different review and legal vetting process than normal contributions, as described on http://incubator.apache.org/ip-clearance/index.html.
3. When a method is deprecated, it should be explained which method should be used, and what has changed.
4. Instead develop and contribute as you go. This means develop as you would normally, but interact with the OFBiz community through mailing lists and contribute patches regularly. # If you are do not have a committer on your team this can slow down development, so do what you can to "sell" one of the committers on your project and get an ally on the committing team to regularly review and commit your patches. Note that if you let us know in advance that you are planning a larger effort of this nature, we can perhaps find a volunteer beforehand to work with you on this.
5. Just please remember that there is no paid staff on OFBiz, all are volunteers. You may see your patch sit in Jira for a long time while committers work on other things. This usually happens because a committer is working on a priority for the project that has been a problem for a while, or on a paid contract in order to survive and to be able to continue helping with OFBiz.
6. It might be tempting to run your effort without getting an OFBiz committer involved, but keep in mind that committers can help you with technical, business, and legal concerns either on their own or through collaboration with others in the project on in the ASF more generally.

...

Then, send in a patch file. This is a file which will describe all the differences between your modified code and the code in the OFBiz Subversion repository. You can create a patch file by using a command like this:

$ svn diff applications/product > product.diff

will give us a patch file for all your changes in the applications/product sub-directory and save it as product.diff.
If you have added new files, then use the "add" command first, then make the diff

$ svn add applications/product/<my-file>

$ svn diff applications/product > product.diff

You can also specify the exact files that you'd wish to include in your patch file, in case there are files that you have modified but do not wish to submit. For example, you can use

$ svn status applications/product

to see which files have been modified (they start with an "M") or added (which start with a "?").

Then do:

$ svn diff applications/product/entity/ applications/product/script/org/ofbiz/shipment/shipment/ShipmentServices.xml > product-shipment.diff

if you only want to make a patch file of the entity/ sub-directory and the ShipmentServices.xml file.

For consistency, please make your patch files from the OFBIZ_HOME directory (usually ofbiz/) and with relative file paths. Your patch file should have file names like:
applications/party/widget/partymgr/PartyScreens.xml
framework/webtools/config/WebtoolsErrorUiLabels.properties
and should not have file names like:
C:\myfiles\ofbiz\applications\party\widget\partymgr\PartyScreens.xml

Make sure that the from/current revision of your local sandbox (checkout) is the current revision, or a very recent one, from the OFBiz SVN repository. The local revision can be checked by doing:

$ svn info

To make sure you have the most recent revision always do an SVN update before doing the patch with svn diff, something like this:

$ svn up

This must always be done before submitting a patch otherwise the patch just won't work. If your local sandbox is checked out from a separate SVN repository following the vendor branch pattern instead of directly from the OFBiz SVN, then you should do a vendor branch update, merge, and then local update in your sandbox before doing the svn diff to create the patch.

Next upload your patch file to your JIRA issue. Please use .patch as extension, some tools use extensions and this facilitates commiters works.
Finally, if there are several patch files already on an issue, please write a comment about which file should be used. A best practice is also to keep the same filename if a patch file is updated. Jira will take care of that and will keep (better for history) but gray deprecated files with the same filename. It's easier for commiter to see at 1st glance which file to use. You can read in 1st comment below what may happen when not using the same filename.

...