Hi Oleg, > I am working hard trying to complete the rewrite of HttpCookie. I also > would like to copy over HttpAuth and HttpConn code from the Commons > HttpClient branch to HttpComponents HttpClient at some point in July. > Both HttpAuth and HttpConn may require very little API changes beyond > trivial removal of deprecated methods. When that's done we will have a > pretty complete set of components required to build a full fledged HTTP > client: HttpCore, HttpCookie, HttpAuth and HttpConn.
Sounds way cool! Thanks for all the hard work, while we are spending our time in the sun or at lakes :-) Here are my 0.02€ on the options: > That would be the > right moment to step back a little and take a closer look at our > options: > > (1) Do we want HttpCookie, HttpAuth, HttpConn to share the same release > cycle as HttpClient and be released under the same version? In this case > httpcomponents-full.jar may never be needed > > (2) Do we want to go all the way and spin off HttpCookie, HttpAuth, > HttpConn into separate modules with a separate release cycle versioned > independently from HttpClient? I am still in favor of spinning them off, after one or two combined alphas to stabilize the API. Once the API is stable we don't expect many changes, so the additional effort will be low. I therefore do not see a reason to revise the initial plan. > If so, how we are going to serve the > needs of those users who have never felt there were any particular > problem with HttpClient monolithic design or its package size? Those > people may be very upset at having to download a whole bunch of tiny > jars with different versions instead of just one. > > (2.1) Do we want to release jakarta-httpclient-4.x consisting of all its > HttpComponent dependencies: HttpCore, HttpCookie, HttpAuth, HttpConn? > How do we version it? Rather not. I don't see a point in stopping halfway along the road. > (2.2) Do we want to release jakarta-httpcomponents-4.x consisting of all > HttpComponent modules including HttpClient? Yepp. > How do we version it? The idea I was pondering is to use the HttpComponents meta-distribution as the version counter. Say we have HttpComponents version 4.0.0 with HttpCore, HttpClient, HttpAuth, HttpCookie, HttpConn all at the same version. Then HttpConn needs an update. Combined version goes up to 4.0.1, which is also used for HttpConn. All others stay at 4.0.0. Then HttpClient needs an update, which requires an update of HttpCore. Combined version goes to 4.0.2, which is also used for HttpCore and HttpClient, both skipping 4.0.1. All others stay where they are. The release cycle for HttpComponents will always be locked with the release cycle of the component or components that trigger the update. I haven't thought this through to the end. I suspect that alpha/beta will not be a problem: Components alpha packages the newest versions of all components, including alpha versions. Components beta packages the newest versions of all components that have reached beta stage. Components final packages only final versions of all components. What could break this strategy is upgrades in the second digit. If HttpClient is supposed to go to 4.1, then HttpComponents would need to go to 4.1. Then even minor upgrades to any other package would need that package to upgrade to a 4.1.x level. On the other hand, we might just count all HttpComponents releases in the third digit and not re-set that when the second digit changes. So if the version is 4.0.9 and we want to upgrade to 4.1, we'd have 4.1.10. Or else we count the HttpComponents version with a dash: 4.0-29, 4.1-30 and attach the dash version to the components that triggered the updated. No matter what, we'd need a big table on the HttpComponents site which lists for every release of HttpComponents exactly what versions of the individual components are in there. As I said, I didn't think it through. But despite the versioning question, I am in favor of releasing individual components as well as a combined package, which should include HttpNIO and HttpAsync. Otherwise, the communities around these might have an even harder time to grow. Packaging everything should encourage people that use the combined JAR to try out those APIs, rather than avoiding them in order to not catch a new dependency. I'll be leaving for a short business trip this evening. I should be back on Thursday to resume the discussion. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
