As discussed in developer meetings, and approved (via vote) on dspace-devel, the DSpace Java API will be refactored as detailed in the "Service-based API" proposal:
Vote on proposal: http://dspace.2283337.n4.nabble.com/PLEASE-VOTE-on-whether-to-include-Services-API-refactoring-in-DSpace-6-0-tp4679123.html
This constitutes a MAJOR refactor of the DSpace Java API that comes with several key benefits:
- 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)
- The API itself will 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 changes, the refactor process should not be difficult, but it will be necessary before you can successfully upgrade to 6.0.
However, it is NOT backwards compatible with DSpace 5.x or below. Again, anyone who has made customizations that rely on the Java API (dspace-api) may need to refactor their local customization. But, we believe that vast majority of institutions (likely 90% or more) should not experience any upgrade difficulties, as most only make customizations to the theme / look and feel of either the XMLUI or JSPUI.