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/19 12:32:06 UTC
HC 5.0: co-location with HC 4.x
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
Re: HC 5.0: co-location with HC 4.x
Posted by sebb <se...@gmail.com>.
On 19 November 2015 at 11:32, Oleg Kalnichevski <ol...@apache.org> 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?
Java package names and Maven groupIds need to be globally unique.
Both of these currently start with org.apache, which is a good start
as it means possible duplicates are restricted to ASF projects.
However we should also try and minimise our use of top-level
sub-domains of the org.apache domain.
[As Commons does]
HC currently uses:
Gid: org.apache.httpcomponents
Package: org.apache.http
Therefore any package names need to be under org.apache.http, e.g.
org.apache.http.hc<n>
Commons uses the artifactId to distinguish different release versions,
keeping the same GID.
> 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
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
HC 5.0: artifact id; Re: HC 5.0: package / module structure; Re: HC
5.0: co-location with HC 4.x
Posted by Oleg Kalnichevski <ol...@apache.org>.
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: package / module structure; Re: HC 5.0: co-location with
HC 4.x
Posted by Michael Osipov <mi...@apache.org>.
Am 2015-11-21 um 19:52 schrieb Gary Gregory:
> +1.
>
> I would not mind using Java 8 too.
Believe that is too early. We are using a company-wide, Eclipse
RCP-based product which is on Eclipse 3.4/3.6 and still HttpClient 3.x.
I highly doubt that the dev team will jump on e4 and Java 8 features.
Java 7 is a good base line.
Michael
> Gary
> On Nov 21, 2015 9:03 AM, "Oleg Kalnichevski" <ol...@ok2consulting.com> 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: package / module structure; Re: HC 5.0: co-location with
HC 4.x
Posted by Gary Gregory <ga...@gmail.com>.
+1.
I would not mind using Java 8 too.
Gary
On Nov 21, 2015 9:03 AM, "Oleg Kalnichevski" <ol...@ok2consulting.com> 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
>
>
Re: Re: Re: HC 5.0: package / module structure; Re: HC 5.0:
co-location with HC 4.x
Posted by Michael Osipov <19...@gmx.net>.
> On Mon, 2015-11-23 at 10:51 +0100, Michael Osipov wrote:
> > > On Sun, 2015-11-22 at 20:42 +0100, Michael Osipov wrote:
> > > > Am 2015-11-22 um 20:11 schrieb Oleg Kalnichevski:
> > > > > On Sat, 2015-11-21 at 19:48 +0100, Michael Osipov wrote:
> > > > >> 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.
> > > > >>
> > > > >
> > > > > Are you referring to this one?
> > > > >
> > > > > http://svn.apache.org/repos/asf/httpcomponents/project/trunk/pom.xml
> > > > >
> > > > > If so, by all of means do feel free to improve it.
> > > >
> > > > Yes, that one. I would prefer to create a new one under
> > > > http://svn.apache.org/repos/asf/httpcomponents/pom/trunk/pom.xml to
> > > > avoid disruptive changes with a new artifact id. The POM is so old that
> > > > is hasn't been improved structurally for years. There have been so many
> > > > changes to Apache Parent and Maven Parent from which we can benefit from.
> > > >
> > > > If you are fine with that, I will copy and start my work next week.
> > > >
> > >
> > > Feel free to completely wipe out the existing pom.xml and start from
> > > scratch. Do we really need a new project location though?
> >
> > That is a deliberate choice. Given tha the user base is big, I don't want anyone
> > to open up the "old" URL and see a competely different POM with a different artifact
> > id. My primary goal is stability and predictability. Otherwise I would wipe 8-SNAPSHOT
> > and begin it anew.
> >
>
> Who would that be? Archaeologists?
I can't tell, that is why I am cautious.
> There are tags for previous releases for anyone still interested. See no
> reason of what so ever to keep the old branch.
If that is OK for you. I do not mind to re-start inline.
What do others say?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location
with HC 4.x
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2015-11-23 at 10:51 +0100, Michael Osipov wrote:
> > On Sun, 2015-11-22 at 20:42 +0100, Michael Osipov wrote:
> > > Am 2015-11-22 um 20:11 schrieb Oleg Kalnichevski:
> > > > On Sat, 2015-11-21 at 19:48 +0100, Michael Osipov wrote:
> > > >> 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.
> > > >>
> > > >
> > > > Are you referring to this one?
> > > >
> > > > http://svn.apache.org/repos/asf/httpcomponents/project/trunk/pom.xml
> > > >
> > > > If so, by all of means do feel free to improve it.
> > >
> > > Yes, that one. I would prefer to create a new one under
> > > http://svn.apache.org/repos/asf/httpcomponents/pom/trunk/pom.xml to
> > > avoid disruptive changes with a new artifact id. The POM is so old that
> > > is hasn't been improved structurally for years. There have been so many
> > > changes to Apache Parent and Maven Parent from which we can benefit from.
> > >
> > > If you are fine with that, I will copy and start my work next week.
> > >
> >
> > Feel free to completely wipe out the existing pom.xml and start from
> > scratch. Do we really need a new project location though?
>
> That is a deliberate choice. Given tha the user base is big, I don't want anyone
> to open up the "old" URL and see a competely different POM with a different artifact
> id. My primary goal is stability and predictability. Otherwise I would wipe 8-SNAPSHOT
> and begin it anew.
>
Who would that be? Archaeologists?
There are tags for previous releases for anyone still interested. See no
reason of what so ever to keep the old branch.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location
with HC 4.x
Posted by Michael Osipov <19...@gmx.net>.
> On Sun, 2015-11-22 at 20:42 +0100, Michael Osipov wrote:
> > Am 2015-11-22 um 20:11 schrieb Oleg Kalnichevski:
> > > On Sat, 2015-11-21 at 19:48 +0100, Michael Osipov wrote:
> > >> 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.
> > >>
> > >
> > > Are you referring to this one?
> > >
> > > http://svn.apache.org/repos/asf/httpcomponents/project/trunk/pom.xml
> > >
> > > If so, by all of means do feel free to improve it.
> >
> > Yes, that one. I would prefer to create a new one under
> > http://svn.apache.org/repos/asf/httpcomponents/pom/trunk/pom.xml to
> > avoid disruptive changes with a new artifact id. The POM is so old that
> > is hasn't been improved structurally for years. There have been so many
> > changes to Apache Parent and Maven Parent from which we can benefit from.
> >
> > If you are fine with that, I will copy and start my work next week.
> >
>
> Feel free to completely wipe out the existing pom.xml and start from
> scratch. Do we really need a new project location though?
That is a deliberate choice. Given tha the user base is big, I don't want anyone
to open up the "old" URL and see a competely different POM with a different artifact
id. My primary goal is stability and predictability. Otherwise I would wipe 8-SNAPSHOT
and begin it anew.
Some projects even choose a new Subversion tree/Git branch for every new major release.
See Tomcat or Maven. Everything can live side-by-side.
WDYT?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: package / module structure; Re: HC 5.0: co-location
with HC 4.x
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2015-11-22 at 20:42 +0100, Michael Osipov wrote:
> Am 2015-11-22 um 20:11 schrieb Oleg Kalnichevski:
> > On Sat, 2015-11-21 at 19:48 +0100, Michael Osipov wrote:
> >> 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.
> >>
> >
> > Are you referring to this one?
> >
> > http://svn.apache.org/repos/asf/httpcomponents/project/trunk/pom.xml
> >
> > If so, by all of means do feel free to improve it.
>
> Yes, that one. I would prefer to create a new one under
> http://svn.apache.org/repos/asf/httpcomponents/pom/trunk/pom.xml to
> avoid disruptive changes with a new artifact id. The POM is so old that
> is hasn't been improved structurally for years. There have been so many
> changes to Apache Parent and Maven Parent from which we can benefit from.
>
> If you are fine with that, I will copy and start my work next week.
>
Feel free to completely wipe out the existing pom.xml and start from
scratch. Do we really need a new project location though?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
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-22 um 20:11 schrieb Oleg Kalnichevski:
> On Sat, 2015-11-21 at 19:48 +0100, Michael Osipov wrote:
>> 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.
>>
>
> Are you referring to this one?
>
> http://svn.apache.org/repos/asf/httpcomponents/project/trunk/pom.xml
>
> If so, by all of means do feel free to improve it.
Yes, that one. I would prefer to create a new one under
http://svn.apache.org/repos/asf/httpcomponents/pom/trunk/pom.xml to
avoid disruptive changes with a new artifact id. The POM is so old that
is hasn't been improved structurally for years. There have been so many
changes to Apache Parent and Maven Parent from which we can benefit from.
If you are fine with that, I will copy and start my work next week.
Michael
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: package / module structure; Re: HC 5.0: co-location
with HC 4.x
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2015-11-21 at 19:48 +0100, Michael Osipov wrote:
> 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.
>
Are you referring to this one?
http://svn.apache.org/repos/asf/httpcomponents/project/trunk/pom.xml
If so, by all of means do feel free to improve it.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
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-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
HC 5.0: package / module structure; Re: HC 5.0: co-location with HC
4.x
Posted by Oleg Kalnichevski <ol...@ok2consulting.com>.
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
Re: HC 5.0: co-location with HC 4.x
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 20, 2015 at 2:50 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2015-11-19 at 23:27 +0000, sebb wrote:
> > On 19 November 2015 at 21:17, Michael Osipov <mi...@apache.org>
> wrote:
> > > Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski:
>
> ...
>
> > >
> > > First of all, I wouldn't use any of those. (Currently referring to
> package
> > > names only). Artifact ids are a different story.
> > >
> > > org.apache.http: that is too general and confuses me with Apache HTTP
> > > Server.
> > > org.apache.http.hc: http seems redundant here due to hc (http
> components).
> > > org.apache.hc<n>.http: same here.
> > >
> > > I would do:
> > >
> > > HC Core: org.apache.hc.core5
> > > HC Client: org.apache.hc.client5
> > > HC Async Cilent: org.apache.hc.asyncclient5
> > >
> > > Clean and simple. Each project would be scoped in its namespace.
> Picking up
> > > sebb's opinion, we even reflect the HTTP domain in the package name.
> >
> > It's not just my _opinion_.
> > We cannot freely choose the package name, because we are not the only
> > Java project in the world, nor even in the org.apache namespace.
> >
> > Likewise we cannot use the domain com.oracle or com.ibm or even
> com.apache.
> > We MUST use the ASF domain as the package name prefix or there is a
> > risk of clashes with 3rd party software.
> >
> > org.apache.hc should be OK, since we already use HC for the website.
> > It's very unlikely that any other ASF project will be named HC.
> >
>
> Would this be all right for everyone?
>
> org.apache.hc.core5.http
>
Fine with me.
Gary
>
> Oleg
>
>
> ---------------------------------------------------------------------
> 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: co-location with HC 4.x
Posted by Michael Osipov <mi...@apache.org>.
Am 2015-11-20 um 19:38 schrieb Gary Gregory:
> On Fri, Nov 20, 2015 at 10:04 AM, Michael Osipov <mi...@apache.org>
> wrote:
>
>> Am 2015-11-20 um 16:33 schrieb Oleg Kalnichevski:
>>
>>> On Fri, 2015-11-20 at 15:13 +0100, Michael Osipov wrote:
>>>
>>>> On Fri, 2015-11-20 at 12:42 +0100, Michael Osipov wrote:
>>>>>
>>>>>> On Thu, 2015-11-19 at 23:27 +0000, sebb wrote:
>>>>>>>
>>>>>>>> On 19 November 2015 at 21:17, Michael Osipov <mi...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski:
>>>>>>>>>
>>>>>>>>
>>> ...
>>>
>>> Would this be all right for everyone?
>>>>>>>
>>>>>>> org.apache.hc.core5.http
>>>>>>>
>>>>>>
>>>>>> Why do you want to use the redundant 'http'?
>>>>>>
>>>>>
>>>>> While not very likely we might have non HTTP protocol support as well,
>>>>> such as Websockets.
>>>>>
>>>>
>>>> I see but WebSockets share no common code with HTTP except the initial
>>>> handshake.
>>>> I would rather see this as another top level project because
>>>> HttpClient's API is
>>>> highly optimized for HTTP and not a general-purpose one like Commons VFS.
>>>>
>>>>
>>> Project charter allows us to pursue development of a component toolset
>>> 'focused on HTTP and associated protocols'.
>>>
>>
>> I wouldn't really say that WebSockets are an associated protocol due to
>> its different nature in communication and messaging.
>>
>> I highly doubt that we well gain the proper momentum to develop something
>> for WebSockets. It should be at least as good as Jetty's WS Client API.
>>
>> I also can well imagine SSL related components being in a separate
>>> namespace like 'org.apache.hc.core5.ssl'
>>>
>>
>> That would be ok.
>>
>> At the end, you propose:
>>
>> HC Core: org.apache.hc.http.core5
>> HC Client: org.apache.hc.http.client5
>> HC Async Cilent: org.apache.hc.http.asyncclient5
>>
>> Is that right?
>>
>
> hc.http seems redundant to me.
>
> HC Core: org.apache.hc.core5
> HC Client: org.apache.hc.client5
> HC Async Cilent: org.apache.hc.asyncclient5
> or
> HC Async Cilent: org.apache.hc.client5.assync
Gary,
that was my proposal too where Oleg commented on. Please read the entire
tread.
asyncclient5 is better because it is not developed in sync with sync client.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: co-location with HC 4.x
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 20, 2015 at 10:04 AM, Michael Osipov <mi...@apache.org>
wrote:
> Am 2015-11-20 um 16:33 schrieb Oleg Kalnichevski:
>
>> On Fri, 2015-11-20 at 15:13 +0100, Michael Osipov wrote:
>>
>>> On Fri, 2015-11-20 at 12:42 +0100, Michael Osipov wrote:
>>>>
>>>>> On Thu, 2015-11-19 at 23:27 +0000, sebb wrote:
>>>>>>
>>>>>>> On 19 November 2015 at 21:17, Michael Osipov <mi...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski:
>>>>>>>>
>>>>>>>
>> ...
>>
>> Would this be all right for everyone?
>>>>>>
>>>>>> org.apache.hc.core5.http
>>>>>>
>>>>>
>>>>> Why do you want to use the redundant 'http'?
>>>>>
>>>>
>>>> While not very likely we might have non HTTP protocol support as well,
>>>> such as Websockets.
>>>>
>>>
>>> I see but WebSockets share no common code with HTTP except the initial
>>> handshake.
>>> I would rather see this as another top level project because
>>> HttpClient's API is
>>> highly optimized for HTTP and not a general-purpose one like Commons VFS.
>>>
>>>
>> Project charter allows us to pursue development of a component toolset
>> 'focused on HTTP and associated protocols'.
>>
>
> I wouldn't really say that WebSockets are an associated protocol due to
> its different nature in communication and messaging.
>
> I highly doubt that we well gain the proper momentum to develop something
> for WebSockets. It should be at least as good as Jetty's WS Client API.
>
> I also can well imagine SSL related components being in a separate
>> namespace like 'org.apache.hc.core5.ssl'
>>
>
> That would be ok.
>
> At the end, you propose:
>
> HC Core: org.apache.hc.http.core5
> HC Client: org.apache.hc.http.client5
> HC Async Cilent: org.apache.hc.http.asyncclient5
>
> Is that right?
>
hc.http seems redundant to me.
HC Core: org.apache.hc.core5
HC Client: org.apache.hc.client5
HC Async Cilent: org.apache.hc.asyncclient5
or
HC Async Cilent: org.apache.hc.client5.assync
?
Gary
> I have intentionally switched that because client wouldn't live under
> core5. I have already Java modules in mind Oracle is about to introduce in
> Java 9 (auto module feature).
>
> Michael
>
>
> ---------------------------------------------------------------------
> 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: co-location with HC 4.x
Posted by Michael Osipov <mi...@apache.org>.
Am 2015-11-20 um 20:57 schrieb Oleg Kalnichevski:
>>> I also can well imagine SSL related components being in a separate
>>> namespace like 'org.apache.hc.core5.ssl'
>>
>> That would be ok.
>>
>> At the end, you propose:
>>
>> HC Core: org.apache.hc.http.core5
>> HC Client: org.apache.hc.http.client5
>> HC Async Cilent: org.apache.hc.http.asyncclient5
>>
>> Is that right?
>>
>
> Almost.
>
> HC Core: org.apache.hc.core5 (including org.apache.hc.core5.http,
> org.apache.hc.core5.ssl, etc)
Very good.
> HC Client: org.apache.hc.client5 (including org.apache.hc.client5.http)
Very good.
> HC Async Client: I was going to propose it be merged into HC client, but
> this is a subject to another discussion.
If it doesn't have a huge impact on size, this is fine.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: co-location with HC 4.x
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2015-11-20 at 19:04 +0100, Michael Osipov wrote:
> Am 2015-11-20 um 16:33 schrieb Oleg Kalnichevski:
> > On Fri, 2015-11-20 at 15:13 +0100, Michael Osipov wrote:
> >>> On Fri, 2015-11-20 at 12:42 +0100, Michael Osipov wrote:
> >>>>> On Thu, 2015-11-19 at 23:27 +0000, sebb wrote:
> >>>>>> On 19 November 2015 at 21:17, Michael Osipov <mi...@apache.org> wrote:
> >>>>>>> Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski:
> >
> > ...
> >
> >>>>> Would this be all right for everyone?
> >>>>>
> >>>>> org.apache.hc.core5.http
> >>>>
> >>>> Why do you want to use the redundant 'http'?
> >>>
> >>> While not very likely we might have non HTTP protocol support as well,
> >>> such as Websockets.
> >>
> >> I see but WebSockets share no common code with HTTP except the initial handshake.
> >> I would rather see this as another top level project because HttpClient's API is
> >> highly optimized for HTTP and not a general-purpose one like Commons VFS.
> >>
> >
> > Project charter allows us to pursue development of a component toolset
> > 'focused on HTTP and associated protocols'.
>
> I wouldn't really say that WebSockets are an associated protocol due to
> its different nature in communication and messaging.
>
> I highly doubt that we well gain the proper momentum to develop
> something for WebSockets. It should be at least as good as Jetty's WS
> Client API.
>
I am not saying we should do it. I am saying our charter allows us to do
so.
> > I also can well imagine SSL related components being in a separate
> > namespace like 'org.apache.hc.core5.ssl'
>
> That would be ok.
>
> At the end, you propose:
>
> HC Core: org.apache.hc.http.core5
> HC Client: org.apache.hc.http.client5
> HC Async Cilent: org.apache.hc.http.asyncclient5
>
> Is that right?
>
Almost.
HC Core: org.apache.hc.core5 (including org.apache.hc.core5.http,
org.apache.hc.core5.ssl, etc)
HC Client: org.apache.hc.client5 (including org.apache.hc.client5.http)
HC Async Client: I was going to propose it be merged into HC client, but
this is a subject to another discussion.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: co-location with HC 4.x
Posted by Michael Osipov <mi...@apache.org>.
Am 2015-11-20 um 16:33 schrieb Oleg Kalnichevski:
> On Fri, 2015-11-20 at 15:13 +0100, Michael Osipov wrote:
>>> On Fri, 2015-11-20 at 12:42 +0100, Michael Osipov wrote:
>>>>> On Thu, 2015-11-19 at 23:27 +0000, sebb wrote:
>>>>>> On 19 November 2015 at 21:17, Michael Osipov <mi...@apache.org> wrote:
>>>>>>> Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski:
>
> ...
>
>>>>> Would this be all right for everyone?
>>>>>
>>>>> org.apache.hc.core5.http
>>>>
>>>> Why do you want to use the redundant 'http'?
>>>
>>> While not very likely we might have non HTTP protocol support as well,
>>> such as Websockets.
>>
>> I see but WebSockets share no common code with HTTP except the initial handshake.
>> I would rather see this as another top level project because HttpClient's API is
>> highly optimized for HTTP and not a general-purpose one like Commons VFS.
>>
>
> Project charter allows us to pursue development of a component toolset
> 'focused on HTTP and associated protocols'.
I wouldn't really say that WebSockets are an associated protocol due to
its different nature in communication and messaging.
I highly doubt that we well gain the proper momentum to develop
something for WebSockets. It should be at least as good as Jetty's WS
Client API.
> I also can well imagine SSL related components being in a separate
> namespace like 'org.apache.hc.core5.ssl'
That would be ok.
At the end, you propose:
HC Core: org.apache.hc.http.core5
HC Client: org.apache.hc.http.client5
HC Async Cilent: org.apache.hc.http.asyncclient5
Is that right?
I have intentionally switched that because client wouldn't live under
core5. I have already Java modules in mind Oracle is about to introduce
in Java 9 (auto module feature).
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Re: Re: HC 5.0: co-location with HC 4.x
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2015-11-20 at 15:13 +0100, Michael Osipov wrote:
> > On Fri, 2015-11-20 at 12:42 +0100, Michael Osipov wrote:
> > > > On Thu, 2015-11-19 at 23:27 +0000, sebb wrote:
> > > > > On 19 November 2015 at 21:17, Michael Osipov <mi...@apache.org> wrote:
> > > > > > Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski:
...
> > > > Would this be all right for everyone?
> > > >
> > > > org.apache.hc.core5.http
> > >
> > > Why do you want to use the redundant 'http'?
> >
> > While not very likely we might have non HTTP protocol support as well,
> > such as Websockets.
>
> I see but WebSockets share no common code with HTTP except the initial handshake.
> I would rather see this as another top level project because HttpClient's API is
> highly optimized for HTTP and not a general-purpose one like Commons VFS.
>
Project charter allows us to pursue development of a component toolset
'focused on HTTP and associated protocols'.
I also can well imagine SSL related components being in a separate
namespace like 'org.apache.hc.core5.ssl'
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Re: Re: HC 5.0: co-location with HC 4.x
Posted by Michael Osipov <19...@gmx.net>.
> On Fri, 2015-11-20 at 12:42 +0100, Michael Osipov wrote:
> > > On Thu, 2015-11-19 at 23:27 +0000, sebb wrote:
> > > > On 19 November 2015 at 21:17, Michael Osipov <mi...@apache.org> wrote:
> > > > > Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski:
> > >
> > > ...
> > >
> > > > >
> > > > > First of all, I wouldn't use any of those. (Currently referring to package
> > > > > names only). Artifact ids are a different story.
> > > > >
> > > > > org.apache.http: that is too general and confuses me with Apache HTTP
> > > > > Server.
> > > > > org.apache.http.hc: http seems redundant here due to hc (http components).
> > > > > org.apache.hc<n>.http: same here.
> > > > >
> > > > > I would do:
> > > > >
> > > > > HC Core: org.apache.hc.core5
> > > > > HC Client: org.apache.hc.client5
> > > > > HC Async Cilent: org.apache.hc.asyncclient5
> > > > >
> > > > > Clean and simple. Each project would be scoped in its namespace. Picking up
> > > > > sebb's opinion, we even reflect the HTTP domain in the package name.
> > > >
> > > > It's not just my _opinion_.
> > > > We cannot freely choose the package name, because we are not the only
> > > > Java project in the world, nor even in the org.apache namespace.
> > > >
> > > > Likewise we cannot use the domain com.oracle or com.ibm or even com.apache.
> > > > We MUST use the ASF domain as the package name prefix or there is a
> > > > risk of clashes with 3rd party software.
> > > >
> > > > org.apache.hc should be OK, since we already use HC for the website.
> > > > It's very unlikely that any other ASF project will be named HC.
> > > >
> > >
> > > Would this be all right for everyone?
> > >
> > > org.apache.hc.core5.http
> >
> > Why do you want to use the redundant 'http'?
>
> While not very likely we might have non HTTP protocol support as well,
> such as Websockets.
I see but WebSockets share no common code with HTTP except the initial handshake.
I would rather see this as another top level project because HttpClient's API is
highly optimized for HTTP and not a general-purpose one like Commons VFS.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Re: HC 5.0: co-location with HC 4.x
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2015-11-20 at 12:42 +0100, Michael Osipov wrote:
> > On Thu, 2015-11-19 at 23:27 +0000, sebb wrote:
> > > On 19 November 2015 at 21:17, Michael Osipov <mi...@apache.org> wrote:
> > > > Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski:
> >
> > ...
> >
> > > >
> > > > First of all, I wouldn't use any of those. (Currently referring to package
> > > > names only). Artifact ids are a different story.
> > > >
> > > > org.apache.http: that is too general and confuses me with Apache HTTP
> > > > Server.
> > > > org.apache.http.hc: http seems redundant here due to hc (http components).
> > > > org.apache.hc<n>.http: same here.
> > > >
> > > > I would do:
> > > >
> > > > HC Core: org.apache.hc.core5
> > > > HC Client: org.apache.hc.client5
> > > > HC Async Cilent: org.apache.hc.asyncclient5
> > > >
> > > > Clean and simple. Each project would be scoped in its namespace. Picking up
> > > > sebb's opinion, we even reflect the HTTP domain in the package name.
> > >
> > > It's not just my _opinion_.
> > > We cannot freely choose the package name, because we are not the only
> > > Java project in the world, nor even in the org.apache namespace.
> > >
> > > Likewise we cannot use the domain com.oracle or com.ibm or even com.apache.
> > > We MUST use the ASF domain as the package name prefix or there is a
> > > risk of clashes with 3rd party software.
> > >
> > > org.apache.hc should be OK, since we already use HC for the website.
> > > It's very unlikely that any other ASF project will be named HC.
> > >
> >
> > Would this be all right for everyone?
> >
> > org.apache.hc.core5.http
>
> Why do you want to use the redundant 'http'?
While not very likely we might have non HTTP protocol support as well,
such as Websockets.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Re: HC 5.0: co-location with HC 4.x
Posted by Michael Osipov <19...@gmx.net>.
> On Thu, 2015-11-19 at 23:27 +0000, sebb wrote:
> > On 19 November 2015 at 21:17, Michael Osipov <mi...@apache.org> wrote:
> > > Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski:
>
> ...
>
> > >
> > > First of all, I wouldn't use any of those. (Currently referring to package
> > > names only). Artifact ids are a different story.
> > >
> > > org.apache.http: that is too general and confuses me with Apache HTTP
> > > Server.
> > > org.apache.http.hc: http seems redundant here due to hc (http components).
> > > org.apache.hc<n>.http: same here.
> > >
> > > I would do:
> > >
> > > HC Core: org.apache.hc.core5
> > > HC Client: org.apache.hc.client5
> > > HC Async Cilent: org.apache.hc.asyncclient5
> > >
> > > Clean and simple. Each project would be scoped in its namespace. Picking up
> > > sebb's opinion, we even reflect the HTTP domain in the package name.
> >
> > It's not just my _opinion_.
> > We cannot freely choose the package name, because we are not the only
> > Java project in the world, nor even in the org.apache namespace.
> >
> > Likewise we cannot use the domain com.oracle or com.ibm or even com.apache.
> > We MUST use the ASF domain as the package name prefix or there is a
> > risk of clashes with 3rd party software.
> >
> > org.apache.hc should be OK, since we already use HC for the website.
> > It's very unlikely that any other ASF project will be named HC.
> >
>
> Would this be all right for everyone?
>
> org.apache.hc.core5.http
Why do you want to use the redundant 'http'?
Alternatively, one could use org.apache.httpcomponents.core5.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: co-location with HC 4.x
Posted by "Asankha C. Perera" <as...@apache.org>.
On 11/20/2015 04:20 PM, Oleg Kalnichevski wrote:
> On Thu, 2015-11-19 at 23:27 +0000, sebb wrote:
>> On 19 November 2015 at 21:17, Michael Osipov <mi...@apache.org> wrote:
>>> Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski:
> ...
>
>>> First of all, I wouldn't use any of those. (Currently referring to package
>>> names only). Artifact ids are a different story.
>>>
>>> org.apache.http: that is too general and confuses me with Apache HTTP
>>> Server.
>>> org.apache.http.hc: http seems redundant here due to hc (http components).
>>> org.apache.hc<n>.http: same here.
>>>
>>> I would do:
>>>
>>> HC Core: org.apache.hc.core5
>>> HC Client: org.apache.hc.client5
>>> HC Async Cilent: org.apache.hc.asyncclient5
>>>
>>> Clean and simple. Each project would be scoped in its namespace. Picking up
>>> sebb's opinion, we even reflect the HTTP domain in the package name.
>> It's not just my _opinion_.
>> We cannot freely choose the package name, because we are not the only
>> Java project in the world, nor even in the org.apache namespace.
>>
>> Likewise we cannot use the domain com.oracle or com.ibm or even com.apache.
>> We MUST use the ASF domain as the package name prefix or there is a
>> risk of clashes with 3rd party software.
>>
>> org.apache.hc should be OK, since we already use HC for the website.
>> It's very unlikely that any other ASF project will be named HC.
>>
> Would this be all right for everyone?
>
> org.apache.hc.core5.http
+1
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: co-location with HC 4.x
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2015-11-19 at 23:27 +0000, sebb wrote:
> On 19 November 2015 at 21:17, Michael Osipov <mi...@apache.org> wrote:
> > Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski:
...
> >
> > First of all, I wouldn't use any of those. (Currently referring to package
> > names only). Artifact ids are a different story.
> >
> > org.apache.http: that is too general and confuses me with Apache HTTP
> > Server.
> > org.apache.http.hc: http seems redundant here due to hc (http components).
> > org.apache.hc<n>.http: same here.
> >
> > I would do:
> >
> > HC Core: org.apache.hc.core5
> > HC Client: org.apache.hc.client5
> > HC Async Cilent: org.apache.hc.asyncclient5
> >
> > Clean and simple. Each project would be scoped in its namespace. Picking up
> > sebb's opinion, we even reflect the HTTP domain in the package name.
>
> It's not just my _opinion_.
> We cannot freely choose the package name, because we are not the only
> Java project in the world, nor even in the org.apache namespace.
>
> Likewise we cannot use the domain com.oracle or com.ibm or even com.apache.
> We MUST use the ASF domain as the package name prefix or there is a
> risk of clashes with 3rd party software.
>
> org.apache.hc should be OK, since we already use HC for the website.
> It's very unlikely that any other ASF project will be named HC.
>
Would this be all right for everyone?
org.apache.hc.core5.http
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: HC 5.0: co-location with HC 4.x
Posted by sebb <se...@gmail.com>.
On 19 November 2015 at 21:17, Michael Osipov <mi...@apache.org> wrote:
> Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski:
>>
>> 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?
>
>
> Finally -- at long last. This is something I had in mind for more than six
> months now. The current approach taken by Apache Commons saved me tons of
> work rewriting third party components just for namespace clashes. At some
> point, I had a dependency on a third party, closed source library which
> still uses HttpClient 3.x (!). Impossible to use 4.x. I had to reverse
> engineer the calls and reimplement them from scratch. Wasted two weeks for
> that.
>
> I would highly favor a package change/bump every major release. That would
> give everyone the ability to update at their own pace w/o waiting for third
> parties, etc.
>
>> 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?
>
>
> First of all, I wouldn't use any of those. (Currently referring to package
> names only). Artifact ids are a different story.
>
> org.apache.http: that is too general and confuses me with Apache HTTP
> Server.
> org.apache.http.hc: http seems redundant here due to hc (http components).
> org.apache.hc<n>.http: same here.
>
> I would do:
>
> HC Core: org.apache.hc.core5
> HC Client: org.apache.hc.client5
> HC Async Cilent: org.apache.hc.asyncclient5
>
> Clean and simple. Each project would be scoped in its namespace. Picking up
> sebb's opinion, we even reflect the HTTP domain in the package name.
It's not just my _opinion_.
We cannot freely choose the package name, because we are not the only
Java project in the world, nor even in the org.apache namespace.
Likewise we cannot use the domain com.oracle or com.ibm or even com.apache.
We MUST use the ASF domain as the package name prefix or there is a
risk of clashes with 3rd party software.
org.apache.hc should be OK, since we already use HC for the website.
It's very unlikely that any other ASF project will be named HC.
> Michael
>
>
> ---------------------------------------------------------------------
> 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: co-location with HC 4.x
Posted by Michael Osipov <mi...@apache.org>.
Am 2015-11-19 um 12:32 schrieb Oleg Kalnichevski:
> 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?
Finally -- at long last. This is something I had in mind for more than
six months now. The current approach taken by Apache Commons saved me
tons of work rewriting third party components just for namespace
clashes. At some point, I had a dependency on a third party, closed
source library which still uses HttpClient 3.x (!). Impossible to use
4.x. I had to reverse engineer the calls and reimplement them from
scratch. Wasted two weeks for that.
I would highly favor a package change/bump every major release. That
would give everyone the ability to update at their own pace w/o waiting
for third parties, etc.
> 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?
First of all, I wouldn't use any of those. (Currently referring to
package names only). Artifact ids are a different story.
org.apache.http: that is too general and confuses me with Apache HTTP
Server.
org.apache.http.hc: http seems redundant here due to hc (http components).
org.apache.hc<n>.http: same here.
I would do:
HC Core: org.apache.hc.core5
HC Client: org.apache.hc.client5
HC Async Cilent: org.apache.hc.asyncclient5
Clean and simple. Each project would be scoped in its namespace. Picking
up sebb's opinion, we even reflect the HTTP domain in the package name.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org