Hi all, I tried to solve the remaining issues.
Please update the javadocs in gt-app-schema-resolver and the user manual,
which still mention the old class names. You should probably move the
resolver section in the manual to xml, or wherever you think it makes most
sense. for your convenience,
Mauro,
that looks great. Both GeoTools and GeoServer (patched branch) build
cleanly. The docs build and look fine.
The only question I have is: why is it necessary to synchronise the
block where resolvedLocationToOriginalLocationMap.put is called, when
this is already a ConcurrentHashMap? (I
2013/2/14 Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Nice work, Mauro. You are getting closer.
Thanks, it's a hard work, but someone had to do it :-)
There are still some issues to be addressed.
The good news is that all tests pass (including SchemaCacheOnlineTest,
which requires
Hi guys, I tried to integrate all your suggestions with a new commit on
this branch:
https://github.com/mbarto/geotools/tree/geot_4386_no_app_schema_resolver.
Basically what I did is:
* removed classes migrated to gt-xml (SchemaResolver, SchemaCache and
SchemaCatalog) from app-schema-resolver,
Nice work, Mauro. You are getting closer.
There are still some issues to be addressed.
The good news is that all tests pass (including SchemaCacheOnlineTest,
which requires ~/.geotools/schema-resolver.properties to enable it).
Furthermore, I have made the changes required in GeoServer in a
Looking good Mauro.
One last question though about dependencies. I notice that gt-xml still
depends on the geosciml schemas. Is this necessary? IDeally this dependency
could remain in app-schema specific modules where it is needed.
More comments below.
On Mon, Feb 11, 2013 at 8:13 PM, Ben
2013/2/12 Justin Deoliveira jdeol...@opengeo.org
Looking good Mauro.
One last question though about dependencies. I notice that gt-xml still
depends on the geosciml schemas. Is this necessary? IDeally this dependency
could remain in app-schema specific modules where it is needed.
The
On Tue, Feb 12, 2013 at 7:34 AM, Mauro Bartolomeoli
mauro.bartolome...@geo-solutions.it wrote:
2013/2/12 Justin Deoliveira jdeol...@opengeo.org
Looking good Mauro.
One last question though about dependencies. I notice that gt-xml still
depends on the geosciml schemas. Is this necessary?
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
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:
@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
2013/2/7 Justin Deoliveira 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
2013/2/6 Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
app-schema uses the app-schema-resolver implementation to obtain schemas
from the classpath (jar files), oasis calogs, or cached downloads. It is
designed to drive the XML encoder, and solve the problem of cross-module
relative imports
Wow, that sounds great, Mauro.
Making gt-app-schema-resolver a dependency of gt-xml will require
promoting gt-app-schema-resolver to core; this is a large change and
will require Justin's approval (as resident xml guru), discussion on the
lists, and a change proposal. Are you sure you cannot
Hi all,
I'm trying to solve a bug with the GeoTools WMS client, that when
contacting a GeoServer service with inspire extensions enabled, throws
exception and it's very slow to complete the GetCapabilities request.
This is very annoing because it prevents use of this type of services with
the
On Tue, Feb 5, 2013 at 12:43 PM, Mauro Bartolomeoli
mauro.bartolome...@geo-solutions.it wrote:
I have two options:
* simplest one: SchemaFactory looks in classpath for schemas.properties
files containing uri - localpath bindings used for preloading and caching
schemas. The content of
I wonder if a third alternative would be to utilize the URIResolver apis
already present in the jdk. If I am not mistaken the app-schema folks use
this to solive this same problem. Maybe Ben or Rini can comment on that.
At what point are the schemas downloaded? Are they done by the underlying
xml
Il giorno 05/feb/2013 16:39, Justin Deoliveira jdeol...@opengeo.org ha
scritto:
I wonder if a third alternative would be to utilize the URIResolver apis
already present in the jdk. If I am not mistaken the app-schema folks use
this to solive this same problem. Maybe Ben or Rini can comment on
Il giorno 05/feb/2013 16:39, Justin Deoliveira jdeol...@opengeo.org ha
scritto:
I wonder if a third alternative would be to utilize the URIResolver apis
already present in the jdk. If I am not mistaken the app-schema folks use
this to solive this same problem. Maybe Ben or Rini can comment on
app-schema uses the app-schema-resolver implementation to obtain schemas
from the classpath (jar files), oasis calogs, or cached downloads. It is
designed to drive the XML encoder, and solve the problem of cross-module
relative imports (import of ../../../whatever) from different sources.
It
20 matches
Mail list logo
