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.

Here are some conventions, or say patterns, which are common for defining an Entity and its Fields.

• Entity name must be in UpperCamelCase.
• If entity name is abbreviation like Unit Od Measure (UOM) then treat it as one word and name is like Uom.
• The Field name must be in lowerCamelCase and name should be self descriptive enough to show the purpose of the field.
• If relation tag specify the relationship between two entities then the fk-name should contains the words from both entities separated by ("_") underscore.
• If a entity relation with another entity defines more than one time then it should be differentiated by title attribute while defining a relation like "Form" or "To".
• In the same if both fields in the <key-map> tag are same then no need to specify rel-field-name.
• In case of view entities the name will consist of names of all its member entities.
• The <view-link> should be define for proper view in the webtools.