Page History

...

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
      1. An initial push down is essentially complete though additional verification and pom optimization is needed
   2. Their dependency declaration needs to point to the proper version on maven-central, not the locally created artifact
      1. All of the artifacts that can be resolved to maven-central without selected new versions is complete
      2. Additional validation is needed especially to ensure that conflicts do not cause problems
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 Maven Bamboo CI build
11. server/src/main/resources/properties/lib.properties may be a candidate for removal as it was tied to the Ant build
12. libraries listed in server/src/resource/properties/install.properties do not automatically update with library updates and duplicate information in the pom which does not benefit from pom dependency checking

Rationale

Subproject break-out

...