To edit or add content to this Wiki, you can simply create a new account at http://wocommunity.org/account.
There are many ways for anyone to help develop Project WOnder. It would be helpful to become familiar with the information in Creating and Submitting an Acceptable Patch. For more minute detail, you can keep up with the committers's progress moment by moment by subscribing to the Commit History RSS feed on GitHub.
Project WOnder is a large set of frameworks and example applications and utility applications. Project WOnder can be used with different versions of WebObjects. (What versions of WOnder are compatible with what versions of WebObjects?) Developers may be using different tool sets to edit their projects, including eclipse and Xcode. Contributors should keep all of this in mind as they make changes.
Please see this tutorial on importing the Project Wonder sources into your eclipse environment.
There are dependencies between the frameworks that make up Project WOnder that must be kept in mind while changes are being made.
We have done a webcast about how to contribute to Project Wonder by using Git, you can get the recording here
Since the move of Project Wonder to GitHub, the main branch ("master") is for WebObjects 5.4. If you use WebObjects 5.3, you have to use the Wonder_5_0_0_Legacy branch.
Project WOnder uses different name prefixes for different parts of the system. Prefixes include those in the list below. Note that there may be components and classes in very different parts of the system which do similar things. Code and resources are not necessarily organized by functionality, but may be organized by time of creation, by author, or by some other factor.
It is not always easy to find things. Ask the mailing list if you have questions.
If you add new components into ERExtensions, please put your bindings into the WOD file. For other non-core frameworks and examples, you can use WOOgnl bindings.
If you are adding new code to Wonder, please use of the above prefix for your additions. If you don't know which one to use, go with "ER".
Before EVERY commit, please make a diff and check if it's reasonable and then take care what you commit with which message.
Do NOT commit reformatted code, at the very least, do it in two steps, one for the reformat, one for the actual changes so one can see what is going on.
DO NOT commit changes in the d2wmodels when saved with RuleEditor. This should be obvious from the previous rule, but it's VITAL that these files are committed with one and one tool only.
You can do pretty much what you like in your own projects, but take EXTREME care in Frameworks/Core.
The burden is clearly on those who deliver patches to provide them in a way where you can actually see what has changed and to make these changes with minimal impact.
- Anjo Krank, 2011
Always messing up spacing and commiting spacing changes which upset everyone? With git, you can use
When you generate any diff with -b, it will ignore spacing diffs. So then create a new branch (from master) and re-apply the diff. That way you'll only have real changes, not spacing ones.
Or just don't make formatting changes in the first place.
- Miguel Arroz, 2011
One can see the different branches of the project by going to the GitHub branches page