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 HTTPClient extends org.geotools.data.ows.HTTPClient {

Here is the warnings from the log:
[INFO] Compiling 25 source files to 
/home/runner/work/geotools/geotools/modules/library/http/target/classes
5440
 
<https://github.com/geotools/geotools/runs/1662859692?check_suite_focus=true#step:5:5440>[INFO]
 -------------------------------------------------------------
5441
 
<https://github.com/geotools/geotools/runs/1662859692?check_suite_focus=true#step:5:5441>Warning:
  COMPILATION WARNING : 
5442
 
<https://github.com/geotools/geotools/runs/1662859692?check_suite_focus=true#step:5:5442>[INFO]
 -------------------------------------------------------------
5445
 
<https://github.com/geotools/geotools/runs/1662859692?check_suite_focus=true#step:5:5445>Warning:
  
/home/runner/work/geotools/geotools/modules/library/http/src/main/java/org/geotools/http/HTTPClient.java:[32,58]
 org.geotools.data.ows.HTTPClient in org.geotools.data.ows has been deprecated
5446
 
<https://github.com/geotools/geotools/runs/1662859692?check_suite_focus=true#step:5:5446>Warning:
  
/home/runner/work/geotools/geotools/modules/library/http/src/main/java/org/geotools/http/HTTPResponse.java:[34,60]
 org.geotools.data.ows.HTTPResponse in org.geotools.data.ows has been deprecated


And here is a link to the specific run:
https://github.com/geotools/geotools/runs/1662859692?check_suite_focus=true 
<https://github.com/geotools/geotools/runs/1662859692?check_suite_focus=true>

Regards,

Roar Brænden


> 6. jan. 2021 kl. 00:06 skrev Jody Garnett <jody.garn...@gmail.com>:
> 
> 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;
> /**
>  * @deprecated Please use org.geotools.data.http.HTTPClient
>  */
> interface HTTPClient extends org.geotools.data.http.HTTPClient {
>    ...
> }
> 
> That can work :)
> --
> Jody Garnett
> 
> 
> On Tue, 5 Jan 2021 at 14:43, Roar Brænden <roar.brenden...@gmail.com 
> <mailto:roar.brenden...@gmail.com>> wrote:
> 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 was thinking about moving all that only has to do with HTTP into 
> the namespace org.geotools.http. It ended up being a too broad change. What 
> do you all mean. Would it make sense to do such a refactoring?
> 
> The classes I consider is:
> 
> DelegateHTTPClient
> DelegateHTTPResponse
> HTTPClient
> HTTPResponse
> LoggingHTTPClient
> SimpleHttpClient
> 
> Regards,
> 
> Roar Brænden
> 
>> 5. jan. 2021 kl. 21:55 skrev Jody Garnett <jody.garn...@gmail.com 
>> <mailto:jody.garn...@gmail.com>>:
>> 
>> 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 <roar.brenden...@gmail.com 
>> <mailto:roar.brenden...@gmail.com>> wrote:
>> 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 <jody.garn...@gmail.com 
>>> <mailto:jody.garn...@gmail.com>>:
>>> 
>>> I outlined the proposal here 
>>> https://github.com/geotools/geotools/wiki/HTTPClient-Factory 
>>> <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 <roar.brenden...@gmail.com 
>>> <mailto:roar.brenden...@gmail.com>> 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 
>>> 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 
>>> HTTPClient as an argument for the constructor, rather than using a factory 
>>> pattern. And that's strange cause elsewhere you are using factory patterns 
>>> a lot.
>>> 
>>> 
>>> > 23. des. 2020 kl. 23:46 skrev Jody Garnett <jody.garn...@gmail.com 
>>> > <mailto:jody.garn...@gmail.com>>:
>>> > 
>>> > 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 going what is your feeling between "gt-http" and "gt-web"?
>>> > --
>>> 
>>> 
>>> I would prefer to use http, as web is too wide.
>>> For the moment I have these two projects in the file structure:
>>> 
>>> library / http (gt-http)
>>> plugin / http-commons (gt-http-commons)
>>> 
>>> 
>>> Regards
>>> 
>>> Roar Brænden
>> 
> 

_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to