HC 5.0: artifact id; Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[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.

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
> > org.apache.http.hc
> > org.apache.hc.http
> > where  is a major release version
> > 
> > Something else? Any thoughts or preferences?
> > 
> > Oleg
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> > For additional commands, e-mail: dev-h...@hc.apache.org
> > 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
> 



-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@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

[Michael Osipov]

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
org.apache.http.hc
org.apache.hc.http
where  is a major release version

Something else? Any thoughts or preferences?

Oleg


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





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





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





-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@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

[Gary Gregory]

On Wed, Nov 25, 2015 at 12:03 PM, Michael Osipov 
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
 org.apache.http.hc
 org.apache.hc.http
 where  is a major release version

 Something else? Any thoughts or preferences?

 Oleg


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


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


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
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

[Michael Osipov]

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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[sebb]

On 23 November 2015 at 09:46, Michael Osipov <1983-01...@gmx.net> wrote:
>> On Mon, 2015-11-23 at 10:08 +0100, Michael Osipov wrote:
>> > > On Sun, Nov 22, 2015 at 3:10 PM, Jon Moore  wrote:
>> > >
>> > > > On Sat, Nov 21, 2015 at 1:56 PM, Michael Osipov 
>> > > > wrote:
>> > > >
>> > > > > 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.
>> > > >
>> > >
>> > > By the time, HC5 comes out, Java 9 might be out ;-)
>> > >
>> > > I think it is time to move to Java 8, which might also attract fresh 
>> > > blood
>> > > to the project.
>> >
>> > Gary,
>> >
>> > if you have seen those screencaps from Devoxx in Belgium you would know 
>> > that Java 9 brings
>> > the most tremendous changes since the inception of Java (citing Mark 
>> > Reinhold). This is
>> > too much changes for just one release.
>> >
>> > Moreover, I highly against moving to Java 8 right now becuase too many 
>> > people have constraints
>> > to move to a new major Java version. Withhelding them from upgrade to 5.0 
>> > just because of that
>> > would create a chicken-end-egg problem.
>> >
>> > Given that this project has only few active developers, we should rather 
>> > focus on onther issues.
>> >
>> > For instance, at Maven there are probably working ten developers, yet we 
>> > have chosen to stick
>> > to Java 7 for broad compat.
>> >
>> > Michael
>> >
>>
>> Folks
>>
>> I think it was probably a little more than year ago that Gradle folks
>> said they might have to consider forking HttpClient if we had moved to
>> Java 6 too soon. HC is a low level library. We risk losing a substantial
>> user base if we get too carried away with new Java features.
>
> That is exactly the type of issue I was referring to.
>
> JMeter is one of the most prominent users and still uses Java 6. I don't want
> JMeter to live with 4.x forever. Given that JMeter gave me a lot of freedom,
> I want to give a lot back.
>

JMeter trunk now requires Java 7 (see
https://bz.apache.org/bugzilla/show_bug.cgi?id=57981)

This was done because Java 6 was lacking some functionality that we
needed, e.g. in keytool

Note that JMeter is very different from a low-level library such as HC.
It should generally be run on its own host, so requiring a later
version of Java is not usually a problem (so long as the release is
generally available).
However, we have not yet required the use of Java 8, because there is
no pressing need to do so.

Requiring Java 8 for HC may cause problems for some users of JMeter,
but there is an easy workround - just run JMeter using Java 8.
This is possible because JMeter is a stand-alone app.

This is not however possible in general for other applications that
depend on HC; the hosts on which they have to run may not be
upgradeable yet.

>> I loathe having to go back to Java 7 from Java 8 every time work on
>> HttpClient. Really. But let's revisit this decision in a few month time.
>> We might be forced to upgrade due to HTTP/2 TLS requirements.
>
> If so, we should consider providing this as a separate, pluggable module 
> compiled with Java 8 while
> the rest can happily work with Java 7.

+1

> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

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

Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

> On Sun, Nov 22, 2015 at 3:10 PM, Jon Moore  wrote:
> 
> > On Sat, Nov 21, 2015 at 1:56 PM, Michael Osipov 
> > wrote:
> >
> > > 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.
> >
> 
> By the time, HC5 comes out, Java 9 might be out ;-)
> 
> I think it is time to move to Java 8, which might also attract fresh blood
> to the project.

Gary,

if you have seen those screencaps from Devoxx in Belgium you would know that 
Java 9 brings
the most tremendous changes since the inception of Java (citing Mark Reinhold). 
This is
too much changes for just one release.

Moreover, I highly against moving to Java 8 right now becuase too many people 
have constraints
to move to a new major Java version. Withhelding them from upgrade to 5.0 just 
because of that
would create a chicken-end-egg problem.

Given that this project has only few active developers, we should rather focus 
on onther issues.

For instance, at Maven there are probably working ten developers, yet we have 
chosen to stick
to Java 7 for broad compat.

Michael

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

Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Oleg Kalnichevski]

On Mon, 2015-11-23 at 10:08 +0100, Michael Osipov wrote:
> > On Sun, Nov 22, 2015 at 3:10 PM, Jon Moore  wrote:
> > 
> > > On Sat, Nov 21, 2015 at 1:56 PM, Michael Osipov 
> > > wrote:
> > >
> > > > 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.
> > >
> > 
> > By the time, HC5 comes out, Java 9 might be out ;-)
> > 
> > I think it is time to move to Java 8, which might also attract fresh blood
> > to the project.
> 
> Gary,
> 
> if you have seen those screencaps from Devoxx in Belgium you would know that 
> Java 9 brings
> the most tremendous changes since the inception of Java (citing Mark 
> Reinhold). This is
> too much changes for just one release.
> 
> Moreover, I highly against moving to Java 8 right now becuase too many people 
> have constraints
> to move to a new major Java version. Withhelding them from upgrade to 5.0 
> just because of that
> would create a chicken-end-egg problem.
> 
> Given that this project has only few active developers, we should rather 
> focus on onther issues.
> 
> For instance, at Maven there are probably working ten developers, yet we have 
> chosen to stick
> to Java 7 for broad compat.
> 
> Michael
> 

Folks

I think it was probably a little more than year ago that Gradle folks
said they might have to consider forking HttpClient if we had moved to
Java 6 too soon. HC is a low level library. We risk losing a substantial
user base if we get too carried away with new Java features.

I loathe having to go back to Java 7 from Java 8 every time work on
HttpClient. Really. But let's revisit this decision in a few month time.
We might be forced to upgrade due to HTTP/2 TLS requirements.

Oleg


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

Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

> 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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

> 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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

> On Mon, 2015-11-23 at 10:08 +0100, Michael Osipov wrote:
> > > On Sun, Nov 22, 2015 at 3:10 PM, Jon Moore  wrote:
> > > 
> > > > On Sat, Nov 21, 2015 at 1:56 PM, Michael Osipov 
> > > > wrote:
> > > >
> > > > > 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.
> > > >
> > > 
> > > By the time, HC5 comes out, Java 9 might be out ;-)
> > > 
> > > I think it is time to move to Java 8, which might also attract fresh blood
> > > to the project.
> > 
> > Gary,
> > 
> > if you have seen those screencaps from Devoxx in Belgium you would know 
> > that Java 9 brings
> > the most tremendous changes since the inception of Java (citing Mark 
> > Reinhold). This is
> > too much changes for just one release.
> > 
> > Moreover, I highly against moving to Java 8 right now becuase too many 
> > people have constraints
> > to move to a new major Java version. Withhelding them from upgrade to 5.0 
> > just because of that
> > would create a chicken-end-egg problem.
> > 
> > Given that this project has only few active developers, we should rather 
> > focus on onther issues.
> > 
> > For instance, at Maven there are probably working ten developers, yet we 
> > have chosen to stick
> > to Java 7 for broad compat.
> > 
> > Michael
> > 
> 
> Folks
> 
> I think it was probably a little more than year ago that Gradle folks
> said they might have to consider forking HttpClient if we had moved to
> Java 6 too soon. HC is a low level library. We risk losing a substantial
> user base if we get too carried away with new Java features.

That is exactly the type of issue I was referring to.

JMeter is one of the most prominent users and still uses Java 6. I don't want
JMeter to live with 4.x forever. Given that JMeter gave me a lot of freedom,
I want to give a lot back.
 
> I loathe having to go back to Java 7 from Java 8 every time work on
> HttpClient. Really. But let's revisit this decision in a few month time.
> We might be forced to upgrade due to HTTP/2 TLS requirements.

If so, we should consider providing this as a separate, pluggable module 
compiled with Java 8 while
the rest can happily work with Java 7.

Michael

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

Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Oleg Kalnichevski]

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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Oleg Kalnichevski]

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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Jon Moore]

On Sat, Nov 21, 2015 at 1:56 PM, Michael Osipov  wrote:

> 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.


Java 7 is already end-of-life, as of April 2015. Given that part of the
idea of starting version 5.0 is to be able to remove deprecated items and
general cleanup, it would seem prudent to me to at least *start* HC 5.0
with a non-EOL Java version. In addition, the Streams API that were added
to in java.util.streams might be very useful especially in an HTTP/2.0
implementation, although that might be a separate discussion.

I will also note that you should weigh my opinion against the fact that I
haven't had a lot of time for contributing recently...

Jon

Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Gary Gregory]

On Sun, Nov 22, 2015 at 3:10 PM, Jon Moore  wrote:

> On Sat, Nov 21, 2015 at 1:56 PM, Michael Osipov 
> wrote:
>
> > 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.
>

By the time, HC5 comes out, Java 9 might be out ;-)

I think it is time to move to Java 8, which might also attract fresh blood
to the project.

My 2c,
Gary


>
>
> Java 7 is already end-of-life, as of April 2015. Given that part of the
> idea of starting version 5.0 is to be able to remove deprecated items and
> general cleanup, it would seem prudent to me to at least *start* HC 5.0
> with a non-EOL Java version. In addition, the Streams API that were added
> to in java.util.streams might be very useful especially in an HTTP/2.0
> implementation, although that might be a separate discussion.
>
> I will also note that you should weigh my opinion against the fact that I
> haven't had a lot of time for contributing recently...
>
> Jon
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[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.

Cheers

Oleg



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

HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[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.

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
> org.apache.http.hc
> org.apache.hc.http
> where  is a major release version
> 
> Something else? Any thoughts or preferences?
> 
> Oleg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
> 



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

Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

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"  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
org.apache.http.hc
org.apache.hc.http
where  is a major release version

Something else? Any thoughts or preferences?

Oleg


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





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







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

Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

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
org.apache.http.hc
org.apache.hc.http
where  is a major release version

Something else? Any thoughts or preferences?

Oleg


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





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





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

Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x

[Gary Gregory]

+1.

I would not mind using Java 8 too.

Gary
On Nov 21, 2015 9:03 AM, "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
> > org.apache.http.hc
> > org.apache.hc.http
> > where  is a major release version
> >
> > Something else? Any thoughts or preferences?
> >
> > Oleg
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> > For additional commands, e-mail: dev-h...@hc.apache.org
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>

Re: Re: Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

> On Fri, 2015-11-20 at 12:42 +0100, Michael Osipov wrote:
> > > On Thu, 2015-11-19 at 23:27 +, sebb wrote:
> > > > On 19 November 2015 at 21:17, Michael Osipov  
> > > > 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.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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

> On Thu, 2015-11-19 at 23:27 +, sebb wrote:
> > On 19 November 2015 at 21:17, Michael Osipov  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.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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: HC 5.0: co-location with HC 4.x

[Oleg Kalnichevski]

On Thu, 2015-11-19 at 23:27 +, sebb wrote:
> On 19 November 2015 at 21:17, Michael Osipov  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.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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: HC 5.0: co-location with HC 4.x

[Asankha C. Perera]

On 11/20/2015 04:20 PM, Oleg Kalnichevski wrote:

On Thu, 2015-11-19 at 23:27 +, sebb wrote:

On 19 November 2015 at 21:17, Michael Osipov  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.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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Re: HC 5.0: co-location with HC 4.x

[Oleg Kalnichevski]

On Fri, 2015-11-20 at 12:42 +0100, Michael Osipov wrote:
> > On Thu, 2015-11-19 at 23:27 +, sebb wrote:
> > > On 19 November 2015 at 21:17, Michael Osipov  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.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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: Re: Re: HC 5.0: co-location with HC 4.x

[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 +, sebb wrote:
> > > > > On 19 November 2015 at 21:17, Michael Osipov  
> > > > > 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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: HC 5.0: co-location with HC 4.x

[Gary Gregory]

On Fri, Nov 20, 2015 at 2:50 AM, Oleg Kalnichevski  wrote:

> On Thu, 2015-11-19 at 23:27 +, sebb wrote:
> > On 19 November 2015 at 21:17, Michael Osipov 
> 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.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-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

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 +, sebb wrote:

On 19 November 2015 at 21:17, Michael Osipov  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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: HC 5.0: co-location with HC 4.x

[Gary Gregory]

On Fri, Nov 20, 2015 at 10:04 AM, 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 +, sebb wrote:
>>
>>> On 19 November 2015 at 21:17, Michael Osipov 
>>> 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-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

Am 2015-11-20 um 19:38 schrieb Gary Gregory:

On Fri, Nov 20, 2015 at 10:04 AM, 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 +, sebb wrote:



On 19 November 2015 at 21:17, Michael Osipov 
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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: HC 5.0: co-location with HC 4.x

[Oleg Kalnichevski]

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 +, sebb wrote:
> >> On 19 November 2015 at 21:17, Michael Osipov  
> >> 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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: HC 5.0: co-location with HC 4.x

[Michael Osipov]

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
org.apache.http.hc
org.apache.hc.http
where  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.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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: HC 5.0: co-location with HC 4.x

[sebb]

On 19 November 2015 at 21:17, Michael Osipov  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
>> org.apache.http.hc
>> org.apache.hc.http
>> where  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.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-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

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

Re: HC 5.0: co-location with HC 4.x

[sebb]

On 19 November 2015 at 11:32, 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
> org.apache.http.hc
> org.apache.hc.http
> where  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

Commons uses the artifactId to distinguish different release versions,
keeping the same GID.


> Oleg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

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