Page History

The Service-based API refactoring will take place on the DS-2701-service-api feature branch. As this API is NOT backwards compatible, all existing DSpace Modules will need to be refactored to utilize this new API. 

If you would like to help out, please claim one or more DSpace Modules, and submit a PR (against the above "DS-2701-service-api" branch) which fixes that module. A module is considered "fixed" when it compiles (against the new API) and all its unit tests (if any) pass. Please submit one PR per module. (NOTE: PLEASE WAIT FOR THE INITIAL API merger before starting any module refactors)

•  New dspace-api - Kevin Van de Velde (Atmire)  - NOTE: This merger must occur before any other work can begin.
•  dspace-jspui - Andrea Bollini (4Science) (and others).  Fixed JSPs by Folder (under /src/main/webapp)
  
  •  WEB-INF/ (no JSPs)
  •  browse/ (Kevin Van de Velde (Atmire)
  •  components/ Mark H. Wood (nothing to fix)
  •  controlledvocabulary/ Mark H. Wood (nothing to fix)
  •  css/ (no JSPs)
  •  discovery/ Mark H. Wood (nothing to fix)
  •  dspace-admin/ Kevin Van de Velde (Atmire)
  •  error/ Kevin Van de Velde (Atmire)
  •  feedback/ Mark H. Wood (nothing to fix)
  •  help/ Kevin Van de Velde (Atmire)
  •  image/ (no JSPs)
  •  layout/ Mark H. Wood (nothing to fix)
  •  login/ Mark H. Wood
  •  mydspace/ Mark H. Wood (nothing to fix)
  •  register/ Mark H. Wood
  •  requestitem/ Mark H. Wood (nothing to fix)
  •  search/ Mark H. Wood
  •  sherpa/ Kevin Van de Velde (Atmire)
  •  static/ (no JSPs)
  •  statistics/ Mark H. Wood (nothing to fix)
  •  submit/ Kevin Van de Velde (Atmire)
  •  suggest/ Mark H. Wood (nothing to fix)
  •  tools/ Kevin Van de Velde (Atmire)
  •  workspace/ Kevin Van de Velde (Atmire)
  •  [root folder] Kevin Van de Velde (Atmire)
•  dspace-lni - Robin Taylor will refactor LNI out entirely (as suggested in DS-2124)
•  dspace-oai - Mark H. Wood
•  dspace-rdf - Pascal-Nicolas Becker
•  dspace-rest - Peter Dietz (DSPR#1026)
•  dspace-services (will this be completed as part of the inital refactor?)
•  dspace-solr (should not need refactoring. No dspace-api methods called)
•  dspace-sword Andrea Schweer
•  dspace-swordv2 Andrea Schweer, Tim Donohue (claimed from Robin T so he can concentrate on LNI) 
•  dspace-xmlui-mirage2 - Kevin Van de Velde (Atmire)
•  dspace-xmlui - Kevin Van de Velde (Atmire)

Once all modules successfully compile and pass all unit tests, the feature branch will be merged into "master" and more extensive testing will be performed.

a major refactoring of the "dspace-api" (DSpace's Java API) to better support "separation of concerns/responsibilities". Simply put, often, in the existing (5.x and below) API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace "Service-based API" attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate.  The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate).

• This is essentially a new Java API for DSpace. (Some areas of our API are still the same, but most have been refactored)
  
  • NOTE: It is not backwards compatible with the existing (5.x and below) Java API.
• It modularizes our primary API in a way that makes it much easier to achieve future goals on our Roadmap (especially, moving us towards potentially better support of third-party modules)
• It cleans up one of the "messiest" areas of our existing API, the Database management / hardcoded Oracle and PostgreSQL queries, in favor of using Hibernate.  This allows us the potential to support additional database platforms in the future (e.g. MySQL or similar). It decreases the likelihood of Oracle-specific bugs (which have always been a problem), as the Oracle queries are delegated to Hibernate. It also simplifies the process of testing for database-specific problems in general (as again, all queries are delegated to Hibernate).
• It begins teasing apart a true "business logic layer" in the API (see the "service layer" of this new API)
• It provides (internal) globally unique UUIDs for all DSpace objects (instead of existing incremental, non-unique database identifiers)
• The refactored API itself should not affect the fresh installation or upgrade process of DSpace 6.0, provided that you have not made local changes that rely on the existing Java API (dspace-api). If you have made such local API changes, your refactor process should not be difficult. But, it will be necessary before you can successfully upgrade to 6.0. See "Tutorials" below for examples.