Page History

...

• For Larger Initiatives/Codebases: If you are building out a much larger project, we highly recommend notifying the community of the work early on via an email to dspace-devel@googlegroups.com (or via one of the weekly Developer Meetings).  This has several benefits:
  • Ensures you achieve your goals in a way that is consistent with the DSpace architecture and plans of the rest of the community. 
  • Minimizes the chances of a scenario where you have invested a large amount of time and effort into a body of code that does not fit in with the DSpace architecture or the consensus of the community.
  • This can help find collaborators or get early feedback.
• Develop incrementally; try and implement and contribute a basic form of your feature as soon as possible, rather than aiming to implement a complete and 'polished' solution. This will help ensure you're on the right track with regards to the rest of the DSpace community and platform. The sooner your code is part of the core code base, the less time you will have to spend 'chasing' the main code base, i.e. keeping your changes up-to-date with that core code base.
• Obtain the DSpace code using GitHub (see also Development with Git). This will make code management much easier. It's very simple to do; see Developer Guidelines and Tools.
• Read Code Contribution Guidelines 81953128 (this page) and Code Style Guide to ensure you are following DSpace conventions. This will ensure your code is more likely to be immediately accepted as part of out-of-the-box DSpace.
• Ensure that any third-party tools/libraries that you plan to utilize are released under compatible open source licenses. See the Licensing of Contributions 81953128 section below.

1. Make your code available (preferably in GitHub) and create a ticket in our Issue Tracker

...

...

3. Reworking Code (if necessary) & Next Steps

...

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.7 compliant. compliant with the supported version of Java (e.g. for DSpace 7, Java 11 compliance is required)
2. Your code should adhere to our Java Code Style Guide.  Most major IDEs can easily import our Checkstyle configurations to ensure alignment with this code style
3. Your contribution must adhere to licensing requirements to be included. Refer to the Licensing of Contributions 81953128 below
4. User interface patches must be internationalised (see the Internationalization Support (I18nSupport) guide)
5. User interface patches must be XHTML-compliant and have a W3C WCAG Conformance Level of "Double-A"
6. 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.
7. Your code must come with Documentation. Minimally, technical documentation must be part of the system docs – see Documentation Contributions 81953128 below. Ideally, we'd also like User/Usage Documentation.
8. Examples or Use Cases should be submitted to help Committers understand and adequately test the patch prior to applying it to the core code
9. 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
10. 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.color. 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.
11. 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.
12. Retain backwards compatibility where possible. If there are questions/concerns about this, let us know. There are always exceptions.
13. No 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 Database schema changes 81953128 below.
14. If your code makes changes to the database schema or content, and you are patching more than one branch (for example, 5_x and master), see Patching multiple branches 81953128 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). All 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 81953128 below for more details.

Licensing of Contributions

...