DataNucleus Development

DataNucleus is open source, released under the Apache 2 license. As a result you are welcome 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 JPA/JDO features
  • Support for improved persistence to existing datastores (e.g Excel, LDAP, XML)
  • Support for persistence to new datastores (e.g Cassandra, Redis)
  • Development of DataNucleus tooling (Eclipse plugin, Maven plugin etc)
  • 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; we're not interested if you only have a week or so and then disappear off onto something else. There are many interesting parts of the system to work on so this is your chance to get aboard the project; and demonstrating to an employer an involvement in an open source project can be beneficial to your career.

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 Forum), the development process should be as below. Please abide by these simple rules

  1. Identify an 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.6+.
  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.

Licensing

All contributions to the DataNucleus Project must adhere to the Apache 2 license. Notwithstanding the above, at the discretion of the PMC, 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.

All contributions must contain the following copyright notice. 

/**********************************************************************
Copyright (c) 2006 {your name} and others. All rights reserved.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Contributors:
{year} {contributor1} - {description of contribution}
{year} {contributor2} - {description of contribution}
    ...
**********************************************************************/

The original contributor is the one who contributes the first version of the file. A contributor may be a person or an organization - whoever owns the copyright. If the contributor is an organization, the person may also be indicated. For each additional contributor, indicate the part of the code or contribution that came from the contributor, especially if it contains an interesting algorithm or data table etc. For clarity, also indicate the contributor in the actual section of contributed code. Also reference the bug ID if applicable. The basic principle is to clearly identify the contribution... especially if it is a separable block of code.

Versioning

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 at 1.0 Milestone 1 (1.0.0.M1)
  • Subsequent releases increment the milestone ... 1.0.0.M2, 1.0.0.M3 etc
  • When we feel we are close to a full release we can optionally have 1.0 Release Candidate 1 (1.0.0.RC1)
  • We have as many release candidates as necessary to get everything feature complete
  • The full release is 1.0.0(.Release)
  • Any subsequent releases in that lifecycle increment the revision number, so 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.

Coding Standards

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

Mailing Lists

DataNucleus has the following mailing lists to aid in tracking development. They are read-only.

Product Release Process

When there is a DataNucleus product to be released (e.g AccessPlatform), the following is the release process

  • Make sure that all required plugin versions are released. See the plugin release process for details.
  • Go to the product that needs releasing and checkout the latest code. Make a note of the revision number
  • Update build.properties so that versions of all required plugins are set, and the version of the product is set. You can check this change in
  • Generate the required product archives, and the documentation.
  • Release the archives and documentation on SourceForge
  • Create a directory under ${DATANUCLEUS}/releases/{product_name}/{version}/ and put a file in there called revision containing the revision number noted

Plugin Release Process

When there is a DataNucleus plugin to be released, the following is the release process

  • Go to the sub-project that needs releasing and checkout the latest code. Make a note of the revision number
  • Update pom.xml and META-INF/MANIFEST.MF so that the version(s) are set (of the plugin and any dependencies). You can check these changes in
  • Build and test the code
  • Build, install and deploy the plugin (to Nightlabs), using 
    mvn clean source:jar install assembly:assembly deploy:deploy -DdescriptorId=src
  • Create a directory under ${DATANUCLEUS}/releases/{plugin_name}/{version}/ and put a file in there called revision containing the revision number noted

Metrics

DataNucleus originated as JPOX in 2003 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 we recommend use of Ohloh, providing number of lines of code, estimated cost etc to replicate it.
Ohloh -