Page History

...

1. Until dependencies are found in a public repository, the following script needs to be run
   • ./resources/scripts/installLibs.sh
2. mvn clean install
   • builds all source code
   • runs all unit & integration tests
3. mvn install -Dintegration.test.skip=true
   • runs all unit tests
   • skips all integration tests
4. mvn install -Dmaven.test.skip=true
   • skips all unit tests

5. Wiki Markup
   {{mvn integration-test \-P config\[A\|B\|Q\]}}

   • runs system tests per given configuration
6. mvn install -P fedora-installer
   • generates fedora-installer.jar
   • found in /installer/target

During the build refactoring it is recommended that you clear the top-level "duraspace" section of your local repository after doing SVN updates and reinstalling the local dependencies. Note that this is not the same as the "org.duraspace.fedora" section where build artifacts are installed; the Maven build will take care of that for you.

Unresolved

1. Currently, all of the maven dependencies are in the top-level pom.xml
   1. They need to be surgically pushed down to their appropriate subproject pom.xml
   2. Their dependency declaration needs to point to the proper version on maven-central, not the locally created artifact
2. The continued need for each junit suite aggregator class needs to be re-evaluated
3. Unit test naming conventions need to be standardized (since maven invokes them based on a regex at different build phases)
   1. unit-test: '**/*Test.class'
   2. integration-test: '**/Test*.class'
4. Unit/system/integration tests used to fall under 'fedora.test'
   1. now that they have been split across subprojects ('server', 'client', 'integrationtest'), they are not aggregated with a single call (i.e. fedora.test.AllUnitTests)
   2. a fix to this issue would only be needed as long as we continue to use ANT, Maven2 has its own test aggregation
5. Build number & timestamp needed for artifact names and manifest files
   • client.jar
     • needs 'fedora.version' in filename and manifest
     • needs 'build.tstamp' in manifest
   • The following is a plugin that should do the trick
   • It should be configured in the top-level /pom.xml and /client/pom.xml
   • http://mojo.codehaus.org/buildnumber-maven-plugin/index.html
   • The build number plug-in fails if the SCM is unavailable or is not installed on the host platform. A <revisionOnScmFailure> parameter has been added to set a default build number. A warning is still shown during build but the build runs properly to completion. The default build number has been set to the "version" of the fedora-repository pom assuming that pom's version will eventually match a current or planned release.
6. Refactor fedora.test.FedoraTestCase.java into two classes (one dependent on '/server' and one on '/client') so tests the inherit from it can be pushed back down from '/integrationtest' to their respective projects.
7. fedora.test.integration.cma.SimpleDeploymentTests has a bug. See source file for details.
8. In creating fedorahome.zip, deploy and undeploy *.wsdd files are token-swapped (e.g. 'Fedora-API-M-Port-SOAPHTTP' to 'management').
   • This mangles token instances such as 'Fedora-API-M-Port-SOAPHTTP S'. This is a pre-existing bug.
9. Running the maven-built installer can result in an out of memory exception:
   • java -jar installer/target/installer-1.0.0-fedora-installer.jar
     Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
     at java.util.jar.JarInputStream.getBytes(JarInputStream.java:82)
     at java.util.jar.JarInputStream.<init>(JarInputStream.java:65)
     at java.util.jar.JarInputStream.<init>(JarInputStream.java:43)
     at com.simontuffs.onejar.JarClassLoader.loadByteCode(JarClassLoader.java:450)
   • Chris has been able to reproduce this consistently in Ubuntu with Sun Java5 and Java6.
   • Dan has been able to reproduce this consistently on Windows XP with Sun Java5 and Java6.
   • This can be worked around by specifying -Xms256m -Xmx256m (increasing the heap size).
   • The installer currently is built with superflouous jars, so that may be the cause.  It may be the case that the dependency push-down effort (#1 above) resolves this.
10. Script needs to be written to support Bamboo CI build (the Ant build is now broken)

Rationale

Subproject break-out

...