Doing a bit of research to see what is needed out of a 1.4.M0 review - and thought I should share concerns raised thus far.
Goal:
- proposal for tonights GeoServer meeting
Concerns:
- division between module support (platform? runtime?) and the existing main module (capture spring dependencies and support classes separate from the support classes for OWS and configuration)
- use of spring context - is there once big flat context for the entire module system?
- provision of support classes to gather up annotated classes from modules (um is that Java 5 only? oh wait a uniformly named file in each module would do the trick)
- module naming to prevent collisions (recommendation of org.vfny.geoserver.xxModuleName may conflict with maven conventions?)
- docs on how things are wired up (actually a diagram request, possible BeanDoc)
Actions:
- review spring xml files and add notations for "BeanDoc"
Concerns:
- division between module support (platform? runtime?) and the existing main module (capture spring dependencies and support classes separate from the support classes for OWS and configuration)
Separation into:
- main - module support, sucks spring dependencies together in a pom.xml, with docs and utility classes as required (see below...)
- data - open web service support (requires a config)
- use of spring context - is there once big flat context for the entire module system?
No, each module has a context.
- provision of support classes to gather up annotated classes from modules (um is that Java 5 only? oh wait a uniformly named file in each module would do the trick)
This is needed if two modules want share the same database, and is the motivation for utility classes in main. The Java 5 part seems to be not important.
- module naming to prevent collisions (recommendation of org.vfny.geoserver.xxModuleName may conflict with maven conventions?)
Was a problem with maven eclipse:eclipse - rename modules to prevent conflicts.
- docs on how things are wired up (actually a diagram request, possible BeanDoc)