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

Compare with Current View Page History

« Previous Version 18 Next »

Table of Contents

One of the things we have been meaning to do is convert our build framework over from ANT to Maven2.
The time has come, and the work is in-progress (jira:fcrepo-394).

The basic strategy was laid out in our last face-to-face committers' meeting in Ithaca.
As you can see, there are a few things that need to be done. If you are interested in helping, I would be very happy to coordinate efforts. Send me an email, Andrew Woods.

Approach

Since moving to Maven2 requires significant restructuring of the baseline directories, we want to make small, incremental changes back to svn/trunk so that the on-going fedora development does become too far seperated. This means that the ANT builds must continue to work as the baseline becomes incrementally transformed.

Progress/Status

(warning) Not yet
(info) Partial
(tick) Complete

  • (tick) 1a - Source conformant to m2 standards (files and packages) + tweak build.xml
    1. This was checked-into svn:fedora/trunk.rev.8076
    2. The basic structure of maven has been created (src/main/java, src/test/java, etc)
    3. The renaming of packages based on Maven-central's requirements will happen at the very end of this whole effort
  • (tick) 1b - Get poms for all dependencies
    1. Based on the jars in the /lib dir, a simple install script pushes them into the local repository
    2. Need to create proper *.pom and <dependency> for each artifact
  • (info) 2 - Ant-maven integration (four subprojects) with main goal of installer.jar
    • This initial integration requires a minimum break-out of the following subprojects
      1. (info) generate
        • This is a small project that creates the executable stubwrapper generator
      2. (tick) common
        • This contains 'fedora.common' package
        • includes wsdl2java generation and stubwrappers
      3. (info) server
        • This is the 'fedora.server' package
      4. (info) client
        • This is the 'fedora.client' package
      5. (info) integrationtest
        • This is the 'fedora.test' package
        • has dependencies on both '/client' and '/server'
  • (warning) 3 - m2-only (full split-out)
    • Admin Client
    • Java Client API
    • Server Webapp
    • Installer
    • (Old GUI)
    • New GUI
  • (warning) 4 - Split out server modules as projects
  • (warning) 5 - Rename packages based on Maven-central's requirements

To Revisit

If you would like to help, these nuggets need a friend.

  1. Currently, all of the maven dependencies are in the top-level pom.xml
    1. They need to be surgically pushed down to their approapriate 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. All 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

Rationale

Subproject break-out
generate

Finding the appropriate lines on which to draw subproject (maven module) boundaries is not an exact science.

During this initial conversion to Maven2, we want to minimize the degree of baseline upheavel while splitting out subprojects enough to allow maven to properly function.

A logical starting point is:

  • client
  • server
  • common

Where 'client' has a dependency on 'server', and they both depend on 'common'.
This becomes a little problematic with the introduction of wsdl stubs/skeletons and in the case of Fedora, second-level generated source code wrapping the generated wsdl stubs.

The generated artifacts are as follows:

  • wsdl-stubs
  • wsdl-skeletons
  • wsdl-stub wrappers

The sequence of events to produce these artifacts is as follows:

  1. compile fedora class (BuildAxisStubWrapper.java)
  2. run axis-wsdl2java on fedora wsdl's
  3. run executable BuildAxisStubWrapper on wsdl2java outputs (wsdl-stubs)

The binary output of step-2 above is needed by 'server' during compilation.
The source output of step-2 above is needed as input to step-3.
The source output of step-3 above is needed by 'client' during compilation.

  • Note: the source output is needed here instead of the binary because the generated source imports dependencies on 'client'.
    Therefore, the source output of step-2 is needed by 'client' before the compilation phase.

This being the case, the three-step sequence above can all be pushed down to 'common'.
The only problem here is that an executable BuildAxisStubWrapper is needed before the source-generation phase of running axis-wsdl2java.
Therefore, a fourth subproject is needed to create the BuildAxisStubWrapper executable: 'generate'.

integrationtest

There is a combination of unit, integration, and system tests within the baseline.
The 'integrationtest' subproject grew out of the need to have tests with dependencies on all of the other functional subprojects.

As it so happens, their is a test base class (FedoraTestCase.java) that is extended by several other tests from both 'server' and 'client'.
FedoraTestCase itself depends on both 'server' and 'client'.
Therefore, all tests that extend from FedoraTestCase are implicitly integration tests and have been migrated to the 'integrationtest' subproject.

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels