Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Subject: Re: HC 5.0: artifact id; Re: HC 5.0: package / module structure; Re:
 HC 5.0: co-location with HC 4.x
To: HttpComponents Project <dev@hc.apache.org>
References: <1447932726.2577.28.camel@apache.org>
 <1448125282.25520.8.camel@ok2consulting.com>
 <1448469399.31431.9.camel@apache.org>
From: Michael Osipov <michaelo@apache.org>
Message-ID: <56561408.8030100@apache.org>
Date: Wed, 25 Nov 2015 21:03:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <1448469399.31431.9.camel@apache.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Am 2015-11-25 um 17:36 schrieb Oleg Kalnichevski:
> Folks
>
> I made the first pass at re-arranging packages in HttpCore trunk and
> think it is presently good enough for 5.0-alpha1
>
> Please feel free to take a look.

Just checked. Looks like a tremendous move action. I will require a day 
or two to have a look at it. At first glance, it looks good.

> I am now going to change artifact id from
>
> org.apache.httpcomponents:httpcore
>
> to
>
> org.apache.httpcomponents.core5:httpcore
>
> Please let me know if you have objections or better ideas.

The group id is good. I think we can do better with the artifact id(s).

httpcomponents-core-parent or even simpler httpcore-parent (a parent 
should always be named as such)
|- httpcore
|- httpcore-ab
|- httpcore-osgi

We should always keep in mind that the artifact should be recognizable 
by its filname or id. Maybe httpcomponents-httpcore, -httpcore-ab, etc. 
would be better but they are, of course, longer. (imho)

Those depicted in the tree are probably an acceptable trade-off.

Michael

> On Sat, 2015-11-21 at 18:01 +0100, Oleg Kalnichevski wrote:
>> 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.
>>
>> Oleg
>>
>>
>>
>> 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
>
>


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