Re: [Geotools-devel] app-schema / complex features module
Yeah that is true... it needs the resolver for the schema stuff. App-schema-resolver is a bit of a misnomer because it also contains stuff that can be used independently of app-schema. It would actually make a lot of sense to me to put the complex stuff in the same package as the resolver. On 11/12/2012 06:07 PM, Justin Deoliveira wrote: Seems like a good amount of code. And does bring along a few dependencies as it seems. * xpp * app-schema-resolver So perhaps a new module is the way to go. But also would be fine with rolling it into one fo the existing modules. The second dependency is an interesting one. If this module is going to be factored out of app-schema perhaps so should the resolver as well.. although i know its already its own module seems a bit wierd to have the dependency back. -Justin On Mon, Nov 12, 2012 at 5:14 AM, Jody Garnett jody.garn...@gmail.com mailto:jody.garn...@gmail.com wrote: Hi Niels: You have identified one of the ideas I put together for this Friday's code sprint (http://wiki.osgeo.org/wiki/FOSS4G-AU_2012) - My motivation was to set up some base classes allowing for complex features to be processed - since as you point out there is very little available now. My preference would be to add the base classes to gt-data? -- Jody Garnett On Monday, 12 November 2012 at 9:35 PM, Niels Charlier wrote: Hi Ben and mailing list, I would like to propose that some of the stuff in the app-schema module gets taken out of the app-schema module, and move either in a new module or into an existing module. The issue I am dealing with now is that I need to use a bunch of stuff from app-schema that has to do with complex features in the CSW module, but it doesn't actually have anything to do with app-schema itself at all (application schema mappings etc). In particular - Creating complex feature types and features from scratch. - Certain parts of the feature type registry, in particular the creation of feature types from xsd schemas. - The complex feature property accessor, which makes it possible to retrieve properties from features with namespace qualified advanced x-paths in filters etc... In my view these things are really something separate from all the rest of the stuff that is used to support the application schema mappings specifically. Separating these concerns has a number of advantages: - A module like CSW can use these features without relying on a whole module of which most of the stuff really has nothing to do with it. - People can easily implement other implementations of complex feature stores or other things that use complex features without having to use app-schema. For now I have created a separate gt-complex module on my repository https://github.com/NielsCharlier/geotools branch csw, you can look at it for what I am going for. It contains mostly copies of app-schema classes, with the exception of the featuretyperegistry which has been made app-schema and gml independant, but in such a way that the app-schema specific featureregistry could easily be built on top of it. My preference would be to create a new module; because it has the advantage of the clarity. You would get all the complex stuff together (because they are spread among different existing packages and can't be put in one package) and it would be easy to adapt app-schema to use it. Thoughts/ideas? Kind Regards Niels Charlier -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net mailto:GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] app-schema / complex features module
On 14/11/12 21:35, Niels Charlier wrote: App-schema-resolver is a bit of a misnomer because it also contains stuff that can be used independently of app-schema. Well, app-schema-resolver is a resolver for application schemas. If anything is a misnomer, it is app-schema, which should be complex-features-mapped-from-simple-features-dataaccess, but I hate to type. ;-) It would actually make a lot of sense to me to put the complex stuff in the same package as the resolver. I am not so sure. app-schema-resolver is fairly small and knows nothing about geoapi. I like your original suggestion of a new module. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] app-schema / complex features module
On Tue, Nov 13, 2012 at 6:06 AM, adam.br...@csiro.au wrote: Hi Niels, et al., The work that I did in ComplexFeature Parsing and building support is located at https://github.com/Adam-Brown/geotools/tree/gml_client_lib. It includes a generic feature builder, a complex feature builder and an attribute builder which I put in gt-main. I also added XSDMapping and FeatureWrapper to gt-main - the idea of these is to help people define strongly-typed classes that they use with the complex feature parser. Does that mean that main ends up depending on gt-xsd-*? That is something I would not be very happy to see, not everybody needs to deal with EMF/XSD when working on GIS applications. Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] app-schema / complex features module
On Mon, Nov 12, 2012 at 12:35 PM, Niels Charlier ni...@scitus.be wrote: Hi Ben and mailing list, I would like to propose that some of the stuff in the app-schema module gets taken out of the app-schema module, and move either in a new module or into an existing module. The issue I am dealing with now is that I need to use a bunch of stuff from app-schema that has to do with complex features in the CSW module, but it doesn't actually have anything to do with app-schema itself at all (application schema mappings etc). In particular - Creating complex feature types and features from scratch. - Certain parts of the feature type registry, in particular the creation of feature types from xsd schemas. - The complex feature property accessor, which makes it possible to retrieve properties from features with namespace qualified advanced x-paths in filters etc... In my view these things are really something separate from all the rest of the stuff that is used to support the application schema mappings specifically. Separating these concerns has a number of advantages: - A module like CSW can use these features without relying on a whole module of which most of the stuff really has nothing to do with it. - People can easily implement other implementations of complex feature stores or other things that use complex features without having to use app-schema. I like the direction, this is very much needed to get complex features some life outside of the app-schema module Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] app-schema / complex features module
On 13/11/12 16:07, Andrea Aime wrote: On Tue, Nov 13, 2012 at 6:06 AM, adam.br...@csiro.au mailto:adam.br...@csiro.au wrote: The work that I did in ComplexFeature Parsing and building support is located at https://github.com/Adam-Brown/geotools/tree/gml_client_lib. It includes a generic feature builder, a complex feature builder and an attribute builder which I put in gt-main. I also added XSDMapping and FeatureWrapper to gt-main - the idea of these is to help people define strongly-typed classes that they use with the complex feature parser. Does that mean that main ends up depending on gt-xsd-*? That is something I would not be very happy to see, not everybody needs to deal with EMF/XSD when working on GIS applications. I believe avoiding this was a pretty strong design goal. Note also that gt-xsd-gml3 depends on gt-main, so Maven will helpfully choke on any attempt to make gt-main depend on gt-xsd-gml3 as it does not support circular dependencies. :-) Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] app-schema / complex features module
Hi Andrea, Sorry, I think my previous email might have been a bit misleading: XSDMapping is just an @interface whose only dependency is on java.lang.annotation.*. I put it in gt-main to keep it next to FeatureWrapper, with which I intend it to be used. Both of these files can be moved elsewhere if gt-main isn't appropriate for them? Thanks, Adam -Original Message- From: Caradoc-Davies, Ben (CESRE, Kensington) Sent: Wednesday, 14 November 2012 1:51 PM To: Andrea Aime Cc: Brown, Adam (CESRE, Kensington); Angreani, Rini (CESRE, Kensington); geotools-devel@lists.sourceforge.net Subject: Re: [Geotools-devel] app-schema / complex features module On 13/11/12 16:07, Andrea Aime wrote: On Tue, Nov 13, 2012 at 6:06 AM, adam.br...@csiro.au mailto:adam.br...@csiro.au wrote: The work that I did in ComplexFeature Parsing and building support is located at https://github.com/Adam-Brown/geotools/tree/gml_client_lib. It includes a generic feature builder, a complex feature builder and an attribute builder which I put in gt-main. I also added XSDMapping and FeatureWrapper to gt-main - the idea of these is to help people define strongly-typed classes that they use with the complex feature parser. Does that mean that main ends up depending on gt-xsd-*? That is something I would not be very happy to see, not everybody needs to deal with EMF/XSD when working on GIS applications. I believe avoiding this was a pretty strong design goal. Note also that gt-xsd-gml3 depends on gt-main, so Maven will helpfully choke on any attempt to make gt-main depend on gt-xsd-gml3 as it does not support circular dependencies. :-) Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] app-schema / complex features module
Hi Ben and mailing list, I would like to propose that some of the stuff in the app-schema module gets taken out of the app-schema module, and move either in a new module or into an existing module. The issue I am dealing with now is that I need to use a bunch of stuff from app-schema that has to do with complex features in the CSW module, but it doesn't actually have anything to do with app-schema itself at all (application schema mappings etc). In particular - Creating complex feature types and features from scratch. - Certain parts of the feature type registry, in particular the creation of feature types from xsd schemas. - The complex feature property accessor, which makes it possible to retrieve properties from features with namespace qualified advanced x-paths in filters etc... In my view these things are really something separate from all the rest of the stuff that is used to support the application schema mappings specifically. Separating these concerns has a number of advantages: - A module like CSW can use these features without relying on a whole module of which most of the stuff really has nothing to do with it. - People can easily implement other implementations of complex feature stores or other things that use complex features without having to use app-schema. For now I have created a separate gt-complex module on my repository https://github.com/NielsCharlier/geotools branch csw, you can look at it for what I am going for. It contains mostly copies of app-schema classes, with the exception of the featuretyperegistry which has been made app-schema and gml independant, but in such a way that the app-schema specific featureregistry could easily be built on top of it. My preference would be to create a new module; because it has the advantage of the clarity. You would get all the complex stuff together (because they are spread among different existing packages and can't be put in one package) and it would be easy to adapt app-schema to use it. Thoughts/ideas? Kind Regards Niels Charlier -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] app-schema / complex features module
Hi Niels: You have identified one of the ideas I put together for this Friday's code sprint (http://wiki.osgeo.org/wiki/FOSS4G-AU_2012) - My motivation was to set up some base classes allowing for complex features to be processed - since as you point out there is very little available now. My preference would be to add the base classes to gt-data? -- Jody Garnett On Monday, 12 November 2012 at 9:35 PM, Niels Charlier wrote: Hi Ben and mailing list, I would like to propose that some of the stuff in the app-schema module gets taken out of the app-schema module, and move either in a new module or into an existing module. The issue I am dealing with now is that I need to use a bunch of stuff from app-schema that has to do with complex features in the CSW module, but it doesn't actually have anything to do with app-schema itself at all (application schema mappings etc). In particular - Creating complex feature types and features from scratch. - Certain parts of the feature type registry, in particular the creation of feature types from xsd schemas. - The complex feature property accessor, which makes it possible to retrieve properties from features with namespace qualified advanced x-paths in filters etc... In my view these things are really something separate from all the rest of the stuff that is used to support the application schema mappings specifically. Separating these concerns has a number of advantages: - A module like CSW can use these features without relying on a whole module of which most of the stuff really has nothing to do with it. - People can easily implement other implementations of complex feature stores or other things that use complex features without having to use app-schema. For now I have created a separate gt-complex module on my repository https://github.com/NielsCharlier/geotools branch csw, you can look at it for what I am going for. It contains mostly copies of app-schema classes, with the exception of the featuretyperegistry which has been made app-schema and gml independant, but in such a way that the app-schema specific featureregistry could easily be built on top of it. My preference would be to create a new module; because it has the advantage of the clarity. You would get all the complex stuff together (because they are spread among different existing packages and can't be put in one package) and it would be easy to adapt app-schema to use it. Thoughts/ideas? Kind Regards Niels Charlier -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net (mailto:GeoTools-Devel@lists.sourceforge.net) https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] app-schema / complex features module
Seems like a good amount of code. And does bring along a few dependencies as it seems. * xpp * app-schema-resolver So perhaps a new module is the way to go. But also would be fine with rolling it into one fo the existing modules. The second dependency is an interesting one. If this module is going to be factored out of app-schema perhaps so should the resolver as well.. although i know its already its own module seems a bit wierd to have the dependency back. -Justin On Mon, Nov 12, 2012 at 5:14 AM, Jody Garnett jody.garn...@gmail.comwrote: Hi Niels: You have identified one of the ideas I put together for this Friday's code sprint (http://wiki.osgeo.org/wiki/FOSS4G-AU_2012) - My motivation was to set up some base classes allowing for complex features to be processed - since as you point out there is very little available now. My preference would be to add the base classes to gt-data? -- Jody Garnett On Monday, 12 November 2012 at 9:35 PM, Niels Charlier wrote: Hi Ben and mailing list, I would like to propose that some of the stuff in the app-schema module gets taken out of the app-schema module, and move either in a new module or into an existing module. The issue I am dealing with now is that I need to use a bunch of stuff from app-schema that has to do with complex features in the CSW module, but it doesn't actually have anything to do with app-schema itself at all (application schema mappings etc). In particular - Creating complex feature types and features from scratch. - Certain parts of the feature type registry, in particular the creation of feature types from xsd schemas. - The complex feature property accessor, which makes it possible to retrieve properties from features with namespace qualified advanced x-paths in filters etc... In my view these things are really something separate from all the rest of the stuff that is used to support the application schema mappings specifically. Separating these concerns has a number of advantages: - A module like CSW can use these features without relying on a whole module of which most of the stuff really has nothing to do with it. - People can easily implement other implementations of complex feature stores or other things that use complex features without having to use app-schema. For now I have created a separate gt-complex module on my repository https://github.com/NielsCharlier/geotools branch csw, you can look at it for what I am going for. It contains mostly copies of app-schema classes, with the exception of the featuretyperegistry which has been made app-schema and gml independant, but in such a way that the app-schema specific featureregistry could easily be built on top of it. My preference would be to create a new module; because it has the advantage of the clarity. You would get all the complex stuff together (because they are spread among different existing packages and can't be put in one package) and it would be easy to adapt app-schema to use it. Thoughts/ideas? Kind Regards Niels Charlier -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] app-schema / complex features module
Niels, that sounds great! What is the overlap with Adam Brown's complex builders in his ComplexFeature Parsing and Building Support proposal: http://docs.codehaus.org/display/GEOTOOLS/ComplexFeature+Parsing+and+Building+Support I think this is still resting in a branch in Adam's github repo. See yesterday's committee meeting notes: Reference point: Andrea had to make layers of builders in order to use this kind of setup for CSW (ebRIM record, CSW record). Used Adam's Builder, and then builders on top of that domains specific. Adam? The long-term goal should be to break-out all the complex builders into gt-main (or gt-complex if not possible) and then refactor everything (including gt-app-schema) to use them. And have great API user documentation and example. Kind regards, Ben. On 12/11/12 19:35, Niels Charlier wrote: Hi Ben and mailing list, I would like to propose that some of the stuff in the app-schema module gets taken out of the app-schema module, and move either in a new module or into an existing module. The issue I am dealing with now is that I need to use a bunch of stuff from app-schema that has to do with complex features in the CSW module, but it doesn't actually have anything to do with app-schema itself at all (application schema mappings etc). In particular - Creating complex feature types and features from scratch. - Certain parts of the feature type registry, in particular the creation of feature types from xsd schemas. - The complex feature property accessor, which makes it possible to retrieve properties from features with namespace qualified advanced x-paths in filters etc... In my view these things are really something separate from all the rest of the stuff that is used to support the application schema mappings specifically. Separating these concerns has a number of advantages: - A module like CSW can use these features without relying on a whole module of which most of the stuff really has nothing to do with it. - People can easily implement other implementations of complex feature stores or other things that use complex features without having to use app-schema. For now I have created a separate gt-complex module on my repository https://github.com/NielsCharlier/geotools branch csw, you can look at it for what I am going for. It contains mostly copies of app-schema classes, with the exception of the featuretyperegistry which has been made app-schema and gml independant, but in such a way that the app-schema specific featureregistry could easily be built on top of it. My preference would be to create a new module; because it has the advantage of the clarity. You would get all the complex stuff together (because they are spread among different existing packages and can't be put in one package) and it would be easy to adapt app-schema to use it. Thoughts/ideas? Kind Regards Niels Charlier -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] app-schema / complex features module
Hi Niels, et al., The work that I did in ComplexFeature Parsing and building support is located at https://github.com/Adam-Brown/geotools/tree/gml_client_lib. It includes a generic feature builder, a complex feature builder and an attribute builder which I put in gt-main. I also added XSDMapping and FeatureWrapper to gt-main - the idea of these is to help people define strongly-typed classes that they use with the complex feature parser. There are a bunch of other changes in gt-wfs-ng around parsing complex features but I suspect that they are already in the right place? Cheers, Adam -Original Message- From: Caradoc-Davies, Ben (CESRE, Kensington) Sent: Tuesday, 13 November 2012 11:54 AM To: Niels Charlier Cc: Justin Deoliveira; geotools-devel@lists.sourceforge.net; Angreani, Rini (CESRE, Kensington); Brown, Adam (CESRE, Kensington) Subject: Re: app-schema / complex features module Niels, that sounds great! What is the overlap with Adam Brown's complex builders in his ComplexFeature Parsing and Building Support proposal: http://docs.codehaus.org/display/GEOTOOLS/ComplexFeature+Parsing+and+Building+Support I think this is still resting in a branch in Adam's github repo. See yesterday's committee meeting notes: Reference point: Andrea had to make layers of builders in order to use this kind of setup for CSW (ebRIM record, CSW record). Used Adam's Builder, and then builders on top of that domains specific. Adam? The long-term goal should be to break-out all the complex builders into gt-main (or gt-complex if not possible) and then refactor everything (including gt-app-schema) to use them. And have great API user documentation and example. Kind regards, Ben. On 12/11/12 19:35, Niels Charlier wrote: Hi Ben and mailing list, I would like to propose that some of the stuff in the app-schema module gets taken out of the app-schema module, and move either in a new module or into an existing module. The issue I am dealing with now is that I need to use a bunch of stuff from app-schema that has to do with complex features in the CSW module, but it doesn't actually have anything to do with app-schema itself at all (application schema mappings etc). In particular - Creating complex feature types and features from scratch. - Certain parts of the feature type registry, in particular the creation of feature types from xsd schemas. - The complex feature property accessor, which makes it possible to retrieve properties from features with namespace qualified advanced x-paths in filters etc... In my view these things are really something separate from all the rest of the stuff that is used to support the application schema mappings specifically. Separating these concerns has a number of advantages: - A module like CSW can use these features without relying on a whole module of which most of the stuff really has nothing to do with it. - People can easily implement other implementations of complex feature stores or other things that use complex features without having to use app-schema. For now I have created a separate gt-complex module on my repository https://github.com/NielsCharlier/geotools branch csw, you can look at it for what I am going for. It contains mostly copies of app-schema classes, with the exception of the featuretyperegistry which has been made app-schema and gml independant, but in such a way that the app-schema specific featureregistry could easily be built on top of it. My preference would be to create a new module; because it has the advantage of the clarity. You would get all the complex stuff together (because they are spread among different existing packages and can't be put in one package) and it would be easy to adapt app-schema to use it. Thoughts/ideas? Kind Regards Niels Charlier -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
