Versions Compared

Old Version 60

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 61

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Java 17 (or later) and Tomcat 10 (or later) is required for the backend.  The DSpace 8 backend can no longer be run on Java 11 or Tomcat 9 as it has been updated to Spring 6 / Spring Boot v3 to support Jakarta Enterprise Edition 9+.  You must upgrade these dependencies in order to run DSpace 8.  If you are using a different servlet engine, you must ensure it is compatible with Jakarta EE 9+ (e.g. Jetty must be version 11 or later)
    • If you have any custom Java code or custom plugins, they must all be migrated to use "jakarta.*" dependencies instead of "javax.*" dependencies.  It is not possible to use older "javax.*" dependencies in DSpace 8. 
  • Node 18 or 20 is required for the frontend. The DSpace 8 User Interface has been upgraded to Angular 17, and Node 16 is no longer supported. This is less likely to impact local customizations, but is worth being aware of.
  • The deprecated REST API v6 ("dspace-rest" module) was removed.  All custom code must be migrated to the new REST API (first released in 7.x).  Any custom code which depends on the older REST API v6 must be rewritten, as the new REST API is not backwards compatible. For more information on the removed REST API v6, see the DSpace 7.x documentation.
  • "Type" field (dc.type) is now required by default. In all submission form configurations (in "submission-forms.xml" as described in Submission User Interface), the "dc.type" field is now required. This was changed to better support integrations with DataCite and other systems that expect a "type" for every resource.  If you do not want this change, you can undo the changes in your local copy of "submission-forms.xml". (Donated by The Library Code)
  • The "dc.date.available" field is no longer set by DSpace during submission. DSpace has had two fields which represented when an object was added/available in DSpace: "dc.date.accessioned" and "dc.date.available".  The Accessioned Date (dc.date.accessioned) has always represented the date the object was deposited into DSpace, while the Available Date (dc.date.available) represented the date the object was first available (which may be later than the accessioned date if the item had an embargo).  Since Embargo information is now stored on the item's authorization policy, the "dc.date.available" date is no longer useful or accurate.  Therefore, DSpace no longer will automatically set a "dc.date.available", as any embargo date can be retrieved via the item's policies. See #9103.
    • If you have any custom code that relied on the "dc.date.available" metadata field, we recommend updating it to use "dc.date.accessioned".  Alternatively, you could use the REST API to obtain embargo information from an Item's resource policies.
  • In User Interface, the service which generates HTML "<meta>" tags in the "<head>" tag has been renamed from "MetadataService" to "HeadTagService".  If you have generated custom "<meta>" tags, then you will need to migrate them to the new "/src/app/core/metadata/head-tag.service.ts" file.

Major Updates and Improvements

...