You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2015/11/25 17:36:39 UTC
HC 5.0: artifact id; Re: HC 5.0: package / module structure; Re: HC
5.0: co-location with HC 4.x
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.
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.
Oleg
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
Re: HC 5.0: artifact id; Re: HC 5.0: package / module structure; Re:
HC 5.0: co-location with HC 4.x
Posted by Michael Osipov <mi...@apache.org>.
Am 2015-11-25 um 21:07 schrieb Gary Gregory:
> [..]
>> |- 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)
>>
>
> I can't really imagine liking httpcomponents-httpcore5-5.0.jar. I do not
> think we need "httpcomponents" in the AID or jar file name, in the GID yes.
I have intentionally brought up this point, though I wouldn't promote
it. It feels too cumbersome. My first and foremost thought was simpyl to
avoid possible filename clashes.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: artifact id; Re: HC 5.0: package / module structure; Re:
HC 5.0: co-location with HC 4.x
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Nov 25, 2015 at 12:03 PM, Michael Osipov <mi...@apache.org>
wrote:
> 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)
>
+1 to "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)
>
I can't really imagine liking httpcomponents-httpcore5-5.0.jar. I do not
think we need "httpcomponents" in the AID or jar file name, in the GID yes.
Gary
>
> 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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: HC 5.0: artifact id; Re: HC 5.0: package / module structure; Re:
HC 5.0: co-location with HC 4.x
Posted by Michael Osipov <mi...@apache.org>.
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