Mauro, I think your changes are just what we need. Please also update your branch to remove the duplication in gt-app-schema-resolver, so that it contains only those things that depend on gt-xsd-core and so cannot be folded into gt-xml.
One other issue is synchronisation: gt-app-schema-resolver has until now only been used in circumstances (GeoServer startup) in which concurrent access is not an issue. What happens if two concurrent threads try to use the resolver? One thread might read a copy on disk while another is still downloading it. Simple synchronisation might result in nasty starvation if a download hangs. Core code must consider these issues and either address them or state that the code is not thread safe. Please also ensure that the relevant attributions are copied to gt-xml: modules/extension/app-schema/app-schema-resolver/src/site/apt/review.apt I also note a new copy of XMLSchema.xsd which will require attribution. As Justin is the maintainer of gt-xml, all changes there will require his approval. There is also an ugly, ugly hack in AppSchemaResolver: if a cache directory is not set, it can be configured to automatically find one if it recognises a *GeoServer* data directory. Ugly, but very useful, and I have not thought of a better way of doing it (a data store parameter, perhaps?). The standard for core is higher than extension; Justin may want this either fixed or factored out into a subclass in gt-app-schema-resolver so that he does not have to maintain any (more) ugly hacks. :-) Justin? Kind regards, Ben. On 11/02/13 21:31, Mauro Bartolomeoli wrote: > Hi guys, > I created a new branch ( > https://github.com/mbarto/geotools/tree/geot_4386_no_app_schema_resolver > ) that removes app-schema-resolver dependencies, basically porting 3 > classes (AppSchemaResolver, AppSchemaCache and AppSchemaCatalog) > directly into the gt-xml module. > The next step would be to let app-schema-resolver depend on these to > remove the duplication. > Let me know if we can proceed this way. > > Thanks. > Mauro Bartolomeoli > > > 2013/2/7 Mauro Bartolomeoli <mauro.bartolome...@geo-solutions.it > <mailto:mauro.bartolome...@geo-solutions.it>> > > > > > 2013/2/7 Justin Deoliveira <jdeol...@opengeo.org > <mailto:jdeol...@opengeo.org>> > > @Mauro: I am not sure it makes sense to have a library module > depend on an extension module. Maybe we can shuffle a few things > around to make this cleaner. > > @Ben: What about moving the classes from app-schema-resolver > that don't depend on xsd-core, like the core entity resolver > classes, to library/xml? > > > I agree with both sentences. > > I think the app-schema-resolver stuff could be easily become a > generic schema-resolver, useful for xml schema resolving and caching > in general. > > Thanks. > Mauro Bartolomeoli > > > > > -- > == > Our support, Your Success! Visit http://opensdi.geo-solutions.it for > more information. > == > > Dott. Mauro Bartolomeoli > @mauro_bart > Senior Software Engineer > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > phone: +39 0584 962313 > fax: +39 0584 1660272 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > ------------------------------------------------------- -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
