Niels, I favour option 3 (new module gt-complex) because it does different things to gt-app-schema-resolver, which builds no features or types, has no dependency on gt-app-schema, and concerns itself with finding and caching XSD documents and making them available to the gt-xsd-core Configuration API.
Kind regards, Ben. On 07/12/12 22:24, Niels Charlier wrote: > I am working on this proposal: > > http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema > > The idea is to split app-schema stuff (as discussed earlier) in to > general complex feature stuff and specific app-schema stuff > > But I need to decide on a final decision for what to do with the complex > feature stuff. > > There are four possible destinations suggestions: > > * become part of gt-main > * become part of gt-data > * become new module gt-complex > * merge with gt-app-schema-resolver in to gt-complex > > Note that the two options have as a side effect that gt-main/gt-data > becomes dependent on gt-app-schema-resolver and everything it depends > on, which might be undesired! > > My preference goes to option 4. > > Kind Regards > Niels > > -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
