Table of Contents |
---|
Why You Should Contribute to OFBiz
...
OFBiz is a community-developed open source project. What that means is that we're looking to you, the user, to help make our application better. Anybody can contribute to OFBiz, you do not have to be a committer, on an "approved" list, or be a friend or relative. All contributions are considered based on their merit for the project. You also do not need commit privileges to make a contribution. Just create a patch file and post it on our JIRA issue tracker or/and ask for being a wiki contributor.
...
How to create a Jira issue
...
- Create an account here, if you do not have one
- Login
- Search if an issue for what you are after already exists by using the "Find issues"
- If an issue on the subject already exists you can add a comment on it
- If a issue does not exist, create a new one selecting the "create new issue" command. For details on the issue creation see here
- Select the OFBiz project and the issue type.
- Fill in all fields, give as many detail you think necessary
- Generally it is very important to select in the "Affect version" field the ofbiz version you are running. If you are running the trunk then the SVN revision should also be specifyed in the Environment field
- Use the Environment field to specify at least your operating system and the database ofbiz is using since these information could be very useful to help people to work on the issue
- If you need to attach files such as patches you must do it as a second step after the issue creation. It is also possible to easily attach screenshots to the issue see here
- When attaching files or screenshots you can add a comment where you explain how the attached file is supposed to be used. Please reference the file name in the comment because more files could be attached to the issue at a later time and they will be all listed togheter far from their comments.
- Also please use preferably .patch as extension for patches. If updating an attached file keep the same name : Jira is able to deal with that and will simply gray old files, you don't need to delete them (sometimes its usefull to compare older patches versions)
- Jira offers a voting mechanism that is used to give more relevance to the issues (see here to learn more
...
When to create a Jira issue
...
Anchor | ||||
---|---|---|---|---|
|
Info | ||
---|---|---|
| ||
Bug reports are important and welcome, and people take them seriously even when things aren't clear. Part of the problem is that OFBiz is a big system and without adequate details it's easy to do something completely different than what you did. To help make them clear you might try including the following:
|
There are, at least, two kind of contributors: bug reporters, and plain contributors (the ones who follow these Contributors Best Practices). If you don't have enough time or competence to solve a bug by yourself, you may simply report it on the user mailing list. But then please respect the conventions above.
Note | ||
---|---|---|
| ||
|
...
|
...
|
How to create a Jira issue
Tip | ||
---|---|---|
| ||
|
Info | ||
---|---|---|
| ||
|
Following changes
Please read this section in OFBiz Committers Roles and Responsibilities page
Info | ||
---|---|---|
| ||
This feature should be used very parsimoniously because it's not easy to read edited comments from a mailing list and most people read comments from the dev ML (Jira issues are redirected to dev ML). |
If you become a frequent contributor and are willing to help with the long term development of the project, you could become a project committer.
The following guidelines are meant to help contributors work with the committers and the community as a whole:
Tip | ||
---|---|---|
| ||
|
If you are planning a larger contribution, please follow the following tips to facilitate both licensing and collaboration. These tips will make it easier for committers to review and incorporate your work, and will overall speed up your development process as you'll be asking the OFBiz team to do a number of small, simple tasks rather than a couple of large tasks that a committer will have to find significant time to review and commit.
Note | ||
---|---|---|
| ||
|
Anchor | ||||
---|---|---|---|---|
|
Note | ||
---|---|---|
| ||
Here are some conventions, or say patterns, which are common for defining an Entity and its Fields.
|
Apart from the above you can also refer to entitymodel.xsd for understanding the tags.
Anchor | ||||
---|---|---|---|---|
|
Warning | ||
---|---|---|
| ||
Whenever we deprecate an entity in OFBiz there are certain things that MUST be done or all committers should reject the patch:
|
You'll see this pattern used in a few places. This is kind of the way that users in general have some sort of hope of being able to update from one revision of OFBiz to another.
Center |
---|
Deprecating entities : more information here |
How to send in your contributions (or how to create patches, even with Git)
The first step is to create an account for yourself on the JIRA issue tracker and then create a new issue. Describe the contribution that you are making: are you fixing a bug, improving an existing feature, or creating a new feature? Please write as detailed a description as you can and attach screenshots if possible of what you've done. OFBIZ is a huge project, and what may be obvious to you might not be to someone else, even a committer who is familiar with the project.
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. Please use the following conventions to name your patch.
The patch file name should be OFBIZ-number_featureDescription.patch where OFBIZ-number is the name of the Jira issue and featureDescription is full Jira issue title if it's small, or part of title if it's big.
You can create a patch file by using
- Command line (see the howto below)
- Eclipse internal command (don't use finish but rather select project to avoid the 2 1st lines in the patch)
- A Git-UI client, like SourceTree, Tortoise, etc.
- If you use Git to create you patch please use "git diff --no-prefix" option to create it.
Warning | ||
---|---|---|
| ||
Patches must never be used to move files. Else if applied we not only lose history when doing so, but also annotations. So if you are moving files, simply create patches if some files refer to the paths of the relocated files (and hence need to be changed) and tell the committers which files should be moved (from -> to) |
Warning | ||
---|---|---|
| ||
Please adjust your IDE or similar to not remove trailing white spaces when you create a patch, especially a big one, you may do that temporarily. Consider that else reviewers have to be confronted with a lot of false changes, thanks! |
We prefer that you build your patch from the root as it's easier for committers to merge your change. So please make your patch files from the OFBIZ_HOME directory (usually ofbiz/) and with relative file paths.
"Relative file paths" means the in your patch file names should look like these :
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
Examples using command line:
Code Block |
---|
svn di applications/product > OFBIZ-number_featureDescription.patch
|
If you have added new files, then use the "add" command first, then make the diff
Code Block |
---|
svn add applications/product/<my-file>
svn di applications/product > OFBIZ-number_featureDescription.patch
|
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
Code Block |
---|
svn status applications/product
|
to see which files have been modified (they start with an "M") or added (which start with a "?").
Then do:
Code Block |
---|
svn di applications/product/entity/ applications/product/script/org/ofbiz/shipment/shipment/ShipmentServices.xml > OFBIZ-number_featureDescription.patch
|
if you only want to make a patch file of the entity/ sub-directory and the ShipmentServices.xml file.
If you become a frequent contributor and are willing to help with the long term development of the project, you could become a project committer.
The following guidelines are meant to help contributors work with the committers and the community as a whole:
- Follow coding conventions. Seriously, read that document.
- Install the OFBIZ Subversion client configuration file
- Follow the 2 main rules for committers:
- Rule #1 for a committer is the same as for a doctor: first do no harm. Nothing should be committed that breaks existing functionality without replacing it either before or in the same commit. Whatever you are working with someone developed it and chances are someone is using it, and possibly MANY people.
- Rule #2 for a committer is the same as for a scientist: read before you write. When you're getting started a good time ratio for read to write is around 20 to 1. Once you're a total OFBiz pro who knows as much as any living person about the project, you can probably reduce that to about 3 to 1.
- Discuss your features with the community. What are you trying to implement, and how are you planning to do it? This is especially important if you are new to the project.
- Write clear, well-commented and understandable code. Don't take shortcuts, especially around variable names and error or warning messages. Use understandable data structures. Remember, somebody else will be working with your code down the road.
- When you prepare a patch, do your best to avoid to mix formatting changes with relevant changes (if possible, provide a separate patch containing only formatting changes): in this way the reviewer's work will be easier
- When you prepare a patch, do not insert in the code comments with author information since your name will be recorded in the commit log (that is the place were we store this kind of information)
- Internationalize your code with UI labels.
- Start out with small contributions which are easier to review. In the process, get familiar with the project's coding style and "thought process."
- Keep patches and contributions easy to review and commit. Even if a lot of code is touched, try to keep things isolated and the intent of the patch(es) clear. Remember that most committers can find 20 minutes here and there, but it is very hard to fit in the 2-4 hour time block required to review and commit a larger patch (especially if it touches ANY lower level or more sensitive or complex artifacts, and this requires more thorough review).
- Put your contributions on JIRA instead of emailing it directly to the committers, so everybody can review and comment on it. Though it is not necessary this makes contributions more traceable for the licensing through the Apache Software Foundation.
- Get other members of the community to try your patch. Write the dev list and tell them what you've done and ask them to try it out and vote for it. This will help the committers when they are reviewing your patches as there will be more confidence that the patch does what it is intended to do, and doesn't break anything else.
If you are planning a larger contribution, please follow the following tips to facilitate both licensing and collaboration. These tips will make it easier for committers to review and incorporate your work, and will overall speed up your development process as you'll be asking the OFBiz team to do a number of small, simple tasks rather than a couple of large tasks that a committer will have to find significant time to review and commit.
- Do not implement large blocks of artifacts (code, etc) on your own and then contribute them to OFBiz.
- 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.
- When a method is deprecated, it should be explained which method should be used, and what has changed.
- 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.
- 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.
- 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.
How to Send in Your Contributions (or how to create and apply patches)
The first step is to create an account for yourself on the JIRA issue tracker and then create a new issue. Describe the contribution that you are making: are you fixing a bug, improving an existing feature, or creating a new feature? Please write as detailed a description as you can and attach screenshots if possible of what you've done. OFBIZ is a huge project, and what may be obvious to you might not be to someone else, even a committer who is familiar with the project.
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:
Code Block |
---|
$ 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
Code Block |
---|
$ 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
Code Block |
---|
$ svn status applications/product
|
to see which files have been modified (they start with an "M") or added (which start with a "?").
Then do:
Code Block |
---|
$ 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:
Code Block |
---|
$ 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:
Code Block |
---|
$ 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 committers 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 committer 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.
When a Jira issue is totaly totally resolved, we prefer to close the issue than to put it as resolved. There are some cases where there is a tentative resolution and you don't want to close the case because you want the reporter or someone to review and test the fix to make sure it was what was intended. If it is a simpler issue and especially if you are the reporter, then it is best to just close it right away rather than coming back to it later to close.
Why is it Taking So Long to Get My Patch into OFBiz?
...