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:

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:

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

And here is a view into the src directory:

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