On Sun, Feb 18, 2018 at 1:34 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> On Sun, Feb 18, 2018 at 1:28 PM, Bernd Eckenfels <e...@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 >> >> >
