Skip to end of metadata
Go to start of metadata

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
  • No labels

5 Comments

  1. I actually don't think that this work needs to take place on a branch, to be honest. The way we are dealing with implementing support for JPA 3.0 clearly indicates that this is not required, as your work will mostly be additions to existing code. And for any refactoring required to integrate e.g. a new mapping loader, the current code should be sufficient. If it isn't, in-place refactoring should take place.

    If Java 5.0 is a requirement for JAXB 2.0 support, a separate Subversion should be created like has been done for JPA support.

  2. Sounds great. I will try to refine the 'included classes/packages' table based upon the Maven POMS I have created as part of http://jira.codehaus.org/browse/CASTOR-1416. As this is not finished and test ed yet, please bear with me.

    A few more thoughts:

    a) Somehow it'd feel right to include the Spring ORM package here as well. An alternative would be to create a fully fledged project. Same goes for the JAXB 2.0 compliance implementation (once that materializes .. (wink)).

    b) I think that we might (want to) add one or more module at a later stage. Point is that I'd like to see this incrementally approached, as there's really nothing that prevents such an approach.

  3. I left of SpringORM and JPA by intention as they anyway have seperate repository locations at the moment. Therefore we don't need to take care on them with this task. We may deside later if we keep the seperate repositories or move one or the other into a module in Castor repository. As we may need Java 5 for both of them, SpringORM and JPA, I guess we may need to stay with the seperate repositories. The same applies to JAXB when it materializes.

    I also think we will need to furter split some of the suggested modules in smaller pieces at a second step:

    * JDO -> PERSIST, DATABASE and LDAP/DAX

    * XML -> XML, DTD and XLS

    * remaining parts of MAIN -> MAPTOOL

     but let's do one step after the other.

  4. I agree with Bruce that e.g. the mapping mudule eventually should go into its own module (with src/main and src/test directories accordingly). Please note the eventually. As part of issue 1416, I have provided all the files required (bar the POM for a srcgen package, which happens to live on my hard disk only for the time being). The patch attached clearly shows that one can switch to proper modules (incl. POMs) whilst stick with the current directory structure (fo rthe time being).

    In other words, I'd prefer if we could tackle one thing after the other. And I still want to have a fully wokring project at any time, as I'd like to make 1.0.2 available in about 14 days. And no, no branches. That means, that yes, we are going to suffer from some overhead, but it's doable. That's what is most important.

    I am out now for 10 days, see you on July 25. Bye 

  5. The project layout suggested by Bruce sound reasonable to me and seams to have quite some advantages over the one I had thought off. According to his questions from above:

    1. From the castor-mapping, I do not understand this statement: 'Concrete mapping or configuration loaders are only included if they do not rely on xml module or annotations.' Can someone clarify this?

    2. How will castor-jdo not have a compile time dependency on castor-xml? Does castor-mapping mitigate this?

    3. Shouldn't the JDO mapping loader reside in the castor-jdo module instead of the castor-xml module?

    Modules like castor-jdo and castor-xml will only have compile time dependency to interfaces and classes contained in castor-mapping module. Therefore concrete MappingLoader's don't need to be contained in castor-mapping module. Instead they can be included with every other module or the user may provide his own implementation. To achive this the available MappingLoader's are configured in castor.properties file. As the MappingLoader implementation used to load castor mapping file (CastorMappingLoader) will use castor-xml there will be a runtime dependecy to from castor-jdo to castor-xml but no compile time dependency.

    If we'd put the CastorMappingLoader into castor-mapping module there will be a bidirectional compiletime dependecy between castor-xml and castor-mapping which I think is not a good idea. CastorMappingLoader in castor-jdo module will require dependency to castor-xml also for those that like to use a different MappingLoader e.g. based on annotations. In addition will CastorMappingLoader for jdo and xml share a big amount of code, at least as far as I can see that at the moment, which would not be possible if it would reside in castor-jdo module. Taking every thing into account I thought that the best place for it would be castor-xml module.

    Annotation based MappingLoader's should not be placed in castor-mapping module according to their Java5 dependency. I thought they should be placed in modules that already require this dependecy like castor-jpa and castor-jaxb.

    Hope this explains the idea behind the short remarks a bit better.