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 c
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 conveni
2013/2/14 Ben Caradoc-Davies
> 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 ~/.geotools/schema-resol
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 bra
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, in
On Tue, Feb 12, 2013 at 7:34 AM, Mauro Bartolomeoli <
mauro.bartolome...@geo-solutions.it> wrote:
>
>
>
> 2013/2/12 Justin Deoliveira
>
>> Looking good Mauro.
>>
>> One last question though about dependencies. I notice that gt-xml still
>> depends on the geosciml schemas. Is this necessary? IDeal
2013/2/12 Justin Deoliveira
> 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 dependency was intr
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 Carado
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-resolve
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
2013/2/7 Justin Deoliveira
> @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 c
@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/
2013/2/7 Ben Caradoc-Davies
> 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 chang
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 ma
2013/2/6 Ben Caradoc-Davies
> 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 ../../../whate
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 do
Il giorno 05/feb/2013 16:39, "Justin Deoliveira" 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 that.
>
> At what p
Il giorno 05/feb/2013 16:39, "Justin Deoliveira" 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 that.
>
> At what p
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
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
20 matches
Mail list logo
