Well, since we have only positive votes, I prepared the pull request:
https://github.com/geotools/geotools/pull/142
Thanks.
Mauro Bartolomeoli
2013/3/1 Andrea Aime andrea.a...@geo-solutions.it
On Fri, Mar 1, 2013 at 4:43 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
The one
On Mon, Mar 4, 2013 at 10:21 AM, Mauro Bartolomeoli
mauro.bartolome...@geo-solutions.it wrote:
Well, since we have only positive votes, I prepared the pull request:
https://github.com/geotools/geotools/pull/142
Given there was no negative feedback I've merged the patch right away, if
it
On Fri, Mar 1, 2013 at 4:43 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
The one question mark I have is that, because this patch adds a new
dependency, xml-commons-resolver, is it backwards compatible? This might
break builds of users who have manually collected dependencies and
Hi everybody,
as 8.7 release is finally out, could this be a good moment to merge
SchemaResolver patch to 8.x branch?
Just to remember a few things:
* this is the branch to merge:
https://github.com/mbarto/geotools/tree/8.x_geot_4386
* the patch should be quite safe as it mantains code
The one question mark I have is that, because this patch adds a new
dependency, xml-commons-resolver, is it backwards compatible? This might
break builds of users who have manually collected dependencies and are
not using Maven. Do we support these users? Does a new non-test
dependency count
Hi guys.
I prepared the backporting for 8.x here:
https://github.com/mbarto/geotools/tree/8.x_geot_4386
I followed the schema announced yesterday of extending app-schema-resolver
classes from gt-xml ones to mantain code compatibility.
Any obstacle to apply this backporting to 8.x soon (maybe
2013/2/20 Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
+1. That is a good idea. Because the added classes have new names and a
new package, this change is a pure API extension and localised to GeoTools.
This change should wait until after the next beta, and will need support
(and perhaps a
Hi,
I would like to ask opinions for the backporting of the GEOT-4386 patch to
8.x and 9.x branches that has just landed on master.
My thought for the backport would be to mantain compatibility with
existing code, simply avoiding to remove classes in app-schema-resolver,
but letting them extend
+1. That is a good idea. Because the added classes have new names and a
new package, this change is a pure API extension and localised to
GeoTools. This change should wait until after the next beta, and will
need support (and perhaps a vote?).
Note that 8.x is almost obsolete as 9.0 is in beta
