Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

This project would reorganize and consolidate some of the maven project hierarchy to reduce the number of maven projects neccessary to operate DSpace.

Benefits: Reduce the number of maven projects in DSpace "Core" from 39 to 19.

Example Repository: https://github.com/dspace/DSpace/tree/maven-project-consolidation

This project would consolidate:

  • dspace-xmlui
    • dspace-xmlui-wing
      • src/main/java
    • dspace-xmlui-api
      • src/main/java
      • src/main/resources
    • dspace-xmlui-webapp
      • src/main/resources
      • src/main/webapp

and it would reduce it down to

  • dspace-xmlui
    • src/main/java
    • src/main/resources
    • src/main/webapp

We would utilize the current model found in dspace-swordv2 (http://scm.dspace.org/svn/repo/dspace/trunk/dspace/modules/swordv2)

dspace-swordv2

  • src/main/java
  • src/main/resources
  • src/main/webapp

http://scm.dspace.org/svn/repo/dspace/trunk/dspace/modules/swordv2/pom.xml

How it works:

SWORDv2 uses skinny WARs and the generation of secondary artifacts (classes.jar) to create the proper artifacts needed for the overlay process.

<build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <configuration>
                    <attachClasses>true</attachClasses>
                    <!-- In version 2.1-alpha-1, this was incorrectly named warSourceExcludes -->
                    <packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>
                    <warSourceExcludes>WEB-INF/lib/*.jar</warSourceExcludes>
                    <webResources>
                        <resource>
                            <filtering>true</filtering>
                            <directory>${basedir}/src/main/webapp</directory>
                            <includes>
                                <include>WEB-INF/web.xml</include>
                            </includes>
                        </resource>
                    </webResources>
                </configuration>
                <executions>
                    <execution>
                        <phase>prepare-package</phase>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

To produce this for DSpace XMLUI and other webapplications we would consolidate all the project directories in each case and create the same build process for them as well.

Then to add the dependencies into the overlay projects such as dspace/modules/swordv2, the dependencies just need to have the webapp.war and api.jar dependencies replaced with the following

<dependencies>

      <!-- DSpace Custom SWORDv2 Web application -->
      <dependency>
        <groupId>org.dspace</groupId>
        <artifactId>dspace-swordv2</artifactId>
        <type>war</type>
      </dependency>

      <!-- DSpace Implementation of SWORDv2 Provider -->
      <dependency>
        <groupId>org.dspace</groupId>
        <artifactId>dspace-swordv2</artifactId>
        <type>jar</type>
        <classifier>classes</classifier>
      </dependency>

   </dependencies>

In this task we would want to retain svn history as effectively as possible, this means that we will want to probibly do the following

  • create dspace-xxx/src/main directories and commit them to svn
  • copy/move individual "webapp", "java" and "resources" directories into the new src/main directory space.
  • move all dependencies from dspace-xxxx-api/pom.xml into dspace-xxxx/pom.xml and commit
  • move build and dependencies from dspace-xxxx-webapp/pom.xml into dspace-xxxx/pom.xml and commit
  • remove dspace-xxxxx-api and dspace-xxxxx-webapp directories from SVN
  • adjust all dspace/pom.xml and dspace/modules/yyyyy/pom.xml to use the appropriate dependencies afterward 

A prototype branch of this work has been completed in SVN and is ready for testing purposes.

  • No labels

2 Comments

  1. Actually I wonder if Wing should be inside of DSpace at all. It's fairly general. If it has a maintainer, perhaps it should move out to its own standalone project and become an external dependency of DSpace like Log4j.

    1. It was so easy to consolidate into xmlui, there are no other cases where it is used so I assumed as such, its better consolidating it into the project.  Its not that it's fairly general, its that is actually very specific to and only ever used by xmlui.