[GitHub] [httpcomponents-core] michael-o edited a comment on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods.
michael-o edited a comment on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods. URL: https://github.com/apache/httpcomponents-core/pull/189#issuecomment-575344260 @garydgregory There are several issue here, I will go in brief, but this discussion should really be on the dev list. 1. The class version freeze happened when 5.0 was started to be developed. This is a fair deal for everyone to have some long term planning. Yes, Java 7 has been overcome by events. Always consider that this is not a toy project. A LOT of people and software depend on it. I can show you 10 000+ users in my company using HttpClient 4.4.x every single day. 2. Generally, HttpComponents major release takes a long time due to the complexity/amount of code, little community (3-5 people) and being a backend library people only care when it is broken. 3. Java 8 is far not EOL, only Oracle's binary JDK is. There are plenty alternatives until 2025 for Java 8 on various platforms. What we could do is consider 5.0 as an interim release, fixing deficiencies of the 4.x line which will live for a year and then we make another baseline improvement, fix 5.x deficiencies and move to 6.0 with Java 8. Our turnarounds are slow, but this is not a bad thing. Moving fast does not mean you are delivering quality. As a side note, I don't understand the Operations approach either. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] michael-o commented on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods.
michael-o commented on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods. URL: https://github.com/apache/httpcomponents-core/pull/189#issuecomment-575344260 @garydgregory There are several issue here, I will go in brief, but this discussion should really be on the dev list. 1. The class version freeze happened when 5.0 was started to be developed. This is a fair deal for everyone to have some long term planning. Yes, Java 7 has been overcome by events. Always consider that this is not a toy project. A LOT of people and software depend on it. I can show you 10 000+ users in my company using HttpClient 4.4.x every single day. 2. Generally, HttpComponents major release takes a long time due to the complexity/amount of code, little community (3-5 people) and being a backend library people only care when it is broken. 3. Java 8 is far not EOL, only Oracle's binary JDK is. There are plenty alternatives until 2025 for Java 8 on various platforms. What we could do is consider 5.0 as an interim release, fixing deficiencies of the 4.x line which will live for a year and then we make another baseline improvement, fix 5.x deficiencies and move to 6.0 with Java 8. Our turnarounds are slow, but this is not a bad thing. Moving fast does not mean you are delivering quality. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] garydgregory edited a comment on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods.
garydgregory edited a comment on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods. URL: https://github.com/apache/httpcomponents-core/pull/189#issuecomment-575309825 @ok2c & @michael-o I will see your separation of concerns and raise you breaking encapsulation ;-) Let's step back, look at this from the 10,000 ft level and dive back in. Why do we even have a `TimeValue` class? Because for some completely absurd reason we are planning to release a MAJOR NEW version of a library, in 2020, based on Java 7. This means we cannot use Java 8's `java.util.Duration` class. We are actually telling people that Java 7 is so important that it is OK to create new projects that depend on Java 7 while even Java 8 is EOL. FWIW, a lof of the customers I see can't get to Java 11 fast enough. To make matters worse, we are talking of requiring Java 8 for 5.1. So as soon as that happens people are naturally going to see TimeValue instead of Duration all over our API and wonder what kind of silliness that is. Once 5.0 is out, the API is set in stone, so for playing nice with Java 8, we'd have to add Duration APIs where we have TimeValue. Not a pretty sight. So, now, back down to the bits. We've had to open up the guts of TimeValue with accessors like getDuration() and getTimeUnit() in order to play nice with API that take a long and a TimeUnit. That's not pretty and I claim this kind of pattern effectively breaks (in call sites) the encapsulation offered by the TimeValue abstraction. So instead of all call sites cracking a TimeValue egg open each time it needs to call some JRE concurrent APIs, I though it cleaner to flip the call around as this PR provides. You can see, especially in the tests, how much the call sites are cleaned up by this, that's IMO YMMV of course. If it were up to me, I'd make 5.0 depend on Java 8 and use Duration instead of TimeValue. Bam! Simple, expected, done. Thoughts? Gary PS: The comment "Please move those methods into a separate class similar to Operations in client." makes no sense to me; the whole point is to avoid cracking open a TimeValue in the first place. G This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] garydgregory edited a comment on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods.
garydgregory edited a comment on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods. URL: https://github.com/apache/httpcomponents-core/pull/189#issuecomment-575309825 @ok2c & @michael-o I will see your separation of concerns and raise you breaking encapsulation ;-) Let's step back, look at this from the 10,000 ft level and dive back in. Why do we even have a `TimeValue` class? Because for some completely absurd reason we are planning to release a MAJOR NEW version of a library, in 2020, based on Java 7. This means we cannot use Java 8's `java.util.Duration` class. We are actually telling people that Java 7 is so important that it is OK to create new projects that depend on Java 7 while even Java 8 is EOL. FWIW, a lof of the customers I see can't get to Java 11 fast enough. To make matters worse, we are talking of requiring Java 8 for 5.1. So as soon as that happens people are naturally going to see TimeValue instead of Duration all over our API and wonder what kind of silliness that is. Once 5.0 is out, the API is set in stone, so for playing nice with Java 8, we'd have to add Duration APIs where we have TimeValue. Not a pretty sight. So, now, back down to the bits. We've had to open up the guts of TimeValue with accessors like getDuration() and getTimeUnit() in order to play nice with API that take a long and a TimeUnit. That's not pretty and I claim this kind of pattern effectively breaks (in call sites) the encapsulation offered by the TimeValue abstraction. So instead of all call sites cracking a TimeValue egg open each time it needs to call some JRE concurrent APIs, I though it cleaner to flip the call around as this PR provides. You can see, especially in the tests, how much the call sites are cleaned up by this, that's IMO YMMV of course. If it were up to me, I'd make 5.0 depend on Java 8 and use Duration instead of TimeValue. Bam! Simple, expected, done. The comment "Please move those methods into a separate class similar to Operations in client." makes no sense to me; the whole point is to avoid cracking open a TimeValue in the first place. Thoughts? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] garydgregory commented on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods.
garydgregory commented on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods. URL: https://github.com/apache/httpcomponents-core/pull/189#issuecomment-575309825 @ok2c & @michael-o I will see your separation of concerns and raise you breaking encapsulation ;-) Let's step back, look at this from the 10,000 ft level and dive back in. Why do we even have a `TimeValue` class? Because for some completely absurd reason we are planning to release a MAJOR NEW version of a library, in 2020, based on Java 7. This means we cannot use Java 8's `java.util.Duration` class. We are actually telling people that Java 7 is so important that it is OK to create new projects that depend on Java 7 while even Java 8 is EOL. FWIW, a lof of the customers I see can't get to Java 11 fast enough. To make matters worse, we are talking of requiring Java 8 for 5.1. So as soon as that happens people are naturally going to see TimeValue instead of Duration all over our API and wonder what kind of silliness that is. Once 5.0 is out, the API is set in stone, so for playing nice with Java 8, we'd have to add Duration APIs where we have TimeValue. Not a pretty sight. So, now, back down to the bits. We've had to open up the guts of TimeValue with accessors like getDuration() and getTimeUnit() in order to play nice with API that take a long and a TimeUnit. That's not pretty and I claim this kind of pattern effectively breaks (in call sites) the encapsulation offered by the TimeValue abstraction. So instead of all call sites cracking a TimeValue egg open each time it needs to call some JRE concurrent APIs, I though it cleaner to flip the call around as this PR provides. You can see, especially in the tests, how much the call sites are cleaned up by this, that's IMO YMMV of course. If it were up to me, I'd make 5.0 depend on Java 8 and use Duration instead of TimeValue. Bam! Simple, expected, done. Thoughts? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: [VOTE] Release HttpClient 4.5.11 based on RC1
Am 2020-01-15 um 11:51 schrieb Oleg Kalnichevski: Please vote on releasing these packages as HttpClient 4.5.11. The vote is open for the at least 72 hours, and only votes from HttpComponents PMC members are binding. The vote passes if at least three binding +1 votes are cast and there are more +1 than -1 votes. Release notes: https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-4.5.11-RC1/RELEASE_NOTES-4.5.x.txt Maven artefacts: https://repository.apache.org/content/repositories/orgapachehttpcomponents-1109/org/apache/httpcomponents/ Git Tag: 4.5.11-RC1 https://github.com/apache/httpcomponents-client/tree/4.5.11-RC1 Packages: https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-4.5.11-RC1 revision 37630 Hashes: 9fda03d1d3a43425ddca4abcdcaf3951daf9d1653ccb31cdd712fea9be91fc1c01e4577c6ec3cd6f40ebe7e6fdcb15bcdb3badc947141717011ec2f4f536bef3 httpcomponents-client-4.5.11-src.zip 5f7d9c33a34cc72e9401a6f2454019d8343f93a78ab5d086afc0c587776676f009f4e0fe7153fd1037ed1a976174ac9177b7c5da0b66ec9c42f1a5ab3d9339a6 httpcomponents-client-4.5.11-bin.tar.gz ad1d48b8bcb70ad68232300d7395582964409cf3933f0bd6ccd0f5aecab10aeb11b971710006b6819af7877a1b6426e31524b9f772da4ecb5faa2cc292a385ad httpcomponents-client-4.5.11-bin.zip e2f005a7866ac0cb6d8d7c1b0d9d516cd28f6f175722a48d3ec86e63d5af6ff9df633aee1e736453ea4360a12abfbdc7e1cf9e9b8b3fac5229ffcad3eebe376f httpcomponents-client-4.5.11-src.tar.gz Keys: http://www.apache.org/dist/httpcomponents/httpclient/KEYS -- Vote: HttpClient 4.5.11 release [ ] +1 Release the packages as HttpClient 4.5.11. [ ] -1 I am against releasing the packages (must include a reason). +1 - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: [VOTE] Release HttpClient 4.5.11 based on RC1
+1
Based on the git tag.
- Apache RAT check OK
- Apache CLIRR check OK
- Building OK with 'mvn -V clean package' using with the Maven tool chain
containing Oracle Java 1.7.0_80:
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Java\apache-maven-3.6.3\bin\..
Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_231\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
- Building OK with 'mvn -V clean package -P!use-toolchains' using:
Maven home: C:\Java\apache-maven-3.6.3\bin\..
Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_231\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
A Java 11 build blows up on a ton of Javadoc errors.
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Java\apache-maven-3.6.3\bin\..
Java version: 11.0.5, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk-11.0.5
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
[INFO]
[INFO] Reactor Summary for Apache HttpComponents Client 4.5.11:
[INFO]
[INFO] Apache HttpComponents Client ... SUCCESS [
21.096 s]
[INFO] Apache HttpClient .. FAILURE [02:29
min]
[INFO] Apache HttpClient Mime . SKIPPED
[INFO] Apache HttpClient Fluent API ... SKIPPED
[INFO] Apache HttpClient Cache SKIPPED
[INFO] Apache HttpClient Windows features . SKIPPED
[INFO] Apache HttpClient OSGi bundle .. SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 02:56 min
[INFO] Finished at: 2020-01-15T21:57:45-05:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:jar (attach-javadocs)
on project httpclient: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - javadoc: error - The code being documented uses
modules but the packages defined in
https://docs.oracle.com/javase/6/docs/api/ are in the unnamed module.
[ERROR] javadoc: error - The code being documented uses modules but the
packages defined in https://docs.oracle.com/javase/6/docs/api/ are in the
unnamed module.
[ERROR]
C:\temp\rc\httpcomponents-client\httpclient\src\main\java\org\apache\http\impl\client\HttpRequestFutureTask.java:37:
warning: no description for @param
[ERROR] * @param
[ERROR]^
[ERROR]
C:\temp\rc\httpcomponents-client\httpclient\src\main\java-deprecated\org\apache\http\impl\client\SystemDefaultHttpClient.java:68:
warning: empty tag
[ERROR] *
[ERROR]^
[ERROR]
C:\temp\rc\httpcomponents-client\httpclient\src\main\java\org\apache\http\auth\AuthScheme.java:67:
warning: no @throws for org.apache.http.auth.MalformedChallengeException
[ERROR] void processChallenge(final Header header) throws
MalformedChallengeException;
[ERROR] ^
[ERROR]
C:\temp\rc\httpcomponents-client\httpclient\src\main\java\org\apache\http\auth\AuthSchemeProvider.java:44:
warning: no @param for context
[ERROR] AuthScheme create(HttpContext context);
[ERROR]^
[ERROR]
C:\temp\rc\httpcomponents-client\httpclient\src\main\java\org\apache\http\auth\AuthScope.java:180:
warning: no @param for authscope
[ERROR] public AuthScope(final AuthScope authscope) {
[ERROR]^
[ERROR]
C:\temp\rc\httpcomponents-client\httpclient\src\main\java\org\apache\http\auth\AuthScope.java:234:
warning: no @param for that
[ERROR] public int match(final AuthScope that) {
[ERROR]^
[ERROR]
C:\temp\rc\httpcomponents-client\httpclient\src\main\java\org\apache\http\auth\AuthState.java:76:
warning: no @return
[ERROR] public AuthProtocolState getState() {
[ERROR] ^
[ERROR]
C:\temp\rc\httpcomponents-client\httpclient\src\main\java\org\apache\http\auth\AuthState.java:83:
warning: no @param for state
[ERROR] public void setState(final AuthProtocolState state) {
[ERROR] ^
[ERROR]
C:\temp\rc\httpcomponents-client\httpclient\src\main\java\org\apache\http\auth\AuthState.java:90:
warning: no @return
[ERROR] public AuthScheme getAuthScheme() {
[ERROR] ^
[ERROR]
C:\temp\rc\httpcomponents-client\httpclient\src\main\java\org\apache\http\auth\AuthState.java:97:
warning: no @return
[ERROR] public Credentials getCredentials() {
[ERROR]^
[ERROR]
C:\temp\rc\httpcomponents-client\httpclient\src\main\java\org\apache\http\au
[GitHub] [httpcomponents-core] michael-o removed a comment on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods.
michael-o removed a comment on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods. URL: https://github.com/apache/httpcomponents-core/pull/189#issuecomment-575063960 @ok2c I absolutely agree here. Separation of concerns must apply here. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: [VOTE] Release HttpClient 4.5.11 based on RC1
[x] +1 Release the packages as HttpClient 4.5.11 On Wed, 2020-01-15 at 11:51 +0100, Oleg Kalnichevski wrote: > Please vote on releasing these packages as HttpClient 4.5.11. > The vote is open for the at least 72 hours, and only votes from > HttpComponents PMC members are binding. The vote passes if at least > three binding +1 votes are cast and there are more +1 than -1 votes. > > Release notes: > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-4.5.11-RC1/RELEASE_NOTES-4.5.x.txt > > Maven artefacts: > > https://repository.apache.org/content/repositories/orgapachehttpcomponents-1109/org/apache/httpcomponents/ > > Git Tag: 4.5.11-RC1 > https://github.com/apache/httpcomponents-client/tree/4.5.11-RC1 > > Packages: > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-4.5.11-RC1 > revision 37630 > > Hashes: > 9fda03d1d3a43425ddca4abcdcaf3951daf9d1653ccb31cdd712fea9be91fc1c01e4 > 577c6ec3cd6f40ebe7e6fdcb15bcdb3badc947141717011ec2f4f536bef3 > httpcomponents-client-4.5.11-src.zip > 5f7d9c33a34cc72e9401a6f2454019d8343f93a78ab5d086afc0c587776676f009f4 > e0fe7153fd1037ed1a976174ac9177b7c5da0b66ec9c42f1a5ab3d9339a6 > httpcomponents-client-4.5.11-bin.tar.gz > ad1d48b8bcb70ad68232300d7395582964409cf3933f0bd6ccd0f5aecab10aeb11b9 > 71710006b6819af7877a1b6426e31524b9f772da4ecb5faa2cc292a385ad > httpcomponents-client-4.5.11-bin.zip > e2f005a7866ac0cb6d8d7c1b0d9d516cd28f6f175722a48d3ec86e63d5af6ff9df63 > 3aee1e736453ea4360a12abfbdc7e1cf9e9b8b3fac5229ffcad3eebe376f > httpcomponents-client-4.5.11-src.tar.gz > > Keys: > http://www.apache.org/dist/httpcomponents/httpclient/KEYS > > --- > --- > Vote: HttpClient 4.5.11 release > [ ] +1 Release the packages as HttpClient 4.5.11. > [ ] -1 I am against releasing the packages (must include a reason). > > > - > 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
[GitHub] [httpcomponents-core] michael-o commented on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods.
michael-o commented on issue #189: Add and use TimeValue await(), awaitTermination() and get() methods. URL: https://github.com/apache/httpcomponents-core/pull/189#issuecomment-575063960 @ok2c I absolutely agree here. Separation of concerns must apply here. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
