Section : Documentation > Development

DataNucleus is an Open Source development. It is written by many people yet has a broad scope and so is in need of help. It is released under an Apache 2 license, so you are welcome to develop it further. Since the software is free, you are benefiting from this work. You have a duty to contribute to the project, particularly if/when you have problems. It should be noted that many people use open source software without the minor intention of contributing anything back to it; thats ok but then should everyone adopt that attitude then things will not get improved, and additionally those people are not in a position to request/expect any improvements that they would like to see (without putting something back in).

You can help the project in many ways. Here are some examples

Note that involvement in an open source project can significantly improve your employability, since potential employers can see the quality of your code, so this is an opportunity to do something positive. Note also if you contribute to the system in some way then we are more likely to answer your forum questions, or listen to your ideas, so its in your interests to participate. We hope that the above has given you some idea how your time can be used to benefit the common goal of having a quality Java persistence solution free for all to use.

DataNucleus 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.

When you have DataNucleus commit rights (see this forum thread), the development process should be as below. Please abide by these simple rules

  1. Identify an issue to work on for a particular DataNucleus plugin. Raise an issue if it doesnt yet exist, and allocate to yourself.
  2. Develop code, unit tests (as appropriate), and documentation for the issue. DataNucleus is developed using JDK1.8+ (DataNucleus 3.x is developed with JDK1.7+).
  3. Run all DataNucleus tests and the (public) JDO TCK, and when all pass to the same level as before then you can check your code into GitHub. Broken unit tests or JDO TCK tests must be fixed ASAP. Others are using GitHub latest 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.
  4. 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
  5. Where changes are significant and you cannot split them into smaller check-ins (that pass the tests) should be checked in to your own GitHub branch and when complete they should be merged into GitHub master. If help is needed at this point then other developers should help in merging large changes.
  6. All check-ins should refer to the issue being worked on in their commit message (#34 contained in the commit message links the commit to issue #34 of that plugin).
  7. Mark the issue as Resolved for the next release.

Coding Standards

Coding standards are more complicated to define so please look here for details.

Mailing Lists

DataNucleus has no mailing lists as such, but each plugin is developed in GitHub and you can subscribe to notifications about a particular plugin.


All contributions to the DataNucleus project must adhere to the Apache 2 license. Notwithstanding that, at the discretion of the administrators of the project, DataNucleus project downloads may include separately licensed code from third parties as a convenience and where permitted by the third party license, provided this is clearly indicated.


As a general rule, we branch when were at a point of changing internal/external DataNucleus APIs of a plugin. So, for example, we are developing datanucleus-core and want to change some API. The process is as follows

  1. Create branch with name {version} where the version is the version that is stored in that branch (so the current version).
  2. Update pom.xml of master branch to the next version number (so if we have just created a branch for 3.2 then this will be 3.3.0-SNAPSHOT).

If you are developing a new feature then you can optionally develop it in its own branch, so choose a branch name that is not a version (so doesnt conflict with the naming convention above). When you have fully implemented the feature and merged it into master and it is fully tested then you should delete the old branch.


Tagging is performed when we release a plugin, and the Maven release plugin automatically creates tags with names of {artifact_id}_{version} (e.g datanucleus-core-3.2.11). Developers shouldnt have any need for adding other tags.


There are many different versioning systems in use by software. All typically use major.minor.revision (occasionally with finer grain below that). Some use suffix alpha or beta to reflect how close the software is to full release. Some use versioning starting at say 1.0.0, and going up from that until some release e.g 1.0.4 that is considered the full release. DataNucleus uses the following versioning policy

  • When we start a release lifecycle for a product it starts typically at Milestone 1 (e.g 1.0.0.M1). If we are developing a new plugin that will be used from DataNucleus v5.0 then we will start at 5.0 Milestone 1 (5.0.0.M1) for the new plugin.
  • Subsequent releases increment the milestone e.g 1.0.0.M2, 1.0.0.M3 etc
  • When we feel we are close to a full release we can optionally have Release Candidate (e.g 1.0.0.RC1)
  • We have as many release candidates as necessary to get everything feature complete
  • The full release is Release (e.g 1.0.0.Release)
  • Any subsequent releases (after the full release) in that lifecycle increment the revision number, e.g 1.0.1, 1.0.2 etc

The use of Milestone rather than alpha or beta is because all DataNucleus releases are run against all unit tests and TCKs and so stability is typically inherent.

We increment the minor version number when we are changing internal APIs (but not client facing APIs). We increment the major version number when we are changing external (client-facing) APIs.

Product Release Process

DataNucleus AccessPlatform is simply a bundled distribution and is typically released at intervals every 1-2 months, usually taking the latest release of each related plugin and packaging it. When there is a DataNucleus product to be released (e.g AccessPlatform), the following is the release process (administrator role)

  • Make sure that all required plugin versions are released. See the plugin release process below for details.
  • Go to the product that needs releasing update so that versions of all required plugins are set, and the version of the product is set. Check this change in.
  • Generate the required product archives (zips), and the documentation.
  • Release the archives and documentation on SourceForge

Plugin Release Process

Since DataNucleus development policy is that all current tests should always pass for checked in code then a plugin is always in a releasable state. In general changes dont sit in the source repo for more than a month without release. If a commercial client requires a particular feature or bug fix then a release is expedited. If some upstream plugin needs releasing first then it is released before the plugin in question. We try to avoid any changes in internal APIs that would affect downstream plugins if not in a new release cycle. The following is the release process (administrator role)

  • Check that there are no unresolved issues marked against the release version in question and, if necessary complete the outstanding ones, or move them to a later version.
  • Should a developer have a good reason for the release not happening (e.g wanting to get another fix in first) then the release could be delayed, but this is the exception not the norm.
  • Use the Maven release plugin as follows : mvn clean release:clean release:prepare release:perform. This updates the version to remove SNAPSHOT, builds source/javadocs/jar, creates a tag and finally copies it to Sonatype ready for release.
  • Go to the DataNucleus Sonatype account and check/release/close the repository artifacts)

Sample Release Process

We try to make all samples use Maven and have the same release process, so then the released archive is consistent. This is the release process for a sample

  • Go to samples project and edit the pom.xml for version and dependencies
  • Create the assembly using mvn clean assembly:assembly
  • Copy the zip file on to SourceForge (or get an admin to do it)

DataNucleus Extensions and Extension-Points

DataNucleus products are built using a plugin mechanism, allowing plugins to operate together. This plugin mechanism is useful also from a user viewpoint in that you, the user, could provide plugins that use these plugin points and extend the capabilities of DataNucleus. Plugins are loaded by a plugin manager when DataNucleus is initialised at runtime, and this plugin manager uses a registry mechanism, inspecting jars in the CLASSPATH. The three steps necessary for creating a DataNucleus plugin are

  1. Review the DataNucleus Extension-Point that you will need to implement to generate the plugin, and implement it.
  2. Create a file plugin.xml at the top level of your JAR defining the plugin details (see the actual Extension docs).
  3. Update the META-INF/MANIFEST.MF file contained in the jar so that it includes necessary information for OSGi.

Extension points differ from one version of DataNucleus to another, so you should consult the documentation of the version of DataNucleus that you are using. The documentation for extensions in the latest version of DataNucleus can be found here


DataNucleus originated as JPOX in 2003, becoming DataNucleus in 2008, and consequently many people have contributed to its development over the years and has been open source since the outset. In terms of metrics of the codebase you can get a measure of this by looking at the DataNucleus page on OpenHub.

Development Team

The management and direction of DataNucleus is provided by a small team of experienced individuals.

Andy Jefferson : Founder of the DataNucleus project. Has worked on the project since its initiation as JPOX in 2003, and has worked on all plugins. Initiated the support for db4o, ODF, MongoDB, NeoDatis, Neo4j, OOXML, Cassandra, javax.cache, RDBMS connection pools, and much more. Also contributed to version 2 of the plugin for GAE/Datastore, subject to the constraints that Google put on it.

Renato Garcia : worked on the migration to GitHub, test suite flexibility, auto-generation of MANIFESTs, Jenkins/Solar automation, and some more.

Baris Ergun : Took over responsibility for the geospatial plugin. Currently inactive

Erik Bengtson : Founder of the DataNucleus project. Worked on the project since its initiation as JPOX in 2003, until around 2011. Initiated support for Excel, XML, JSON and HBase. Currently inactive

Stefan Seelmann : Wrote the vast majority of the LDAP plugin. Currently inactive

Thomas Marti : Wrote an amount of the spatial plugin (now renamed to geospatial). Currently inactive

Stefan Schmid : Wrote an amount of the spatial plugin (now renamed to geospatial). Currently inactive

Joerg von Frantzius : worked on the test suite, and RDBMS areas. Currently inactive

In addition to those above, other people have contributed to varying degrees in the development of this software or documentation.

DataNucleus tackles a wide range of problem areas - are you interested in contributing to the DataNucleus project and want to get involved? The best way is to become part of the DataNucleus community and start by contributing patches. From that, gain commit rights. Where you take the project to from there is up to you.