Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


The idea is to split the app-schema module in twothree:

  • The first part would contain everything that helps with complex features in general : building them, and can be moved to gt-main: mainly builders
  • The second part would contain everything that helps with complex features in general and depends on XSD: evaluating filters against them (property accessor, x-path evaluation), building complex feature types from XSD. These classes do not rely on specific schemes like GML, etc... apart form XS.
  • The second third part will contain anything that is app-schema specific: creating complex feature datastores with mapping files.

The second third part would continue as the gt-app-schema module. The first part will be moved to gt-main. More specifically, the following classes will be moved:

  • org.geotools.feature.AttributeBuilder (PARTLY)
  • org.geotools.feature.TypeBuilder
  • org.geotools.util.ComplexAttributeConverterFactory

The second would split off and become a new module 'gt-complex'. More specifically, this 'gt-complex' module will consist of the following classes that are now in the gt-app-schema module.

  • org.geotools.util.ComplexAttributeConverterFactoryorg.geotools.filter.expression.FeatureProperty + complete org.geotools.feature.xpath package
  • complete org.geotools.feature.type packagecomplete
  • org.geotools.feature package.Types
  • (PARTLY)
  • (PARTLY) + depending classes (for building types from xsd)

Considering the 'partly' ported classes.

  • AttributeBuilder - will still need an extended version in app-schema to support the NonFeatureTypeProxy which uses mappings
  • XPath - is just a class of different static methods that need to be split in two
  • FeatureTypeRegistry will be made more generic using a helper interface 'FeatureTypeRegistryHelper, app-schema can have its specific implementation