Motivation:
42aa7f0c58 did update the checkstyle version but missed that we declared it explicitly in the all artifact as well.
Modifications:
Remove explicit definition in the all artifact.
Result:
Use latest checkstyle version everywhere.
Motivation:
On MacOS it is not really good enough to check /etc/resolv.conf to determine the nameservers to use. We should retrieve the nameservers using the same way as mDNSResponser and chromium does by doing a JNI call.
Modifications:
Add MacOSDnsServerAddressStreamProvider and testcase
Result:
Use correct nameservers by default on MacOS.
Motivation:
We need to also include the native-image configuration files in the netty all jar to be able to use it with GraalVM native.
Modifications:
Add files in META-INF/native-image as well
Result:
Fixes https://github.com/netty/netty/issues/9514
Motivation:
While building netty-all we should always include all classes for native transports no matter if the native part can be build or not. This was it is easier to test locally with a installed snapshot of netty-all when the code that uses it does enable a specific native transport depending on if the native bits can be loaded or not.
Modifications:
Always include classes of native transports no matter on which platfrom we build. When a release is done we ensure we include the native bits by using the uber-staging profile.
Result:
Easier testing with netty-all snapshots.
Motivation:
Netty is very widely used which can lead to a lot of pain when we break API / ABI. We should make use japicmp-maven-plugin during the build to verify we do not introduce breakage by mistake.
Modifications:
- Add japicmp-maven-plugin to the build process
- Fix a method signature change in HttpProxyHandler that was flagged as a possible problem.
Result:
Ensure no API/ABI breakage accour between releases.
Motivation:
The netty-all artifact doesn't have a Automatic-Module-Name defined in the manifest like the rest of the projects do, resulting in requires netty.all.
Modification:
Add Automatic-Module-Name
Result:
Correctly work as java9 module.
Motivation:
Use actual links to new locations of Protobuf repo and documentation to
avoid problems when redirect will not work.
Modification:
Links in comments and all/pom.xml
Result:
Correct links to Protobuf resources
Motivation:
c93e58c453 changed to use _ for the tcnative lib name but missed to also adjust the filtering.
Modifications:
Fix filtering to look for _
Result:
Not include native tcnative lib as expected.
Motivation:
We need to exclude the netty-tcnative classes from the all jar when building it as otherwise there may be classloader issues.
Modifications:
Add io/netty/internal/tcnative to the exclude list.
Result:
Fixes [#6791]
Motivation:
As we now include native code for multiple platforms we need to generate an uber all jar before release it from the staging repository. For this the uber-staging profile can be used. To create a snapshot uber jar the uber-snapshot profile can be used.
Modifications:
- Add uber-staging and uber-snapshot profile
- Correct comment in pom.xml file to show usage.
Result:
Easier to create snapshot and release uber jars.
Motivation:
To ensure the release plugin works correctly we need to ensure all modules are included during build.
Modification:
- Include all modules
- Skip compilation and tests for native code when not supported but still include the module and build the jar
Result:
Build and release works again
Motivation:
We currently don't have a native transport which supports kqueue https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2. This can be useful for BSD systems such as MacOS to take advantage of native features, and provide feature parity with the Linux native transport.
Modifications:
- Make a new transport-native-unix-common module with all the java classes and JNI code for generic unix items. This module will build a static library for each unix platform, and included in the dynamic libraries used for JNI (e.g. transport-native-epoll, and eventually kqueue).
- Make a new transport-native-unix-common-tests module where the tests for the transport-native-unix-common module will live. This is so each unix platform can inherit from these test and ensure they pass.
- Add a new transport-native-kqueue module which uses JNI to directly interact with kqueue
Result:
JNI support for kqueue.
Fixes https://github.com/netty/netty/issues/2448
Fixes https://github.com/netty/netty/issues/4231
Motivation:
codec-redis and codec-xml are release modules and should be included in netty-all.
Modifications:
Add codec-redis and codec-xml modules to netty-all pom.
Result:
codec-redis and codec-xml can be used with the netty-all artifact.
Motivation:
Java9 will be released soon so we should ensure we can compile netty with Java9 and run all our tests. This will help to make sure Netty will be usable with Java9.
Modification:
- Add some workarounds to be able to compile with Java9, note that the full profile is not supported with Java9 atm.
- Remove some usage of internal APIs to be able to compile on java9
- Not support Alpn / Npn and so not run the tests when using Java9 for now. We will do a follow up PR to add support.
Result:
Its possible to build netty and run its testsuite with Java9.
