Page History

Background

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

...

This proposal is to begin to utilize the tools in Spring Boot to turn DSpace's "backend" webapps (REST API, OAI-PMH, SWORD, SWORDv2, RDF) into a single, easy to install webapp.  At 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).

...

All of the separate, backend web applications (namely SWORDv1, SWORDv2, OAI-PMH, and RDF) would be merged into a single Spring Boot web application (i.e. the REST API v7 webapp).  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 (defining several @Beans).  This is a direct replacement for the web.xml concept.
   1. For example, in PR#2265, SWORDWebConfig.java replaces SWORDv1's web.xml
      1. Notice how the class defines a series of @Beans, all of which can be enabled/disabled via DSpace configuration (in this case a "sword-server.enabled" property).
      2. Additionally, this class can pull in other DSpace configuration/settings to allow for path customization (see the "swordPath" variable in this example, which reads from the "sword-server.path" configuration)
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 The implementation of this can be found in this work-in-progress the initial PR: https://github.com/DSpace/DSpace/pull/2265

...

However, if you install the root webapp at the root path, then this behavior is similar to current DSpace (v6). For example, if the "spring-rest" WAR is accessible at https://mydspace.edu/, then all webapps modules would be a subpath of that:

...

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

This was discussed in a DSpace 7 Working Group meeting, and it was decided that the single webapp will be named "dspace-server", as it comprises the primary "server-side" components of DSpace 7. 

(NOTE: Technically, there is also a server-side portion to the Angular UI to precompile UI pages in support of SEO, etc.  However, as the Angular UI is primarily a client side user interface, we still feel this single webapp is most appropriately called the "server" webapp.)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, we may want to consider giving it a more generic name to make it clear that it's much more than just the REST API.