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

430 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>
[maven-release-plugin] prepare for next development iteration
2018-09-27 21:00:45 +02:00
<version>4.1.31.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>
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
<nativeSourceDirectory>${project.basedir}/src/main/c</nativeSourceDirectory>
<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>
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
<!-- support for __attribute__((weak_import)) by the linker was added in 10.2 so ensure we
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). -->
<arg>MACOSX_DEPLOYMENT_TARGET=10.2</arg>
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>
<phase>compile</phase>
</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>
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
<nativeSourceDirectory>${project.basedir}/src/main/c</nativeSourceDirectory>
<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>
<phase>compile</phase>
</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>
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
<nativeSourceDirectory>${project.basedir}/src/main/c</nativeSourceDirectory>
<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>
<phase>compile</phase>
</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>
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
<!-- Needed by the native transport as we need the memoryAddress of the ByteBuffer -->
<argLine.java9.extras>--add-exports java.base/sun.security.x509=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED</argLine.java9.extras>
<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>
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>
<artifactId>netty-transport-native-unix-common</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-transport</artifactId>
<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>
<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