Discussion of Castor Subproject Work
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.
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:
Files, interfaces and classes of general use. Not restriced to internal use from other modules.
Files, interfaces and classes not moved to a specific module yet. Should only contain xml binding at the end of the whole module work.
Files, interfaces and classes for database persistence. Final target should be to have no compile time dependency to xml module from here.
Files, interfaces and classes for source generator.
core, xml, jdo
Files, interfaces and classes for ddl generator (Google SOC 2006 project).
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.
JAXB 2.0 spec APIs
The Spring integration for Castor JDO
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.)
- 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