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

449 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 08:31:34 -08: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:
~
Enable nohttp check during the build (#10708) Motivation: HTTP is a plaintext protocol which means that someone may be able to eavesdrop the data. To prevent this, HTTPS should be used whenever possible. However, maintaining using https:// in all URLs may be difficult. The nohttp tool can help here. The tool scans all the files in a repository and reports where http:// is used. Modifications: - Added nohttp (via checkstyle) into the build process. - Suppressed findings for the websites that don't support HTTPS or that are not reachable Result: - Prevent using HTTP in the future. - Encourage users to use HTTPS when they follow the links they found in the code.
2020-10-23 14:44:18 +02:00
~ https://www.apache.org/licenses/LICENSE-2.0
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 08:31:34 -08:00
~
~ 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.
-->
Use http in xmlns URIs to make maven release plugin happy again (#10788) Motivation: https in xmlns URIs does not work and will let the maven release plugin fail: ``` [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1.779 s [INFO] Finished at: 2020-11-10T07:45:21Z [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on project netty-parent: Execution default-cli of goal org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare failed: The namespace xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" could not be added as a namespace to "project": The namespace prefix "xsi" collides with an additional namespace declared by the element -> [Help 1] [ERROR] ``` See also https://issues.apache.org/jira/browse/HBASE-24014. Modifications: Use http for xmlns Result: Be able to use maven release plugin
2020-11-10 10:22:35 +01:00
<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 https://maven.apache.org/maven-v4_0_0.xsd">
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 08:31:34 -08:00
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>io.netty</groupId>
<artifactId>netty-parent</artifactId>
[maven-release-plugin] prepare for next development iteration
2020-12-17 06:11:39 +00:00
<version>4.1.57.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 08:31:34 -08: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 08:31:34 -08: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 08:31:34 -08: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 15:54:04 -04: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>
Fix Bundle-NativeCode in MANIFEST file (#10867) Motivation: We used , but should have used ; Modifications: Replace , by ; Result: Correct manifest
2020-12-15 18:08:14 +01: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 19:20:37 +02: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>
</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>
Fix Bundle-NativeCode in MANIFEST file (#10867) Motivation: We used , but should have used ; Modifications: Replace , by ; Result: Correct manifest
2020-12-15 18:08:14 +01: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>
</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>
Fix Bundle-NativeCode in MANIFEST file (#10867) Motivation: We used , but should have used ; Modifications: Replace , by ; Result: Correct manifest
2020-12-15 18:08:14 +01: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>
Ensure we only register native methods once (#10876) Motivation: We need to ensure we only register native methods once as otherwise we may end up in an "invalid" state. The problem here was that before it was basically the responsibility the user of transport-native-unix-common to register the methods. This is error prone as there may be multiple users of these on the classpath at the same time. Modifications: - Provide a way to init native lib without register the native methods of the provided classes. This is needed to be able to re-use functionality which is exposed to our internal native code - Use flatten plugin to correctly resolve classifier and so have the correct dependency - Call Unix.* method to ensure we register the methods correctly once - Include native lib as well in the native jars of unix-common Result: Be able to have multiple artifacts of the classpath that depends on the unix-common. Related to https://github.com/netty/netty-incubator-transport-io_uring/issues/15
2020-12-18 10:37:49 +01:00
</dependency>
</dependencies>
</profile>
<profile>
<!--
For non-classifier native builds we should depend on netty-transport-native-unix-common without the
classifier. This profile will be disabled by the other profiles when the native bits will be build.
-->
<id>non-native</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-transport-native-unix-common</artifactId>
<version>${project.version}</version>
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
</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 08:31:34 -08: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 08:31:34 -08: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 15:54:04 -04: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 08:31:34 -08: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 00:01:14 -08: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 08:31:34 -08: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>
Ensure we only register native methods once (#10876) Motivation: We need to ensure we only register native methods once as otherwise we may end up in an "invalid" state. The problem here was that before it was basically the responsibility the user of transport-native-unix-common to register the methods. This is error prone as there may be multiple users of these on the classpath at the same time. Modifications: - Provide a way to init native lib without register the native methods of the provided classes. This is needed to be able to re-use functionality which is exposed to our internal native code - Use flatten plugin to correctly resolve classifier and so have the correct dependency - Call Unix.* method to ensure we register the methods correctly once - Include native lib as well in the native jars of unix-common Result: Be able to have multiple artifacts of the classpath that depends on the unix-common. Related to https://github.com/netty/netty-incubator-transport-io_uring/issues/15
2020-12-18 10:37:49 +01:00
<!-- We need to use the flatten plugin so the classifier portion of the dependency is resolved-->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
</plugin>
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 08:31:34 -08: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