This page describes a brainstorm / work in progress. It is not stable or usable in Production at this time. If this is ever released, you'll hear about it in a future release!

Background

In the past we've had several discussions/attempts at making DSpace easier to install (e.g. Installer PrototypeInstaller Brainstorms). 

However, with DSpace 7.0, the new REST API (dspace-spring-rest module) is now a Spring Boot web application.  Spring Boot's entire purpose is to provide tools to make easy-to-install web applications.

This proposal is to begin to utilize the tools in Spring Boot to turn DSpace's "backend" webapps (REST API, OAI-PMH, SWORD, RDF) into a single, easy to install webappAt this time, I'm concentrating only on the backend webapps, as they are all Java webapps. So, it does not include the new Angular UI.  I'm also specifically excluding the old REST API (v4-6), as it is deprecated in DSpace 7 (and will be removed in DSpace 8).

How would we achieve this?

All of the separate, backend web applications (namely SWORDv1, SWORDv2, OAI-PMH, and RDF) would be merged into a single Spring Boot web application.  This can be achieved as follows:

  1. Keep each as a separate Maven module
  2. Turn each Maven module into a JAR (i.e. update each module's POM)
  3. Add a new dependency on Spring Boot (spring-boot-starter-web), to allow each module to use Spring Boot annotations/APIs.
  4. Replace each module's web.xml webapp configuration with a Spring @Configuration class.  This is a direct replacement for the web.xml concept, and allows you to map the module to a specific path (e.g. /sword or /oai) in Spring Boot.
  5. Remove the Overlay folder for the module (from [dspace-src]/dspace/modules/).  The Maven Overlay concept is only supported by WARs, and therefore, all Overlays would be applied to the Spring Boot webapp.

An example of this can be found in this work-in-progress PR: https://github.com/DSpace/DSpace/pull/2231

What is the benefit?

Deploying the DSpace backend as a single web application makes it much easier to install/deploy within Tomcat.  We also could consider using Spring Boot's capability to embed Tomcat directly, so that deployment is as simple as running the application.

Other questions to consider

Would I still be able to disable specific features?  For example, what if I don't need or want to install SWORD

Yes, though it'd be different.  Instead of choosing not to install that webapp into Tomcat, you would choose not to build that webapp into DSpace.

For example, to not install SWORDv1 and SWORDv2, you'd just build DSpace without those modules. As the Spring Boot configuration for each module is provided by a Spring @Configuration class (included in the module), if that module is not included in DSpace then that endpoint/path will not be enabled.

# Build DSpace, excluding the "dspace-sword" and "dspace-swordv2" modules
mvn -U clean package -P '!dspace-sword,!dspace-swordv2'


Alternative Option: I'm also looking into a way to provide an "enabled=true" configuration flag in each module's *.cfg file. This flag would allow you to disable the endpoint/path even if the module is included in DSpace.


Can I still overlay specific classes within a module (e.g. in OAI-PMH or SWORD)?

While this still needs to be tested out further, you should be able to simply move those overlays to overlay the main DSpace Spring Boot web application.  So, all overlays would now exist in a single place.

Can I still change the URL or path of OAI-PMH or SWORD?

Partially. This is a small compromise.

Obviously, if these modules are included as a separate webapp, you can easily change the paths/URLs to be whatever you want (via Tomcat and/or Apache configurations).

When they are all included in one webapp, then each module must be a subpath of that root webappWhile this still needs to be tested out further, we should be able to allow you to customize or rename the subpath of each module.  But, you cannot change the base URL.

For example, if you main URL is https://mydspace.edu/, then all webapps would be a subpath of that:

If the backend is all one webapp, what should this webapp be called?

Good question.  Currently, the work-in-progress PR leaves this Spring Boot webapp named "dspace-spring-rest" (i.e. it's the REST API v7 module).  But, if this one webapp now includes all modules, it would need a more generic name.