Thinking that through because of Java 11 package limitations they
gt-http would end up working in a new package:
package org.geotools.data.http;
interface HTTPClient {
...
}
And main would end up with some deprecations for a release cycle:
package org.geotools.data.ows;
/**
* @deprecat
Hi,
I've seen other mention not to use CommonFactoryFinder, and that would be easy
to avoid. Moving the interfaces HTTPClient and HTTPResponse into gt-http means
that all the classes in the namespace org.geotools.data.ows must be taken into
gt-http. It seems easy to implement this.
Initially I
Perfect, the proposal is starting to collect votes.
I had one thing to discuss, use of CommonFactoryFinder? It would be great
if use of this module can be independent of main, this would require
its own own HTTPFactoryFinder or similar.
--
Jody Garnett
On Mon, 4 Jan 2021 at 14:30, Roar Brænden
GeoTools / GeoServer PMC meeting - 2021-01-05Attending
Actions from last meeting:
-
[DONE] Jody: Start email PSC vote this year to pay out of our 2020
budget for CITE test contract, and then send authorization to treasurer
when work is complete
-
[DONE] Jody: Will write it up a
Hi Jody,
+1 for removing it
Cheers
Andrea
On Mon, Jan 4, 2021 at 7:38 PM Jody Garnett wrote:
> While reviewing Andrea's junit 3 --> 4 PR, I was once again struck by how
> stale the validation extension is, I believe it has been over ten years
> since this was used by geoserver or udig and can
