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

550 lines
23 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:
~
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 17:31:34 +01: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 17:31:34 +01:00
<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>
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 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.
Add support for mac m1 (#11666) Motivation: As more and more people switch to a mac m1 we should support it Modifications: - Add profiles for cross-compile for mac m1 - Adjust script to finish release Result: Mac m1 is supported
2021-09-08 21:45:40 +02:00
-->
<optional>true</optional>
</dependency>
</dependencies>
</profile>
<profile>
<id>mac-m1-cross-compile</id>
<properties>
<!-- use aarch_64 as this is also what os.detected.arch will use on an aarch64 system -->
<jni.classifier>${os.detected.name}-aarch_64</jni.classifier>
<jni.compiler.args.cflags>CFLAGS=-target arm64-apple-macos11 -O3 -Werror -fno-omit-frame-pointer -Wunused-variable -fvisibility=hidden -I${unix.common.include.unpacked.dir}</jni.compiler.args.cflags>
<jni.compiler.args.ldflags>LDFLAGS=-arch arm64 -Wl,-weak_library,${unix.common.lib.unpacked.dir}/lib${unix.common.lib.name}.a</jni.compiler.args.ldflags>
<skipTests>true</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>
<name>netty_transport_native_kqueue_aarch_64</name>
<nativeSourceDirectory>${nativeSourceDirectory}</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>
<configureArg>--host=aarch64-apple-darwin</configureArg>
<configureArg>--libdir=${project.build.directory}/native-build/target/lib</configureArg>
</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>
<Bundle-NativeCode>META-INF/native/libnetty_transport_native_kqueue_aarch_64.jnilib; osname=MacOSX; processor=aarch_64</Bundle-NativeCode>
<Automatic-Module-Name>${javaModuleName}</Automatic-Module-Name>
</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.
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
-->
<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>
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>
<!--
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>
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>
<!--
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
<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