Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x
> 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
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
> 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: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x
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: Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x
> 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: Re: Re: HC 5.0: package / module structure; Re: HC 5.0: co-location with HC 4.x
> 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
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
