Why You Should Contribute to OFBiz
By contributing your improvements back to OFBiz, you can get our entire community of developers and users to help you debug, improve, or extend the features that you need for your business. Furthermore, if your contributions improve OFBiz, then it would help to attract more users and more developers for OFBiz down the road, and eventually those users and developers would make contributions that would benefit you. Finally, the process of contributing back to the project is a great way for new users and developers to work with the existing community and learn more about OFBiz so they could tap into its power and flexibility.
How to 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.
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 ML. But then please respect the conventions above.
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:
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.
Apart from the above you can also refer to entitymodel.xsd for understanding the tags.
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.
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. 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 tool like Tortoise
We prefer that you build your patch from the root as it's easier for commiters 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 tha in your patch file names should look like these :
and should not have file names like: C:\myfiles\ofbiz\applications\party\widget\partymgr\PartyScreens.xml
Exemples using command line:
If you have added new files, then use the "add" command first, then make the 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
to see which files have been modified (they start with an "M") or added (which start with a "?").
if you only want to make a patch file of the entity/ sub-directory and the ShipmentServices.xml file.
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:
To make sure you have the most recent revision always do an SVN update before doing the patch with svn diff, something like this:
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.
When a Jira issue is totaly 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?
The first thing to remember is that in order for something to get done an individual or group must have sufficient ability and time to do it. There are no paid OFBiz committers, everyone works on a volunteer basis. This is a natural side effect of OFBiz being a community-driven project rather than "commercial open source".
When someone submits a patch they are asking for someone in the group of committers to do something for free. Sometimes because of the volume of patches it is overlooked and then with a constant stream of new issues, complaints, questions, etc it may be a long time (if ever) before someone gets back to it. Most unfortunately there aren't any committers that can work on contributing to OFBiz full-time because so far there are no committers that don't need to also earn a living. Most committers work with OFBiz in their day job, and because of the size and complexity of the project so far that seems to be the only way someone even can consistently contribute to OFBiz. That doesn't mean they are paid to work on your issue though, unless you and they get lucky and it happens to be related to a paid client objective.
If you REALLY want your patch in, you can get it in. If you want it in, your job is to help the committers get it in. You can recruit others on the mailing lists to review and test your patch. This is really important, because OFBiz is fairly complex and many patches break rule #1, which is in short, "first do no harm". In other words, do break stuff that already exists that other people implemented, and that other people are using.
There is also another option... as mentioned above OFBiz is unfunded and every committer has an employer of some sort, often a handful of clients. This would explain why things are getting committed all the time, even though sometimes the volume of patches getting reviewed and committed is pretty low. If committers are lucky then they get to work on stuff that goes back into OFBiz, and that is ONLY reason that most of the functionality in OFBiz exists at all, especially in the applications (most of the framework, on the other hand, was not ever sponsored). Some people see this as unfair. Others see it as a great stroke of luck that they can take advantage of.
If this isn't working for you, then consider getting more involved with OFBiz or somehow making it possible for others to get more involved with OFBiz. There are many ways you can help, even without becoming a committer yourself. There are the exact same things you can do in order to become a committer if you do enough of them, but of course you can do all of these without any longer term commitment or hoops to jump through. You don't even have to get a committer or PMC member to do anything in order to do these things!
- Subscribe to the dev mailing list, try to read the majority of the messages, and participate in discussions there
- Review and comment on issues in the Jira issue tracker
- Apply patches from Jira locally and test them and comment on the results
- Create patches to fix issues reported in Jira
- Get to know OFBiz and submit patches to fix problems or annoyances you find
- Follow all of the rest of the advice in this document
How Do I Become a Committer Myself?
If you're interested in becoming a committer, that's great! We would love to have you and the whole community will really appreciate your help.
Being a committer can be a great help to your employer and/or clients. It can also be a great asset in your personal and career growth. There is a guarantee that in the course of your activities you will learn and grow. You'll learn about building enterprise applications, both the technical and business sides of them. You'll also learn a lot about working with other people, especially working with other people remotely.
For more information and to get started see the Committers Roles and Responsibilities page.