Development
Documentation
Testing
DataNucleus Development

DataNucleus is an open source Java persistence implementation. It is released under the Apache 2 license. Its source code is available under this license, enabling you to develop it further. We require assistance on many areas of the project should you be interested. A few selected areas where work is needed are

  • Development of JPA2/JDO2.x features
  • Support for persistence to different datastores (e.g Excel, LDAP, XML)
  • Development of the DataNucleus Eclipse plugin(s)
  • Performance improvements
  • Documenting the DataNucleus system

If you are interested, please go to the DataNucleus Forum and raise a thread in the Volunteers forum. Please make sure that you have time to spend on DataNucleus development before volunteering as this would only waste our time otherwise. There are many interesting parts of the system to work on so this is your chance to get aboard the project.

Development Process

DataNucleus uses Test Driven Development (TDD). It has many test suites available and all should be run to provide stability in the codebase.

Once you have DataNucleus commit rights (see Forum), the development process should be as below

  1. Identify Issue to work on. Raise a JIRA if it doesn't yet exist, and allocate to yourself
  2. Develop code, unit tests (as appropriate), and documentation for the issue. DataNucleus is developed using JDK1.5+ but has to be runnable on JDK1.3+.
  3. Run all DataNucleus unit tests and JDO2 TCK, and when all pass to the same level as before then you can check your code into SVN
  4. Broken unit tests or JDO TCK tests MUST BE FIXED ASAP . Others are using SVN trunk too and if you break either the build or the tests then it means they often cannot work effectively. Breakage of unit tests or JDO TCK tests mean that your changes can be rolled back
  5. Issues that involve many changes should be split, where appropriate, into smaller steps so that you can still pass point 3 above with each check in
  6. Where changes are significant and you cannot split them into smaller check-ins (that pass the tests) should be checked in to your own SVN branch and when complete they should be merged into main SVN If help is needed at this point then other developers should help in merging large changes
  7. All check-ins should have a prefix in the description like [NUCCORE-23] for the issue being worked on. Then they will be indexed by JIRA and so we can track changes.
  8. Mark the JIRA issue as "Resolved" for the next release.

Please abide by these rules.