andreacavalli/netty5
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
b08bbd4c20
netty5/transport-native-kqueue/pom.xml

447 lines
18 KiB
XML
Raw Normal View History

New native transport for kqueue 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
2017-01-19 17:31:34 +01:00
<?xml version="1.0" encoding="UTF-8"?>
<!--
~ Copyright 2016 The Netty Project
~
~ The Netty Project licenses this file to you under the Apache License,
~ version 2.0 (the "License"); you may not use this file except in compliance
~ with the License. You may obtain a copy of the License at:
~
~ http://www.apache.org/licenses/LICENSE-2.0
~
~ Unless required by applicable law or agreed to in writing, software
~ distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
~ WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
~ License for the specific language governing permissions and limitations
~ under the License.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>io.netty</groupId>
<artifactId>netty-parent</artifactId>
Update version number to start working on Netty 5
2018-11-20 15:49:57 +01:00
<version>5.0.0.Final-SNAPSHOT</version>
New native transport for kqueue 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
2017-01-19 17:31:34 +01:00
</parent>
<artifactId>netty-transport-native-kqueue</artifactId>
<name>Netty/Transport/Native/KQueue</name>
<packaging>jar</packaging>
<profiles>
<profile>
Correctly include all modules during build 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
2017-05-11 15:14:31 +02:00
<id>mac</id>
New native transport for kqueue 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
2017-01-19 17:31:34 +01:00
<activation>
<os>
<family>mac</family>
</os>
</activation>
<properties>
<jni.compiler.args.ldflags>LDFLAGS=-Wl,-weak_library,${unix.common.lib.unpacked.dir}/lib${unix.common.lib.name}.a</jni.compiler.args.ldflags>
Correctly include all modules during build 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
2017-05-11 15:14:31 +02:00
<skipTests>false</skipTests>
New native transport for kqueue 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
2017-01-19 17:31:34 +01:00
</properties>
Correctly include all modules during build 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
2017-05-11 15:14:31 +02:00
<build>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<!-- unpack the unix-common static library and include files -->
<execution>
<id>unpack</id>
<phase>generate-sources</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<includeGroupIds>${project.groupId}</includeGroupIds>
<includeArtifactIds>netty-transport-native-unix-common</includeArtifactIds>
<classifier>${jni.classifier}</classifier>
<outputDirectory>${unix.common.lib.dir}</outputDirectory>
<includes>META-INF/native/**</includes>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.fusesource.hawtjni</groupId>
<artifactId>maven-hawtjni-plugin</artifactId>
<executions>
<execution>
<id>build-native-lib</id>
<configuration>
Only load native transport if running architecture match the compiled library architecture. Motivation: We should only try to load the native artifacts if the architecture we are currently running on is the same as the one the native libraries were compiled for. Modifications: Include architecture in native lib name and append the current arch when trying to load these. This will fail then if its not the same as the arch of the compiled arch. Result: Fixes [#7150].
2017-08-29 14:13:49 +02:00
<name>netty_transport_native_kqueue_${os.detected.arch}</name>
Include c source files in source jar (#9497) Motivation: We should not only include the java source files but also the c source file in our source jars. Modifications: Add files from src/main/c as well Result: Fixes https://github.com/netty/netty/issues/9494
2019-08-23 09:30:27 +02:00
<nativeSourceDirectory>${nativeSourceDirectory}</nativeSourceDirectory>
Correctly include all modules during build 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
2017-05-11 15:14:31 +02:00
<libDirectory>${project.build.outputDirectory}</libDirectory>
<!-- We use Maven's artifact classifier instead.
This hack will make the hawtjni plugin to put the native library
under 'META-INF/native' rather than 'META-INF/native/${platform}'. -->
<platform>.</platform>
<configureArgs>
<arg>${jni.compiler.args.ldflags}</arg>
<arg>${jni.compiler.args.cflags}</arg>
Use MACOSX_DEPLOYMENT_TARGET=10.6 when compile native transport on MacOS (#8379) Motivation: MACOSX_DEPLOYMENT_TARGET=10.6 needs to be used as everything before is not supported in 10.14 anymore. 10.6 was released 2009 so this should be a safe thing to do. Modifications: Use MACOSX_DEPLOYMENT_TARGET=10.6 Result: Be able to compile on MacOS 10.14
2018-10-13 04:25:56 +02:00
<!-- support for __attribute__((weak_import)) by the linker was added in 10.2 (but 10.6 is the minimum we can use on 10.14) so ensure we
transport-native-kqueue libraries should not lazy link Motivation: We rely upon the linker being non-lazy to test compatibility the native library compatibility for kqueue, but the default mode of operation is to lazy link. Modifications: - We should modify the build scripts to inform the linker that this library should not be lazy linked - Error messages changes dyld: lazy symbol binding failed: Symbol not found: _clock_gettime java.lang.UnsatisfiedLinkError: unsupported JNI version 0xFFFFFFFF required by .../libnetty-transport-native-kqueue.dylib Result: Link errors are detected upon library load time.
2017-06-27 21:54:04 +02:00
explicitly set the target platform. Otherwise we may get fatal link errors due to weakly linked
methods which are not expected to be present on MacOS (e.g. accept4). -->
Use MACOSX_DEPLOYMENT_TARGET=10.6 when compile native transport on MacOS (#8379) Motivation: MACOSX_DEPLOYMENT_TARGET=10.6 needs to be used as everything before is not supported in 10.14 anymore. 10.6 was released 2009 so this should be a safe thing to do. Modifications: Use MACOSX_DEPLOYMENT_TARGET=10.6 Result: Be able to compile on MacOS 10.14
2018-10-13 04:25:56 +02:00
<arg>MACOSX_DEPLOYMENT_TARGET=10.6</arg>
Fix native-build/target/lib wanted but build in native-build/target/lib64 (#9410) Motivation: On openSUSE (probably more), 64 bit builds use lib64, e.g. /usr/lib64, and configure picks this up and builds the native library in native-build/target/lib64 where maven is not looking. Modifications: Explicitly specify --libdir=${project.build.directory}/native-build/target/lib during configuration. Result: Maven uses the correct lib directory.
2019-08-07 09:56:28 +02:00
<configureArg>--libdir=${project.build.directory}/native-build/target/lib</configureArg>
Correctly include all modules during build 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
2017-05-11 15:14:31 +02:00
</configureArgs>
</configuration>
<goals>
<goal>generate</goal>
<goal>build</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<!-- Generate the JAR that contains the native library in it. -->
<execution>
<id>native-jar</id>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
</manifest>
<manifestEntries>
Use the correct osname in the Bundle-NativeCode declaration. Motivation: We need to ensure we use the correct osname in the Bundle-NativeCode declaration as declared in: https://www.osgi.org/developer/specifications/reference/ Modifications: Update osname to match the spec. Result: Correct Bundle-NativeCode entry in the MANIFEST
2017-09-11 20:38:52 +02:00
<Bundle-NativeCode>META-INF/native/libnetty_transport_native_kqueue_${os.detected.arch}.jnilib; osname=MacOSX, processor=${os.detected.arch}"</Bundle-NativeCode>
Added Automatic-Module-Name for native modules to support Java 9 modules Motivation: Latest netty missing predefined Automatic-Module-Name module name entry in MANIFEST.MF for native transports. Modification: Added Automatic-Module-Name entry to manifest during native transports build. Fixes [#7501]
2017-12-13 18:20:37 +01:00
<Automatic-Module-Name>${javaModuleName}</Automatic-Module-Name>
Correctly include all modules during build 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
2017-05-11 15:14:31 +02:00
</manifestEntries>
<index>true</index>
<manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
</archive>
<classifier>${jni.classifier}</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-transport-native-unix-common</artifactId>
<version>${project.version}</version>
<classifier>${jni.classifier}</classifier>
<!--
The unix-common with classifier dependency is optional because it is not a runtime dependency, but a build time
dependency to get the static library which is built directly into the shared library generated by this project.
-->
<optional>true</optional>
</dependency>
</dependencies>
</profile>
<profile>
<id>openbsd</id>
<activation>
<os>
<family>unix</family>
<name>openbsd</name>
</os>
</activation>
<properties>
<skipTests>false</skipTests>
</properties>
<build>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<!-- unpack the unix-common static library and include files -->
<execution>
<id>unpack</id>
<phase>generate-sources</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<includeGroupIds>${project.groupId}</includeGroupIds>
<includeArtifactIds>netty-transport-native-unix-common</includeArtifactIds>
<classifier>${jni.classifier}</classifier>
<outputDirectory>${unix.common.lib.dir}</outputDirectory>
<includes>META-INF/native/**</includes>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.fusesource.hawtjni</groupId>
<artifactId>maven-hawtjni-plugin</artifactId>
<executions>
<execution>
<id>build-native-lib</id>
<configuration>
Only load native transport if running architecture match the compiled library architecture. Motivation: We should only try to load the native artifacts if the architecture we are currently running on is the same as the one the native libraries were compiled for. Modifications: Include architecture in native lib name and append the current arch when trying to load these. This will fail then if its not the same as the arch of the compiled arch. Result: Fixes [#7150].
2017-08-29 14:13:49 +02:00
<name>netty_transport_native_kqueue_${os.detected.arch}</name>
Include c source files in source jar (#9497) Motivation: We should not only include the java source files but also the c source file in our source jars. Modifications: Add files from src/main/c as well Result: Fixes https://github.com/netty/netty/issues/9494
2019-08-23 09:30:27 +02:00
<nativeSourceDirectory>${nativeSourceDirectory}</nativeSourceDirectory>
Correctly include all modules during build 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
2017-05-11 15:14:31 +02:00
<libDirectory>${project.build.outputDirectory}</libDirectory>
<!-- We use Maven's artifact classifier instead.
This hack will make the hawtjni plugin to put the native library
under 'META-INF/native' rather than 'META-INF/native/${platform}'. -->
<platform>.</platform>
<forceConfigure>true</forceConfigure>
<forceAutogen>true</forceAutogen>
<configureArgs>
<arg>${jni.compiler.args.ldflags}</arg>
<arg>${jni.compiler.args.cflags}</arg>
</configureArgs>
</configuration>
<goals>
<goal>generate</goal>
<goal>build</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<!-- Generate the JAR that contains the native library in it. -->
<execution>
<id>native-jar</id>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
</manifest>
<manifestEntries>
Use the correct osname in the Bundle-NativeCode declaration. Motivation: We need to ensure we use the correct osname in the Bundle-NativeCode declaration as declared in: https://www.osgi.org/developer/specifications/reference/ Modifications: Update osname to match the spec. Result: Correct Bundle-NativeCode entry in the MANIFEST
2017-09-11 20:38:52 +02:00
<Bundle-NativeCode>META-INF/native/libnetty_transport_native_kqueue_${os.detected.arch}.jnilib; osname=OpenBSD, processor=${os.detected.arch}"</Bundle-NativeCode>
Correctly include all modules during build 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
2017-05-11 15:14:31 +02:00
</manifestEntries>
<index>true</index>
<manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
</archive>
<classifier>${jni.classifier}</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-transport-native-unix-common</artifactId>
<version>${project.version}</version>
<classifier>${jni.classifier}</classifier>
<!--
The unix-common with classifier dependency is optional because it is not a runtime dependency, but a build time
dependency to get the static library which is built directly into the shared library generated by this project.
-->
<optional>true</optional>
</dependency>
</dependencies>
</profile>
<profile>
<id>freebsd</id>
<activation>
<os>
<family>unix</family>
<name>freebsd</name>
</os>
</activation>
<properties>
<skipTests>false</skipTests>
</properties>
<build>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<!-- unpack the unix-common static library and include files -->
<execution>
<id>unpack</id>
<phase>generate-sources</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<includeGroupIds>${project.groupId}</includeGroupIds>
<includeArtifactIds>netty-transport-native-unix-common</includeArtifactIds>
<classifier>${jni.classifier}</classifier>
<outputDirectory>${unix.common.lib.dir}</outputDirectory>
<includes>META-INF/native/**</includes>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.fusesource.hawtjni</groupId>
<artifactId>maven-hawtjni-plugin</artifactId>
<executions>
<execution>
<id>build-native-lib</id>
<configuration>
Only load native transport if running architecture match the compiled library architecture. Motivation: We should only try to load the native artifacts if the architecture we are currently running on is the same as the one the native libraries were compiled for. Modifications: Include architecture in native lib name and append the current arch when trying to load these. This will fail then if its not the same as the arch of the compiled arch. Result: Fixes [#7150].
2017-08-29 14:13:49 +02:00
<name>netty_transport_native_kqueue_${os.detected.arch}</name>
Include c source files in source jar (#9497) Motivation: We should not only include the java source files but also the c source file in our source jars. Modifications: Add files from src/main/c as well Result: Fixes https://github.com/netty/netty/issues/9494
2019-08-23 09:30:27 +02:00
<nativeSourceDirectory>${nativeSourceDirectory}</nativeSourceDirectory>
Correctly include all modules during build 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
2017-05-11 15:14:31 +02:00
<libDirectory>${project.build.outputDirectory}</libDirectory>
<!-- We use Maven's artifact classifier instead.
This hack will make the hawtjni plugin to put the native library
under 'META-INF/native' rather than 'META-INF/native/${platform}'. -->
<platform>.</platform>
<forceConfigure>true</forceConfigure>
<forceAutogen>true</forceAutogen>
<configureArgs>
<arg>${jni.compiler.args.ldflags}</arg>
<arg>${jni.compiler.args.cflags}</arg>
</configureArgs>
</configuration>
<goals>
<goal>generate</goal>
<goal>build</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<!-- Generate the JAR that contains the native library in it. -->
<execution>
<id>native-jar</id>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
</manifest>
<manifestEntries>
Use the correct osname in the Bundle-NativeCode declaration. Motivation: We need to ensure we use the correct osname in the Bundle-NativeCode declaration as declared in: https://www.osgi.org/developer/specifications/reference/ Modifications: Update osname to match the spec. Result: Correct Bundle-NativeCode entry in the MANIFEST
2017-09-11 20:38:52 +02:00
<Bundle-NativeCode>META-INF/native/libnetty_transport_native_kqueue_${os.detected.arch}.jnilib; osname=FreeBSD, processor=${os.detected.arch}"</Bundle-NativeCode>
Correctly include all modules during build 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
2017-05-11 15:14:31 +02:00
</manifestEntries>
<index>true</index>
<manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
</archive>
<classifier>${jni.classifier}</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-transport-native-unix-common</artifactId>
<version>${project.version}</version>
<classifier>${jni.classifier}</classifier>
<!--
The unix-common with classifier dependency is optional because it is not a runtime dependency, but a build time
dependency to get the static library which is built directly into the shared library generated by this project.
-->
<optional>true</optional>
</dependency>
</dependencies>
New native transport for kqueue 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
2017-01-19 17:31:34 +01:00
</profile>
</profiles>
<properties>
Adding stable JDK9 module names that follow reverse-DNS style Automatic-Module-Name entry provides a stable JDK9 module name, when Netty is used in a modular JDK9 applications. More info: http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html When Netty migrates to JDK9 in the future, the entry can be replaced by actual module-info descriptor. Modification: The POM-s are configured to put the correct module names to the manifest. Result: Fixes #7218.
2017-09-23 08:52:39 +02:00
<javaModuleName>io.netty.transport.kqueue</javaModuleName>
Remove --add-opens=java.base/java.nio=ALL-UNNAMED when running tests as it is not needed anymore since a long time (#8934) Motivation: At some point we needed --add-opens=java.base/java.nio=ALL-UNNAMED to run our native tests but this is not true anymore. Modifications: Remove --add-opens=java.base/java.nio=ALL-UNNAMED when running native tests. Result: Remove obsolate jvm arg.
2019-03-13 08:25:10 +01:00
<!-- Needed as we use SelfSignedCertificate in our tests -->
<argLine.java9.extras>--add-exports java.base/sun.security.x509=ALL-UNNAMED</argLine.java9.extras>
New native transport for kqueue 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
2017-01-19 17:31:34 +01:00
<unix.common.lib.name>netty-unix-common</unix.common.lib.name>
<unix.common.lib.dir>${project.build.directory}/unix-common-lib</unix.common.lib.dir>
<unix.common.lib.unpacked.dir>${unix.common.lib.dir}/META-INF/native/lib</unix.common.lib.unpacked.dir>
<unix.common.include.unpacked.dir>${unix.common.lib.dir}/META-INF/native/include</unix.common.include.unpacked.dir>
Ensure multiple shaded version of the same netty artifact can be loaded as long as the shaded prefix is different (#8207) Motivation: We should support to load multiple shaded versions of the same netty artifact as netty is often used in multiple dependencies. This is related to https://github.com/netty/netty/issues/7272. Modifications: - Use -fvisibility=hidden when compiling and use JNIEXPORT for things we really want to have exported - Ensure fields are declared as static so these are not exported - Adjust testsuite-shading to use install_name_tool on MacOS to change the id of the lib. Otherwise the wrong may be used. Result: Be able to use multiple shaded versions of the same netty artifact.
2018-08-21 07:53:45 +02:00
<jni.compiler.args.cflags>CFLAGS=-O3 -Werror -fno-omit-frame-pointer -Wunused-variable -fvisibility=hidden -I${unix.common.include.unpacked.dir}</jni.compiler.args.cflags>
transport-native-kqueue libraries should not lazy link Motivation: We rely upon the linker being non-lazy to test compatibility the native library compatibility for kqueue, but the default mode of operation is to lazy link. Modifications: - We should modify the build scripts to inform the linker that this library should not be lazy linked - Error messages changes dyld: lazy symbol binding failed: Symbol not found: _clock_gettime java.lang.UnsatisfiedLinkError: unsupported JNI version 0xFFFFFFFF required by .../libnetty-transport-native-kqueue.dylib Result: Link errors are detected upon library load time.
2017-06-27 21:54:04 +02:00
<jni.compiler.args.ldflags>LDFLAGS=-z now -L${unix.common.lib.unpacked.dir} -Wl,--whole-archive -l${unix.common.lib.name} -Wl,--no-whole-archive</jni.compiler.args.ldflags>
Include c source files in source jar (#9497) Motivation: We should not only include the java source files but also the c source file in our source jars. Modifications: Add files from src/main/c as well Result: Fixes https://github.com/netty/netty/issues/9494
2019-08-23 09:30:27 +02:00
<nativeSourceDirectory>${project.basedir}/src/main/c</nativeSourceDirectory>
Correctly include all modules during build 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
2017-05-11 15:14:31 +02:00
<skipTests>true</skipTests>
New native transport for kqueue 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
2017-01-19 17:31:34 +01:00
</properties>
<dependencies>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-common</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-buffer</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>io.netty</groupId>
Correcting Maven Dependencies (#8622) Motivation: Most of the maven modules do not explicitly declare their dependencies and rely on transitivity, which is not always correct. Modifications: For all maven modules, add all of their dependencies to pom.xml Result: All of the (essentially non-transitive) depepdencies of the modules are explicitly declared in pom.xml
2018-12-06 09:01:14 +01:00
<artifactId>netty-transport</artifactId>
New native transport for kqueue 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
2017-01-19 17:31:34 +01:00
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>io.netty</groupId>
Correcting Maven Dependencies (#8622) Motivation: Most of the maven modules do not explicitly declare their dependencies and rely on transitivity, which is not always correct. Modifications: For all maven modules, add all of their dependencies to pom.xml Result: All of the (essentially non-transitive) depepdencies of the modules are explicitly declared in pom.xml
2018-12-06 09:01:14 +01:00
<artifactId>netty-transport-native-unix-common</artifactId>
New native transport for kqueue 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
2017-01-19 17:31:34 +01:00
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-testsuite</artifactId>
<version>${project.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-transport-native-unix-common-tests</artifactId>
<version>${project.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>${tcnative.artifactId}</artifactId>
<classifier>${tcnative.classifier}</classifier>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
Include c source files in source jar (#9497) Motivation: We should not only include the java source files but also the c source file in our source jars. Modifications: Add files from src/main/c as well Result: Fixes https://github.com/netty/netty/issues/9494
2019-08-23 09:30:27 +02:00
<!-- Also include c files in source jar -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${nativeSourceDirectory}</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
New native transport for kqueue 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
2017-01-19 17:31:34 +01:00
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<!-- Generate the fallback JAR that does not contain the native library. -->
<execution>
<id>default-jar</id>
<configuration>
<excludes>
<exclude>META-INF/native/**</exclude>
</excludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Reference in New Issue Copy Permalink