Page History

...

...

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.

1. Any changes must be Java 1.6 compliant.
2. When possible, your contribution should be a patch against the SVN Trunk (latest) code.
3. 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 section below.
4. Your contribution must adhere to licensing requirements to be included. Refer to the Licensing of Contributions below
5. User interface patches must be internationalised (see the I18nSupport guide)
6. User interface patches must be XHTML-compliant and have a W3C WAI Conformance Level of "Double-A"

...

1. Where possible, new User Interface features are encouraged to support both XMLUI and JSPUI interfaces. However, this is not a requirement. Patches supporting only one interface may be accepted.
2. Your patch must come with Documentation. Minimally, technical documentation must be part of the system docs – see Documentation Contributions below. Ideally, we'd also like User/Usage Documentation.
3. Examples or Use Cases should be submitted to help Committers understand and adequately test the patch prior to applying it to the core code
4. Patches should be small diffs (no large all encompassing patches!) using the unified output format. If you need help with generating a patch, there are many good resources out on the web. Here are just a few:
   • How to Create a Patch
   • Creating Patchs
   • Ten Minute Guide to Diff and Patch
5. Any new features should be configurable (i.e. try not to make features specific to your own institution, they need to be generalized if possible). 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
6. 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.
7. Add appropriate WARN, INFO and DEBUG-level logging. Use the included Apache Log4J toolkit, in concert with the

...

1. org.dspace.core.

...

1. LogManager class to do this. See

...

1. org.dspace.app.webui.servlet.

...

1. DSpaceServlet for an example of how to do this.
2. Retain backwards compatibility where possible. If there are questions/concerns about this, let us know. There are always exceptions.
3. No

...

1. Database 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

...

1. Database schema changes

...

1. below

If there are questions/concerns about any of these guidelines, let us know on the 'dspace-devel' list. We are willing to make exceptions in some areas, if exceptions are necessary

...

.

...

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 codeAll code contributions must come with Documentation. At a bare minimum, this should include Technical Documentation covering all configuration options and/or setup. See Documentation Contributions below for more details.

Licensing of Contributions

Any third-party libraries (e.g. 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 acceptable to require additional downloads of JARs to make DSpace compile or function.

...