Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Discussion of Castor Subproject Work

Realisation

Bruce originally suggested to split up Castor into modules in a branch for Castor 2.0. As there will be massive impact on Castor source which would lead to lots of files that need to be merged, we desided to do this work on trunc.

Intended target release for splitting up Castor into modules is 1.1.

It is not intended to move files, interfaces and classes from their current package to a different one with this task. If anything needs to be moved according to other tasks this does not influence the module assignment.

Modules

Repository

The base URL for all Modules is http://svn.codehaus.org/castor/castor/trunk/

Each module should reside in it's own directory and the parent POM resides in the trunk directory. This organization is very typical for a Maven directory structure. An example of this organization taken from the XFire Project trunk:

No Format
BUILDING.txt
LICENSE.txt
base.iml
build-common.xml
build.properties.template
build.xml
checkstyle.xml
examples/
lib/
maven-bundle-plugin/
pom.xml
pom.xml.old
root.iml
xfire-aegis/
xfire-all/
xfire-annotations/
xfire-castor/
xfire-core/
xfire-distribution/
xfire-generator/
xfire-java5/
xfire-jaxb/
xfire-jaxb2/
xfire-jaxws/
xfire-jibx/
xfire-jms/
xfire-loom/
xfire-picocontainer/
xfire-plexus/
xfire-sandbox/
xfire-spring/
xfire-ws-security/
xfire-xmlbeans/
xfire-xmpp/
xfire.ipr

Now let's take a look at the directory structure inside of one of these modules. Here's the xfire-core directory structure:

No Format
build.xml
core.iml
pom.xml
src/
target/
xdocs/
xfire-core.iml

And here is a view into the src directory:

No Format
main/
test/

Inital modules

modules

compatibility

depends on

responsibility

castor-core

Java 1.3

none

Files, interfaces and classes of general use. Not restriced to internal use from other modules.

castor-xml

Java 1.3

core

Files, interfaces and classes not moved to a specific module yet. Should only contain xml binding at the end of the whole module work.

castor-jdo

Java 1.3

core, xml

Files, interfaces and classes for database persistence. Final target should be to have no compile time dependency to xml module from here.

castor-srcgen

Java 1.3

core, xml

Files, interfaces and classes for source generator.

castor-ddlgen

Java 1.3

core, xml, jdo

Files, interfaces and classes for ddl generator (Google SOC 2006 project).

Additional modules

modules

compatibility

depends on

responsibility

castor-mapping

Java 1.3

core

Files, interfaces and classes that build the infrastructur to load mappings and jdo configuration. A bidirectional dependency between mapping and xml modules need to be omited.

castor-jaxb2

Java 1.5

 

JAXB 2.0 spec APIs

castor-spring

Java 1.4

 

The Spring integration for Castor JDO

castor-schema

Java 1.4

 

The Castor XML Schema Object Model; Maybe we could consider putting all schema models in this module (e.g., XML schema, relational schema, LDAP schema, etc.)

Tasks/Problems

  • How to handle Configuration (castor.properties) and Messages (message.properties)?
    Possible solutions to this problem are:
    • Whole configuration resides in core module
    • Independed configuration of every module
    • Base configuration in core module that are extended by module specific configurations
      It need to be discussed where constants for the keys of the properties/messages should be defined.
    • No specific location. Define them where needed.
    • In Configuration class.
    • Special utility classes that only define constants for keys.
      For XML there are specific getters for many of its configuration properties in Configuration class.
    • Stay with this design and leave them in Configuration class.
    • Configuration class should only have general getters to be used for different properties. Code to access specific properties need to be movfed somewhere else.
  • Refactor mapping loader into interfaces and specific implementations
  • Refactor JDO configuration loader into interfaces and specific implementations