Raise the Netty 5 minimum required Java version to Java 11.
Motivation:
Java 11 has been out for some time, and Netty 5 is still some ways out.
There are also many good features in Java 11 that we wish to use, such as VarHandles, var-keyword, and the module system.
There is no reason for Netty 5 to not require Java 11, since Netty 4.x will still be supported for the time being.
Modification:
Remove everything in the pom files related to Java versions older than Java 11.
Remove the animal-sniffer plug-in and rely on the `--release` compiler flag instead.
Remove docker files related to Java versions older than Java 11.
Remove the copied SCTP APIs -- we should test this commit independently on Windows.
Remove the OpenJdkSelfSignedCertGenerator.java file and just always use Bouncy Castle for generating self-signed certificates for testing.
Make netty-testsuite tests pass by including Bouncy Castle as a test dependency, so we're able to generate our self-signed certificate.
Result:
Java 11 is now the minimum required Java version.
Motivation:
The builds often fail when downloading dependencies.
This might be caused by the build taking a long time, and cause pooled connections to be closed
by the remote end, if they are idle for too long.
Modification:
Disable connection pooling. This should force Maven to reestablish the connection for each download,
thus reducing the likelihood of the remote end closing connections we wish to use.
Result:
I'll leave it up the statistis of our CI to confirm, but we should see more stable builds.
Motivation:
A new GraalVM with JDK 11 was released and GraalVM adds Java 11 support
Modification:
- Update GraalVM JDK 8 version
- Add GraalVM JDK 11 support
Result:
Build with GraalVM JDK 11 and use latest GraalVM JDK 8 version
Motivation:
`transport-native-epoll` doesn't have ARM release package.
Modification:
This PR added cross compile profile for epoll. Then we can easily build aarch64 package on X86 machine.
Result:
Fixes#8279
Motivation:
JDK 14 was released so we should include it in our build matrix. Beside this there was also a JDK 13 update
Modifications:
- Add docker-compose files for JDK 14
- Update JDK 13 version
Result:
Build with JDK 14 as well and use latest JDK 13 release
Motivation:
We should update the used java11 version when building via docker to the latest release
Modifications:
Update to 1.11.0-6
Result:
Use latest java11 version
Motivation:
We should use adaptjdk 13 and not oracle openjdk 13 when building with Java 13
Modifications:
Use adopt@1.13.0-0
Result:
More consistent java vendor usage
Motivation:
We should use the same java versions whenever we use CentOS 6 or 7 and also use the latest Java12 version
Modifications:
- Use same Java versions
- Use latest Java 12 version
- Remove old configs which are not used anymore
Result:
Docker cleanup
Motivation:
As we use the docker files for the CI we should use the delegated mount option to speed up builds.
See https://docs.docker.com/docker-for-mac/osxfs-caching/#delegated
Modifications:
Use delegated mount option
Result:
Faster builds when using docker
Motivation:
The first final version of GraalVM was released which deprecated some flags. We should use the new ones.
Modifications:
Removes the use of deprecated GraalVM native-image flags
Adds a flag to initialize netty at build time.
Result:
Do not use deprecated flags
Motivation:
We should use the latest EA release when trying to compile with JDK13.
Modifications:
Update to latest release
Result:
Test with latest release on the CI
Motivation:
We should try to compile / test with graalvm as well.
Modifications:
Add docker-compose file for graalvm
Result:
Be able to also compile / test with graalvm
Motivation:
There were new releases of various Java versions.
Modifications:
Adjust used java versions of the latest releases and so use these on our CI
Result:
Use latest java versions on our CI.
Motivation:
We recently changed the docker config to use adoptjdk builds but missed to include the docker-sync related files.
Modifications:
Use adoptjdk there as well.
Result:
More conistent usage of JDK versions.
Motivation:
docker-sync.io helps to speed up docker FS access on macOS and so make builds there a lot faster. We should add some config to help users use it.
Modifications:
Add docker-sync configs for centos-6.18 which is what we use for releases.
Result:
Faster builds via docker and when using macOS possible.
Motivation:
To ensure Netty works on different JVMs we should also run tests on the CI with these.
Modifications:
Add docker-compose config to run build with OpenJ9 JVM
Result:
Ensure Netty works with different JVMs
Motivation:
We use outdated EA releases when building and testing with JDK 12 and 13.
Modifications:
- Update versions.
- Add workaround for possible JDK12+ bug.
Result:
Use latest releases
Motivation:
We should always build with the latest JDK releases.
Modifications:
Update JDK8 and JDK11 versions to the latest.
Result:
Run CI jobs on the latest JDK release.
Motivation:
There are the first EA bulds for OpenJDK 13. We should support to build with it and run builds on the CI.
Modifications:
- Add profile for JDK 13
- Add docker config to run with JDK 13.
Result:
Building and testing with OpenJDK 13 is possible.
Motivation:
A new EA release was done for OpenJDK12.
Modifications:
Use OpenJDK12 EA 27 when running CI jobs for JDK 12.
Result:
Test against latest OpenJDK 12 EA build.
Motivation:
A new EA build was released for Java 12.
Modifications:
Update to OpenJDK 12 EA24
Result:
Use latest OpenJDK 12 build when building with Java 12
motivation: automate snapshot publishing from docker based ci
changes:
* add local settings.xml with env variables for publishing to sonatype-nexus-snapshots
* pipe UID/PWD env variable in docker compose
Motivation:
We should use the latest OpenJDK 12 release when running tests against Java12.
Modifications:
- Update to OpenJDK 12 ea22.
- Update pax exam version
- skip OSGI testsuite on Java12 as it does not work ea22 yet.
Result:
Use latest OpenJDK 12 version when running on the CI.
Motivation:
We should provide an easy way to run our testsuite against netty-tcnative-boringssl-static
Modifications:
- Add boringssl profile which can be used to enable usage of netty-tcnative-boringssl-static
- Make use of the profile in docker-compose
Result:
Cleaner and easier way of running testsuite against netty-tcnative-boringssl-static
Motivation:
A new EA release was done, we should always run against the latest.
Modifications:
Update to EA 16.
Result:
CI runs with latest EA release for JDK12.
Motivation:
2109f14c24 corrected how we run the testsuite with boringssl-static but missed to also adjust the testsuite-shading configuration which lead to test failures.
Modifications:
Correctly compose the native lib name when no classifier is used.
Result:
Testsuite passes again.
Motivation:
We should explicit specify the java version to use to ensure docker will rebuild the image once a new java version was released and we specify it. Also we should use openjdk for testing when possible.
Modifications:
- Explicit specify the java versions to use
- Use openjdk when possible.
Result:
Ensure latest java versions are used during testing
Motivation:
We publish an "uber-jar" for netty-tcnative-boringssl-static so we should use it when testing against boringssl.
Modifications:
Ensure we use empty classifier.
Result:
Use uber-jar when testing
Motivation:
The first EA builds for Java12 are released so we should allow to run with these in our docker-compose setup.
Modifications:
Add docker-compose configs for Java12.
Result:
Be able to run easily with Java12 as well.
Motivation:
We should add some command to be able to run all tests with leak detection enabled. This will then be used on the CI during PR builds.
Modifications:
Add new docker-compose config to run with leak-detection enabled.
Result:
Easy way to enable leak detection while running tests via docker.
Motivation:
We should ensure we use the latest Java11 EA during build to catch any regressions etc.
Modifications:
Update from ea19 to ea28.
Result:
Use latest Java11 release.
Motivation:
We also need to run our tests while using boringssl-static to ensure everything works when using it. Beside this its sometimes useful to be able to just get a shell and so interactive work in the docker instance.
Modifications:
- Add configs for shell
- Add configs for testing with boringssl-static
- Ensure we not share .m2 when running tests
Result:
More complete docker setup.
