On Sun, 2007-02-25 at 14:08 +0100, Roland Weber wrote: > Hi all, > > there are some open questions about how we're going to or > should split our code into components and modules, and how > we're going to version them. I can't participate in > discussions for the next two weeks, but Oleg will start > pushing for an HttpClient alpha before that, so I thought > I should share my thoughts anyway. If you're not in the > mood for reading my half-baked ideas, you can skip down to > the last paragraph, where I'm suggesting how to proceed. > > --- begin of half-baked ideas --- > > For starters, I feel we should have rather more components > than less. Take for example the HttpClient component in > which we're also developing HttpConn, HttpCookie and HttpAuth. > There is no problem now, as we're in an early stage and all > the code is still changing. But I don't expect that to be > the case in the future. HttpCookie and HttpAuth are coded > based on specifications that don't change anymore. Once we > have the APIs stabilized, there will be little change. > HttpConn on the other hand will see a lot of change for > performance optimizations and bug fixes, while HttpClient > will see a lot of change to make it's API easier to use > for application programmers. If we keep them together in > one component, we will sooner or later end up releasing a > new version of HttpCookie and HttpAuth in which no code > has changed, because we need to ship a new version of > HttpConn and/or HttpClient. Of course this is only an > issue if we put HttpCookie and HttpAuth into separate > modules within HttpClient. > The same situation is at the root of my concerns about > HttpCore-NIO. We have intentionally reduced the scope of > HttpCore-main to get a better grip on the problems it > addresses and to stabilize the code in there. Stuff we > moved out included the opening of connections, along with > SocketFactory and Scheme. HttpCore-NIO started as "fairly > little code" for which "a separate release cycle does not > actually make sense"[1]. I feel that it has picked up much > more responsibilities since, and is no longer a NIO > version or implementation of HttpCore-main.
Roland, With all due respect I do not see it this way. Ability to queue requests is the only thing I can think of, which HttpCore NIO has and HttpCore CIO does not. > > Now one thing we must keep in mind are our users and the > jar hell into which we might be putting them. Oleg already > suggested a vote or poll on general@ about splitting > HttpClient into separate modules for client, conn, auth > and cookie. But before we can start such a poll, we need > to agree on what our packaging should be in the future. > Because the answers we'll get very much depend on the > question we'll be asking. > If our question is "Do you want few jars or many jars?", > we don't even have to ask. If our question is "We'll need > many jars anyway. Do you want them right from the start, > or do you want to rework your build in a few months?", > the answers will be more diverse. > And then there's that idea lurking in the back of my > mind. If we told them that we'll have three jars in > HttpElf, and seven in HttpDwarf, and nine in HttpMen, > there would be howling and chattering of teeth. But > then we could tell them that we have... > > One jar to keep them all, > One jar to find them, > One jar to bring them all, > And from one artefact link them. > [2] > From what little I know of Maven, it should not be too > tricky to create a meta release of HttpComponents by > unjaring the individual modules and rejaring them into > a single package. If we had that, we could ask users > (in particular Synapse) to build against that for > convenience. The meta release would be synchronized > with releases of the individual components, in three > flavors: > HttpComponents-early packages the newest release of > everything, whether it be alpha, beta, RC or final. > HttpComponents-mature packages only mature releases, > that is (beta?,) RC and final. > HttpComponents-final packages only final releases. > I am afraid this approach will break Maven's dependency mediation and conflict resolution mechanism [1], which presently assumes one version per artifact (JAR). If we ever provide HttpComponents bundle, it should be clearly targeted at non-Maven users who prefer to manage project dependencies manually. As to the versioning of HttpComponents bundles, I am presently leaning toward a super-trivial scheme based on YYYYMMDD(-GA) notation, where -GA represents a release of stable versions of all bundled components. Cheers, Oleg [1] http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
