Archived / Obsolete Documentation

Documentation in this space is no longer accurate.
Looking for official DSpace documentation? See all documentation

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

<?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>

  • No labels