See also the Guide to Developing with DSpace.
When you contribute to DSpace, please be sure that your submission adheres to the points in this checklist. The DSpace committers need you to do this to keep quality of the DSpace code high and their work manageable.
Ensure the code is commented and correctly formatted (you can use Eclipse's format function to do that or a tool like Jacobe). Refer to the*Coding Conventions below
Your contribution must adhere to licensing requirements to be included. Refer to the*Licensing of Contributions below
Technical and User on-line help as part of the patch. Technical documentation must be part of the system docs – see*Documentation Contributions below.
Patches must be small diffs (no large all encompassing patches!) using the unified output format (see*Submitting a Patch below for flags)
For example, if you add a new e-thesis-related submission step, you might add a couple of new config parameters: webui.submit.thesisstep, and webui.submit.thesisstep.colour. If webui.submit.thesisstep = false, the submission process should not be affected for those not using DSpace for e-theses. Also, if your code finds that webui.submit.thesisstep is missing, it should assume a default of 'false' so that after an update, previous installations of DSpace behave as expected, and they do not have to add that parameter to their dspace.cfg.
*NOTE: Omission of one or more of these items is likely to result in the patch not being applied and returned to you for further work
*Create the patch file and submit to the DSpace JIRA System
Your code needs to follow the Sun Java code conventions with the following minor modifications:
Your code should be well commented with Javadoc (including package and class overviews). You should also be prepared to document your code in the system docs, but you don't need to do that before contributing the code.
Any third-party libraries (JARs) required to compile or run DSpace must be included. The license of any required jar MUST be compatible with BSD; it must not prevent any commercial use of DSpace, nor have any impact on the rest of the code by its inclusion. It is not acceptible to require additional downloads of JARs to make DSpace compile or function.
Examples of acceptable licenses:
Examples of unacceptable licenses:
JDBC drivers for databases are an exception since:
If you are including new jars or later versions of existing jars, you need to include the associated license file for inclusion in the lib/license directory. The README file in the lib directory must also be updated as part of the patch to describe the jar and identify the jar version.
Database schema changes will be done only on major revisions to the source; this is when the version number takes the form x.y (e.g. 1.3). When making patches which cause schema changes it is necessary to update all of the relevant SQL files with your sequences, tables, views etc. (in /dspace/etc):
Follow exactly the same procedure as above; the documentation resides in the {dspace/docs/docbook} directory.
As of 1.5.1, the documentation is now in docbook. The docbook sources are used to
generate both HTML and PDF forms of the documentation. There are many docbook tutorials available, but you may find it easiest to just review the existing documentation source for an example of what you want to achieve.
Submit the patch to the DSpace JIRA System. Be sure to describe the modification, including the numbers of any bug/feature request items that the patch relates to.
Once you have produced and submitted your patch to the DSpace JIRA System it must be reviewed, tested and approved by one of the committers (see DSpaceContributors for more details). Comments regarding the submission can be posted to JIRA and you will receive email notification of any feedback. If and when your patch becomes stable and approved it will be integrated into the DSpace code base by one of the committers.
During the normal release cycle a feature freeze will be declared for a given date, and normally only patches submitted prior to that date will be considered for the upcoming release. Any patches submitted after this will be in time for the feature freeze of the following release. The date of submitted patches may be flexible depending on the time available for testing and integration and the urgency/usefulness of the patch. Patches which fix bugs will also generally be considered until much closer to the final release date.