You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Roland Weber <ht...@dubioso.net> on 2007/02/25 14:08:24 UTC
[HttpComponents] componentization, packaging, versioning
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. It seems to
do things that we intentionally took out of HttpCore-main
to stabilize the API for blocking IO. Something I don't
want to see is a new release of HttpCore-main because of
changes only in HttpCore-NIO.
What I would like to see (though I don't expect it to
happen anymore) is HttpCore-NIO shrinking back to match
the scope of HttpCore-main (like nio.codecs) while the
stuff that better matches HttpConn moves into something
new like HttpAsync-Reactor or so. Mind you, I don't even
know whether this kind of split is feasible on the code
level. I'm just dreaming here.
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.
Combined JavaDocs or source releases might pose a
bigger challenge, but those would be nice-to-have
rather than a must-have.
Moving our early adopters to a meta release would allow
us to shuffle around components and modules without
causing more inconvenience for those users. Then we
could discuss code location without users expecting
the code in the provisional place we once chose for
our convenience.
The problem with this idea, as always, is time. My
current development stint is ending with this mail, and
the next one won't start until July, maybe August. If
I can't realize the idea of a meta release with little
effort then, I'd also jump on the "fewer is better"
bandwagon.
There's versioning mentioned in the subject of this
mail. For one thing this means version detection at
runtime, in particular for debug output. I'd like to
do this via properties files in the distributed JARs,
with the version being updated by the build process.
So it is one more item for which I have to learn Maven,
and which has to wait until the next development stint
if I am the one to address it.
Then there's the version numbering for components on
separate release cycles. HttpClient alpha 1 will require
HttpCore alpha 4 or 5. That's not exactly obvious for
users. A meta release would ease that pain for users,
too. Even without a meta release, we should maintain
a table on the HttpComponents web page that lists the
sets of compatible versions.
When I was still coding on HttpAsync (to become
HttpDispatch) last year, I tentatively declared it
version 4.0 for consistency with the other components.
Then we discussed that it should rather start at
version 1.0 since it is a new code base. As it happens,
HttpCore-NIO is also a new code base but has inherited
the 4.0 version of HttpCore.
A meta release or a table of compatible versions gives
us a linear counter across individual components. When
adding that to the component specific version, people
(including ourselves) would known without a table lookup
whether a release of one component is newer or older
than that of a different component. Come to think of it,
a date in the version would serve the same purpose :-)
--- end of half-baked ideas ---
So this is how I think we should proceed:
- release HttpClient alpha 1 as it is, in a single jar
- release HttpCore alpha 4 as it is (with module-niossl
deprecated, to be moved out of core before beta)
- give me time to play around with Maven in Jul/Aug/Sep
- make a final decision on packaging in Sep/Oct
cheers,
Roland
[1]
http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200608.mbox/%3c1154513001.4891.22.camel@localhost.localdomain%3e
[2] freely adapted from J.R.R. Tolkien, "The Lord of the Rings"
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpComponents] componentization, packaging, versioning
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2007-03-11 at 11:31 +0100, Roland Weber wrote:
> Hi Oleg,
>
> > 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.
>
> If you consider ElementalHttpServer as part of HttpCore, I can see your
> point. If I am not mistaken, NIO includes logic to dispatch incoming
> requests to worker threads. That's nowhere in the module-main JAR. We
> give an example of how to do it, but NIO builds a framework. I guess
> multithreading is inseparable from NIO and can rightfully claim to be
> at the core for NIO, so I'll shut up on this matter.
>
> >> 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.
> >
> > [1]
> >
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
>
> Transitive dependencies? You mean it's a simple as defining a dummy
> artefact with all the alphas as a dependency and then those alphas
> will be picked up as transitive dependencies by everyone depending
> on the dummy? HttpClient (+Maven) users will declare only HttpClient
> as a dependency and automatically pick up HttpCore and, if we should
> have them, HttpAuth and HttpCookie? Regardless of whether they are
> a module of HttpClient or a separate component? Synapse is going to
> depend on module-niossl and will get HttpCore and HttpNIO without
> noticing where they come from?
Hi Roland,
I believe this is correct.
> That sounds promising. Dummy artefacts for Maven users,
> repackaged JARs for manual deployment.
>
Yep. We would still have to get a formal okay from the rest of Jakarta
to go ahead with this approach, though. I can start working on a
proposal once HttpClient 3.1rc1 and HttpCore 4.0a4 have been released,
HttpConn reviewed, Not-Yet-Commons SSL proposal commented on, HttpAuth
ported to the new API, and Axis2 simple HTTP server updated to HttpCore
4.0a4 ;-)
Oleg
> cheers,
> Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpComponents] componentization, packaging, versioning
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> 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.
If you consider ElementalHttpServer as part of HttpCore, I can see your
point. If I am not mistaken, NIO includes logic to dispatch incoming
requests to worker threads. That's nowhere in the module-main JAR. We
give an example of how to do it, but NIO builds a framework. I guess
multithreading is inseparable from NIO and can rightfully claim to be
at the core for NIO, so I'll shut up on this matter.
>> 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.
>
> [1]
>
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
Transitive dependencies? You mean it's a simple as defining a dummy
artefact with all the alphas as a dependency and then those alphas
will be picked up as transitive dependencies by everyone depending
on the dummy? HttpClient (+Maven) users will declare only HttpClient
as a dependency and automatically pick up HttpCore and, if we should
have them, HttpAuth and HttpCookie? Regardless of whether they are
a module of HttpClient or a separate component? Synapse is going to
depend on module-niossl and will get HttpCore and HttpNIO without
noticing where they come from?
That sounds promising. Dummy artefacts for Maven users,
repackaged JARs for manual deployment.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpComponents] componentization, packaging, versioning
Posted by Oleg Kalnichevski <ol...@apache.org>.
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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org