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.

  • Created by Unknown User (wiki_transfer), last modified on Apr 05, 2010

<?xml version="1.0" encoding="utf-8"?>
<html>
<big>1. Move the 'dspace-pom' module from the 'dspace-pom' directory to the root directory of the project.</big>

<big>2. Remove the profile activations from the 'dspace' that are based on the presence of a pom.xml file all together, and instead force the modules to be "always-on" by putting them in <module>/<modules> elements in the 'dspace-pom' module (now in the root directory).</big>

This still allows for modularity, and the Eclipse M2 plugin will recognize each sub-project.

<big>3. Move the remaining profiles from 'dspace' and put them in the 'dspace-pom' module (e.g. the oracle and postgres related profiles).</big>

This is so that users can activate profiles from the root of the project, and removes non-assembly related roles from the 'dspace' module.

<big>4. Rename the 'dspace' module to 'dspace-assembly'.</big>

Now the role of the 'dspace-assembly' project is clear.

<big>5. Create a new profile, named 'assemble' to activate the 'dspace-assembly' module in the 'dspace-pom' module.</big>

So that assembly needs to be specifically invoked, keep it out of the regular build cycle. I suppose this really isn't needed, but.

<big>6. My suggestion would be to update module ancestry to follow the new directory structure:</big>

dspace-pom -> dspace-jspui
dspace-pom -> dspace-api
dspace-pom -> dspace-assembly
dspace-pom -> dspace-oai
dspace-pom -> language-packs
dspace-pom -> dspace-xmlui -> dspace-xmlui-api
dspace-pom -> dspace-xmlui -> dspace-xmlui-webapp
dspace-pom -> dspace-xmlui -> dspace-xmlui-wing
dspace-pom -> dspace-lni -> dspace-lni-core
dspace-pom -> dspace-lni -> dspace-lni-client
dspace-pom -> dspace-lni -> dspace-lni-webapp

Maven 2 and its plugins just seem to deal nicer when the directory structure of the modules mimics the ancestry of a module.

<big>don't use '<relativePath>', and update subproject dependencies as required</big>

This results in a source layout like:

.
|-- dspace-api
|   `-- src
|-- dspace-assembly
|   |-- bin
|   |-- config
|   |-- docs
|   |-- etc
|   `-- src
|-- dspace-jspui
|   `-- src
|-- dspace-lni
|   |-- dspace-lni-client
|   |-- dspace-lni-core
|   `-- dspace-lni-webapp
|-- dspace-oai
|   `-- src
|-- dspace-xmlui
|   |-- dspace-xmlui-api
|   |-- dspace-xmlui-webapp
|   `-- dspace-xmlui-wing
|-- language-packs
|   |-- ca
[...]
|   `-- zh
|-- pom.xml
|-- src
|   |-- main
|   |-- site
|   `-- test

<big>7. You'll need to tweak the paths of the assembly descriptors. Assembly would be invoked from the root of the project.</big>

</html>

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.