Hi Roar,
I think no one has picked up this review, right?
If that's the case, let me suggest an approach that should be acceptable
without requiring extra people to chime in:
- Check out master, run the wfs-ng tests with "-Ponline" activated,
e.g., "mvn clean install -Ponline". Note down wh
Hi Andrea,
You have a point about my changes in the tests for gt-wfs-ng. I got a little
bit carried away by changing the way TestWFSClient are created. I do believe
that I haven't changed any fundamentally, and the tests runs successfully. It
could perhaps be a point that someone with knowledge
Hi all,
Roar applied the feedback received so far. Wondering if the proposal needs
any update as a consequence? (does not look like, but want to be sure)
https://github.com/geotools/geotools/wiki/HTTPClient-Factory
Also, the PR changes lots of files, but the majority are package changes
for the ht
Hi,
I tried your suggestion to extend the old interfaces. Everything compiles and
seems to work fine, but GitHub Job Linux GitHub CI -> QA fails because of some
warnings for usage of deprecated classes. How can I avoid those warnings?
Here is one of the line it complines about:
public interface
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
Thanks,
I think you've nailed the main goal by the proposal. I did some change to the
code example though.
It would have been great to land this PR, and work with some of the bugs
regarding HTTPClient.
Regards,
Roar Brænden
> 4. jan. 2021 kl. 21:49 skrev Jody Garnett :
>
> I outlined the
I outlined the proposal here
https://github.com/geotools/geotools/wiki/HTTPClient-Factory
I will ask for a review in tomorrow's meeting and trust we can get this
done ahead of the next release.
--
Jody Garnett
On Wed, 23 Dec 2020 at 16:15, Roar Brænden
wrote:
> Hi,
>
> I'm aware that you have
Oh that is great. The tile code was ported from another project I worked
on.
On Wed, Dec 23, 2020 at 4:15 PM Roar Brænden
wrote:
> Hi,
>
> I'm aware that you have a way of doing things, and that my approach wasn't
> in accordance with that. The history is that I worked with gt-tile-client
> thi
Hi,
I'm aware that you have a way of doing things, and that my approach wasn't in
accordance with that. The history is that I worked with gt-tile-client this
autumn and tried to make it work in parallel while fetching tiles. While
looking at this I saw that all too many classes of Geotools take
Roar:
As you may have noticed in the meeting notes your HTTPClient ideas were
discussed. As it has grown in the telling I agreed to write this up as a
proposal for the community (it is how we do design documents and make sure
everyone is in agreement on "big" or "impactful" changes.
Before I get
12 matches
Mail list logo
