On Fri, 2019-12-13 at 15:04 -0800, Ryan Schmitt wrote:
> I don't think core is special in this regard, but I *do* think it is
> special in having a separate release cycle. Most Java projects these
> days
> use version alignment (and usually a unified repository as well),
> despite
> featuring many distinct components that all move at different speeds.
> Examples include:
>
> - Log4j2 (api, core, four logging bridges, many many appenders...)
> - JUnit 5 (platform commons, Jupiter API, Jupiter engine, vintage
> engine,
> Jupiter params support, platform runner...)
> - Jackson (annotations, core, databind, dataformat, datatype, jaxrs,
> Kotlin/scala support...)
> - Netty (common, buffer, codec, resolver, transport, native libs,
> numerous
> protocols and data formats...)
> - AWS SDK for Java (*over a hundred* separate service SDKs, multiple
> HTTP
> clients, SPI, code generators, SDK core...)
>
> Under this approach, there is a clear benefit to the user of only
> having to
> track one version number, no matter how many components are pulled
> in.
> Currently, httpclient5 works quite the other way: users must add
> dependencies on both httpcore5 and httpclient5 as a matter of course,
> and
> must model both versions explicitly: this is the only way to be sure
> that
> they are getting the latest versions of both components.
>
I am not sure I can agree with that. Usually one should care about the
top level library such as HttpClient or HttpAsyncClient only. One needs
to manually override their HttpCore dependency only in case of some
severe bug in core components.
Ultimately this is a blond vs brunette type of debate. While a lot of
fun I doubt it can have an ultimate resolution.
Oleg
PS: One thing I cannot fully understand is why you chose to use
httpclient5 for AWS SDK in the initial iteration. I suppose
HttpAsyncRequester shipped with httpcore5 would be perfectly adequate
initially. Once all low level transport issues are worked out you could
upgrade to httpclient5 and replace HttpAsyncRequester with
HttpAsyncClient with little effort.
> I also think that the projects listed above make it clear that
> dependency
> alignment scales to a much larger number of components than we have
> currently, and adopting it does not foreclose the possibility of
> developing
> new httpcomponents in the future.
>
> On Fri, Dec 13, 2019 at 1:57 PM Oleg Kalnichevski <[email protected]>
> wrote:
>
> > I understand it can be frustrating while core APIs are not stable
> > but core and client components tend to have different maturity
> > cycles
> > and therefore having distinct release cycles for core and client
> > components is beneficial. In HC 4.x we can make fixes to core
> > components and release them fast while some client features are
> > still
> > being worked on and are not ready for a release.
> >
> > We might also have a reverse-proxy or a more feature rich server
> > sub-
> > projects at some point. Coupling core with client would make it
> > much
> > harder and would necessitate a separate core project again at that
> > point.
> >
> > Unless we decide we only develop HttpClient and nothing else, which
> > is
> > fine by me as long as this is what we all want.
> >
> > Oleg
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
