| Susan, The way to do it without altering the code in place requires creating a custom maven project within the dspace/modules/ directory, wiring it into the dspace/pom.xml and dspace/modules/pom.xml so that it compiles into the build process. At this point, I'm seeing community member using both approaches, and I'm unsure which I would most recommend. But here's what I try to approach as a best practice. 1.) I don't like to alter code in place in dspace-api, dspace-xmlui or any of those projects unless I intend to contribute it into the next release of DSpace 1.5.x 2.) Keeping all those projects around lengthens the build process and if your not using all of them (dspace-sword, lni, etc) thats a lot of compile time for nothing. 3.) Once configured properly, your changes in dspace/modules/xxx will always be separate from the rest of the codebase, but you will still need to verify that upgrades don't break your customizations by comparing your code to the original. Something we continue to strive to get away from. So I would recommend the following steps: a.) create a dspace/modules/custom-api/pom.xml for your api changes. That looks something like the attached pom.xml |
<project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> <modelVersion>4.0.0</modelVersion> <groupId>org.dspace.modules</groupId> <artifactId>custom-api</artifactId> <packaging>jar</packaging> <name>DSpace :: Modules :: Custom Changes</name> <description> Changes to the API specific for the your repository </description>
<parent>
<groupId>org.dspace</groupId>
<artifactId>modules</artifactId>
<version>1.5.1</version>
</parent>
<repositories>
<repository>
<id>maven.dspace.org/snapshot</id>
<name>DSpace Maven Snapshot Repository</name>
<url>http://maven.dspace.org/snapshot</url>
<releases>
<enabled>false</enabled>
<checksumPolicy>fail</checksumPolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
</repository>
</repositories>
<dependencies>
<!-- DSpace API -->
<dependency>
<groupId>org.dspace</groupId>
<artifactId>dspace-api</artifactId>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.3</version>
<scope>provided</scope>
</dependency>
</dependencies>
</project>b.) Alter your modules/pom.xml to include it as a module (you can turn off any other modules that you do not want to use here as well.
c.) Add custom-api as a dependency to any modules project you require it within or to the dspace/pom.xml so that it is included into [dspace]/lib as a dependency. I hope this documentation is helpful should you choose this approach. But you can feel free to take the approach that best solves your situation for you. Mark On Feb 3, 2009, at 12:35 PM, Thornton, Susan M. (LARC-B702)[NCI INFORMATION SYSTEMS] wrote:
~~~~~~~~~~~~~ Mark R. Diggory |
------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
