Page History

...

• 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
• 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
• 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. generate
       • This is a small project that creates the executable stubwrapper generator
    2. common
       • This contains 'fedora.common' package
       • includes wsdl2java generation and stubwrappers
    3. server
       • This is the 'fedora.server' packageincludes wsdl2java generation and stubwrappers
    4. client
       • This is the 'fedora.client' packageincludes stubwrappers generation
    5. integrationtest
       • This is the 'fedora.test' package
       • has dependencies on both '/client' and '/server'
• 3 - m2-only (full split-out)
  • Admin Client
  • Java Client API
  • Server Webapp
  • Installer
  • (Old GUI)
  • New GUI
• 4 - Split out server modules as projects
• 5 - Rename packages based on Maven-central's requirements

...

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'

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.