You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2018/02/18 20:21:18 UTC
[VFS] HttpClient version 3, 4 and 5
Hi All,
Our HTTP provider org.apache.commons.vfs2.provider.http still uses Apache
HttpClient 3.1.
Some of these classes surface the HttpClient class from 3.1 in APIs marked
public.
Looking forward to HttpClient 4 and 5-Alpha/Beta, I wonder how to move
forward.
We could:
- Create a new package org.apache.commons.vfs2.provider.http4, or
- Break BC on the classes in org.apache.commons.vfs2.provider.http
Thoughts?
Gary
Re: [VFS] HttpClient version 3, 4 and 5
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Sun, Feb 18, 2018 at 9:21 PM, Gary Gregory <ga...@gmail.com> wrote:
> - Create a new package org.apache.commons.vfs2.provider.http4, or
> - Break BC on the classes in org.apache.commons.vfs2.provider.http
Break BC, and do it right: Don't expose HttpClient in the API.
Emphasis being on the second part.
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] HttpClient version 3, 4 and 5
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Feb 18, 2018 at 1:34 PM, Gary Gregory <ga...@gmail.com>
wrote:
> On Sun, Feb 18, 2018 at 1:28 PM, Bernd Eckenfels <ec...@zusammenkunft.net>
> wrote:
>
>> If we want to do a minor update (2.3) we should not introduce new Major
>> dependencies (unless optional), so having a http4 package and an optional
>> dependency on http3+http4 sounds like the better solution.
>>
>
> I am more concerned about not breaking BC in a non-major release. It's
> just was not clear to me if a _provider's_ API is part of the public
> Commons VFS API. I suppose that it is since the options builder provide
> features that would otherwise not be available.
>
> This tells me that we should introduce an http4, then an http5 package
> within the VFS 2.x release line, if I ever get around to it that is.
>
I would also be reasonable to breakup VFS into one module per provider to
avoid using optional dependencies. It might even be possible to do this
within the 2.x release line as long we do not need to change any Java
packages. I am setting aside dealing with Java 9 module names for this
discussion.
Gary
>
> Gary
>
>
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>>
>> Von: Gary Gregory
>> Gesendet: Sonntag, 18. Februar 2018 21:21
>> An: Commons Developers List
>> Betreff: [VFS] HttpClient version 3, 4 and 5
>>
>> Hi All,
>>
>> Our HTTP provider org.apache.commons.vfs2.provider.http still uses Apache
>> HttpClient 3.1.
>>
>> Some of these classes surface the HttpClient class from 3.1 in APIs marked
>> public.
>>
>> Looking forward to HttpClient 4 and 5-Alpha/Beta, I wonder how to move
>> forward.
>>
>> We could:
>>
>> - Create a new package org.apache.commons.vfs2.provider.http4, or
>> - Break BC on the classes in org.apache.commons.vfs2.provider.http
>>
>> Thoughts?
>>
>> Gary
>>
>>
>
Re: [VFS] HttpClient version 3, 4 and 5
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Feb 18, 2018 at 1:28 PM, Bernd Eckenfels <ec...@zusammenkunft.net>
wrote:
> If we want to do a minor update (2.3) we should not introduce new Major
> dependencies (unless optional), so having a http4 package and an optional
> dependency on http3+http4 sounds like the better solution.
>
I am more concerned about not breaking BC in a non-major release. It's just
was not clear to me if a _provider's_ API is part of the public Commons VFS
API. I suppose that it is since the options builder provide features that
would otherwise not be available.
This tells me that we should introduce an http4, then an http5 package
within the VFS 2.x release line, if I ever get around to it that is.
Gary
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> Von: Gary Gregory
> Gesendet: Sonntag, 18. Februar 2018 21:21
> An: Commons Developers List
> Betreff: [VFS] HttpClient version 3, 4 and 5
>
> Hi All,
>
> Our HTTP provider org.apache.commons.vfs2.provider.http still uses Apache
> HttpClient 3.1.
>
> Some of these classes surface the HttpClient class from 3.1 in APIs marked
> public.
>
> Looking forward to HttpClient 4 and 5-Alpha/Beta, I wonder how to move
> forward.
>
> We could:
>
> - Create a new package org.apache.commons.vfs2.provider.http4, or
> - Break BC on the classes in org.apache.commons.vfs2.provider.http
>
> Thoughts?
>
> Gary
>
>
Re: [VFS] HttpClient version 3, 4 and 5
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
If we want to do a minor update (2.3) we should not introduce new Major dependencies (unless optional), so having a http4 package and an optional dependency on http3+http4 sounds like the better solution.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Gary Gregory
Gesendet: Sonntag, 18. Februar 2018 21:21
An: Commons Developers List
Betreff: [VFS] HttpClient version 3, 4 and 5
Hi All,
Our HTTP provider org.apache.commons.vfs2.provider.http still uses Apache
HttpClient 3.1.
Some of these classes surface the HttpClient class from 3.1 in APIs marked
public.
Looking forward to HttpClient 4 and 5-Alpha/Beta, I wonder how to move
forward.
We could:
- Create a new package org.apache.commons.vfs2.provider.http4, or
- Break BC on the classes in org.apache.commons.vfs2.provider.http
Thoughts?
Gary