Page History
...
See also the Guide to Developing with DSpace.
Overview of Code Approval Process – How to get your Code into DSpace!
Make your code available
First, you must make your code available to the DSpace Committers Group for review. This can be in the form of a patch (usually posted to our Issue tracker), or you can provide us with downloadable version or read-only access to your SVN or CVS code repository.
| Info | ||
|---|---|---|
| ||
Code contributions that meet certain standards are much more likely to be accepted immediately. For a list of our current standards, please read through the "Code Contribution Standards" section below. |
| Info | ||
|---|---|---|
| ||
The best way to inform us of your code contribution is by entering a new issue into our Issue tracker. We will then review & comment on your code in that same area (and it will automatically send you an email with our comments). |
| Note | ||
|---|---|---|
| ||
When the next release of DSpace is getting close, the Committers will set a "Feature Freeze" date, after which no new features/code will be accepted for that release. The reason for this is that the Committers need time to stabilize the current code before the next release can be completed. Make sure to check the Next Release Status page for details on when the next "Feature Freeze" is – if you are submitting your code too close to the "Feature Freeze" date, it may unfortunately need to wait until after the next version of DSpace is released. Patches which fix bugs will also generally be considered until much closer to the final release date. |
Code Review Process
Once the code is made available, the Committers Group will take time to review the work and provide feedback/comments. Usually, one (or more) committers who are interested in this work will contact you and discuss any feedback we have, and whether or not there would need to be some general changes before we could accept it. Some code changes are readily accepted (because they are stable and look good), others may require more work (if there are concerns or issues that Committers notice).
...
Once your code is accepted, it will be released in the next version of DSpace software!
Code Contribution Standards
Code contributions that meet the following standards are much more likely to be accepted. If you don't understand any of these standards, please contact us – we'll be glad to explain or help.
Contribution Checklist
When you contribute to DSpace, please be sure that your submission adheres to the points in this checklist. The DSpace committers Committers need you to do this to keep quality of the DSpace code high and their work manageable.
- Your contribution needs to When possible, your contribution should be a patch against the SVN trunkTrunk.
- 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
- User interface patches must be internationalised (see the I18nSupport guide)
- User interface patches must be XHTML-compliant and have a W3C WAI Conformance Level of "Double-A"
- Technical and User on-line help as part of the patch. Technical documentation must be part of the system docs – see Documentation Contributions below.
- Examples or Use Cases should be submitted to help committers understand and adequately test the patch prior to applying it to the core code
- Patches must be small diffs (no large all encompassing patches!) using the unified output format (see Submitting a Patch below for flags)
- Any new features must be configurable. Be careful in particular with the `dspace.cfg` file. Make sure you only patch this if you change involved new configuration parameters in it, and make sure you have good default values for them. Don't accidentally include your own local configuration parameters (e.g. host name etc) in the patch! If the new feature is in any way specific to a particular application (e.g., open access, theses), it should be switched off by default
- If you add new configuration parameters, name them appropriately. Also, they should not be required to be in dspace.cfg – if the parameters are omitted, DSpace should continue to operate as before.
- 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.
- Add appropriate WARN, INFO and DEBUG-level logging. Use the included Apache Log4J toolkit, in concert with the `org.dspace.core.LogManager` class to do this. See `org.dspace.app.webui.servlet.DSpaceServlet` for an example of how to do this.
- Retain backwards compatibility where possible
- No DBMS schema changes unless absolutely necessary – this will mean upgrading would require effort. In this case, you also need to supply upgrade instructions and/or code to upgrade in existing installation. See 'Database schema changes' below
- Any changes must be Java 1.5 compliant. Some additional notes on compatability with previous Java versions is also available
| 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 |
...
| Info | ||
|---|---|---|
| ||
Once you've created |
...
the patch file |
...
, submit to the* DSpace |
...
Coding Conventions
Your code needs to follow the Sun Java code conventions with the following minor modifications:
...
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.
Submitting the Patch
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.
What Happens Next
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.
Overview
Content Tools