I have a few thoughts here, with the TL;DR that I like the idea of one repo for core and client.
My background is that I spent a long time working with HttpCore5 to build a proprietary reverse proxy (which has since been rewritten on top of Jetty but that's a different and unrelated story and has nothing to do with the merits or quality of HttpComponents.) The pro of the current set up is that it _seems_ simpler for me to have used new releases of HC5 because there is less code in that repo and therefore less to manage for releases. For example, no need to wait for a bug fix in HttpClient to get a new Core out. The con is that I still use HttpClient for testing what I built with HttpCore, so those two sets of jars MUST be in sync to at least make testing simplest so that they all can live in the same class loader. From an outside POV, I am never 100% sure if versions of Client and Core are guaranteed to match up. This is the same kind of issue I have with Apache Commons DBCP sitting on top of Commons Pool. In our current scheme here, I would want a Client to be released immediately after a Core release to mark the fact that one is made to work with the other. Having both Core and Client in the same repo would make releasing matching jars easier I think, All of this to say that I like one repo and releasing a set of matching jars. It would be even be OK with me if an edge case would be to fix a bug in Core and release both Core and Client, even if nothing has changed in Client. It would tell folks, yep, this guaranteed to match up and designed to work together. Gary On Wed, Dec 18, 2019 at 2:32 AM Ryan Schmitt <rschm...@apache.org> wrote: > It sounds like these changes aren't going to happen, but I'm going to press > the point anyway because I think this is important. > > > 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. > > HttpCore includes both :httpcore5-h2 and :httpcore5-reactive, which are > brand new, highly complex components that are much less stable than > :httpcore5 (which is not that stable in the first place). By your own > admission, I could have written my entire SDK integration using just these > three components. That's a guarantee that HttpCore will *not* be a mature, > slow-moving product any time soon, and that users will need to explicitly > track both versions if we persist in this scheme. > > Let's not kid ourselves: HttpCore is going to be plagued with serious bugs > for years, and we will regularly put out unusably defective releases. The > complexity of HTTP/2 is all but unmanageable. I've seen it myself working > with Netty, which *still* hasn't stabilized its high-level HTTP/2 API after > all this time and effort. > > > Parent and website and changed rarely, why force releases? So are core > > and client logically decoupled. > > On reviewing the repositories, I agree with you about parent and website > (and stylecheck), since these repositories don't produce Maven artifacts > for public consumption. However, I see the version decoupling of core and > client as purely a source of friction for everyone, adding no value > whatsoever. > > You object to the idea of "forcing releases" of other components. Why? What > resource exactly do we manage to conserve by releasing three jar files at a > time, instead of six? The contradiction, by the way, is quite glaring here: > why are :httpcore5, :httpcore5-h2, and :httpcore5-reactive unified and > version aligned with each other, while HttpCore and HttpClient are > decoupled? It makes no sense. > > > Also consider the more modules you have in a reactor, the longer it > > takes to build and test everything. > > First of all, even this claim is not true if you consider how much faster > Gradle could build everything in a single repository, by parallelizing > across all modules. More importantly, the time it takes to *iterate* on > coordinated changes between Core and Client is literally orders of > magnitude longer because they are developed totally separately. > > > The moving targets you have described will slow down when version 5 has > > gone GA. > > Right now, to debug my sporadically failing integration tests in > HttpClient, I want to add debug logging to various places in HttpCore, and > add other types of debugging code as well. Every time I change the > debugging code, I have to locally simulate *an entire release cycle* of > HttpCore, instead of just making all of these changes through my IDE in a > single workspace. >
