hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x
Date Sat, 21 Nov 2015 18:48:26 GMT
Am 2015-11-21 um 18:01 schrieb Oleg Kalnichevski:
> Folks
>
> I moved code to org.apache.hc.core5 namespace as the first step.
>
> Now I would like to move things around in order to make the package
> structure more consistent, reduce circular dependencies between packages
> and prepare for messaging code separation into HTTP/1.1 and HTTP/2
> compliant implementations.
>
> However, more importantly I would like to fold httpcore-nio into
> httpcore. Separation into two modules made sense in 2005 but hardly
> makes any sense today in 2015.
>
> Please let me know if you have any objections to that.

I am quite happy with that. The rename is the very first step to get the 
module in shape.

We should immediately drop deprecated stuff and stuff which is already 
in Java 7 by default. Moreover stuff which is in other Commons projects 
which we could either verbatim copy into util or simply depend on it, 
e.g., Commons Lang StringUtils/Validate.

Have you thought about adapting group ids and artifact ids as well? 
Currently, they seem counter-intuitive to me. Not the way I would expect 
proper artifact id names. At least not sturctured the way I am used from 
maven.a.o.

Additionally, the parent POM has a stupid artifact id, as well as 
configurations which are by now obsolete or already set by default by now.
I'd like to work on the parent POM to take it to a new level which would 
introduce a new artifact id. It could co-exist with 4.x until it goes 
out of life.

WDYT?

Michael

> On Thu, 2015-11-19 at 12:32 +0100, Oleg Kalnichevski wrote:
>> Folks
>>
>> I would like to start working on the first alpha releases of HC 5.0.
>>
>> There is one issue that still needs to be discussed though before I can
>> proceed. We need to decide on how we intent to maintain compatibility
>> with HC 4.x. It is pretty clear that maintaining full compatibility is
>> unrealistic and probably counter-productive. HC 5.0 is likely to have
>> different APIs especially once HTTP/2 transport is implemented.
>>
>> A pragmatic approach could be to make HC 5.0 and HC 4.x deployable
>> within the same class loader context (so called co-location). This is
>> what Apache Commons do with their major releases. We should do
>> likewise.
>>
>> Effectively co-location is about moving major releases to a new package
>> space like org.apache.commons.lang3, org.apache.commons.lang4, etc. I
>> think we should adopt a compatible scheme. The trouble is that when the
>> project was started in 2005 the choice of 'org.apache.http' was pretty
>> natural and in line with Jakarta practices (anyone here still remembers
>> Apache Jakarta?). Now it can be seen as too presumptuous. This would be
>> a good opportunity to fix that.
>>
>> What would be a better name space for the project in your opinion?
>>
>> org.apache.http<n>
>> org.apache.http.hc<n>
>> org.apache.hc<n>.http
>> where <n> is a major release version
>>
>> Something else? Any thoughts or preferences?
>>
>> Oleg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message