netty5/pom.xml

1609 lines
60 KiB
XML
Raw Normal View History

2009-01-12 12:45:50 +01:00
<?xml version="1.0" encoding="UTF-8"?>
<!--
2012-06-04 22:31:44 +02:00
~ Copyright 2012 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:
~
~ https://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 https://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.sonatype.oss</groupId>
<artifactId>oss-parent</artifactId>
<version>9</version>
</parent>
<groupId>io.netty</groupId>
<artifactId>netty-parent</artifactId>
<packaging>pom</packaging>
<version>4.1.60.Final-SNAPSHOT</version>
<name>Netty</name>
<url>https://netty.io/</url>
<description>
Netty is an asynchronous event-driven network application framework for
rapid development of maintainable high performance protocol servers and
clients.
</description>
2011-12-09 06:49:10 +01:00
<organization>
<name>The Netty Project</name>
<url>https://netty.io/</url>
2011-12-09 06:49:10 +01:00
</organization>
<licenses>
<license>
<name>Apache License, Version 2.0</name>
<url>https://www.apache.org/licenses/LICENSE-2.0</url>
</license>
</licenses>
<inceptionYear>2008</inceptionYear>
<scm>
2011-01-11 10:41:14 +01:00
<url>https://github.com/netty/netty</url>
<connection>scm:git:git://github.com/netty/netty.git</connection>
2011-02-07 13:31:08 +01:00
<developerConnection>scm:git:ssh://git@github.com/netty/netty.git</developerConnection>
<tag>HEAD</tag>
</scm>
2011-12-09 07:22:00 +01:00
<developers>
<developer>
<id>netty.io</id>
<name>The Netty Project Contributors</name>
<email>netty@googlegroups.com</email>
<url>https://netty.io/</url>
2011-12-09 07:22:00 +01:00
<organization>The Netty Project</organization>
<organizationUrl>https://netty.io/</organizationUrl>
2011-12-09 07:22:00 +01:00
</developer>
</developers>
<profiles>
<profile>
<id>not_x86_64</id>
<activation>
<os>
<arch>!x86_64</arch>
</os>
</activation>
<properties>
<!-- Use no classifier as we only support x86_64 atm-->
<tcnative.classifier />
<skipShadingTestsuite>true</skipShadingTestsuite>
</properties>
</profile>
<!-- Detect if we use GraalVM and if so enable the native image testsuite -->
<profile>
<id>graal</id>
<activation>
<file>
<!-- GraalVM Component Updater should exists when using GraalVM-->
<exists>${java.home}/bin/gu</exists>
</file>
</activation>
<properties>
<skipNativeImageTestsuite>false</skipNativeImageTestsuite>
<forbiddenapis.skip>true</forbiddenapis.skip>
<testJvm />
</properties>
</profile>
<!-- JDK16 -->
<profile>
<id>java16</id>
<activation>
<jdk>16</jdk>
</activation>
<properties>
<!-- Not use alpn agent as Java11+ supports alpn out of the box -->
<argLine.alpnAgent />
<argLine.java9.extras />
<!-- Export some stuff which is used during our tests -->
<argLine.java9>--illegal-access=deny ${argLine.java9.extras}</argLine.java9>
<forbiddenapis.skip>true</forbiddenapis.skip>
<!-- Needed because of https://issues.apache.org/jira/browse/MENFORCER-275 -->
<enforcer.plugin.version>3.0.0-M3</enforcer.plugin.version>
<!-- 1.4.x does not work in Java10+ -->
<jboss.marshalling.version>2.0.5.Final</jboss.marshalling.version>
<!-- This is the minimum supported by Java12+ -->
<maven.compiler.source>1.7</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>
<!-- pax-exam does not work on latest Java12 EA 22 build -->
<skipOsgiTestsuite>true</skipOsgiTestsuite>
</properties>
</profile>
<!-- JDK15 -->
<profile>
<id>java15</id>
<activation>
<jdk>15</jdk>
</activation>
<properties>
<!-- Not use alpn agent as Java11+ supports alpn out of the box -->
<argLine.alpnAgent />
<forbiddenapis.skip>true</forbiddenapis.skip>
<!-- Needed because of https://issues.apache.org/jira/browse/MENFORCER-275 -->
<enforcer.plugin.version>3.0.0-M3</enforcer.plugin.version>
<!-- 1.4.x does not work in Java10+ -->
<jboss.marshalling.version>2.0.5.Final</jboss.marshalling.version>
<!-- This is the minimum supported by Java12+ -->
<maven.compiler.source>1.7</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>
<!-- pax-exam does not work on latest Java12 EA 22 build -->
<skipOsgiTestsuite>true</skipOsgiTestsuite>
</properties>
</profile>
<!-- JDK14 -->
<profile>
<id>java14</id>
<activation>
<jdk>14</jdk>
</activation>
<properties>
<!-- Not use alpn agent as Java11+ supports alpn out of the box -->
<argLine.alpnAgent />
<forbiddenapis.skip>true</forbiddenapis.skip>
<!-- Needed because of https://issues.apache.org/jira/browse/MENFORCER-275 -->
<enforcer.plugin.version>3.0.0-M3</enforcer.plugin.version>
<!-- 1.4.x does not work in Java10+ -->
<jboss.marshalling.version>2.0.5.Final</jboss.marshalling.version>
<!-- This is the minimum supported by Java12+ -->
<maven.compiler.source>1.7</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>
<!-- pax-exam does not work on latest Java12 EA 22 build -->
<skipOsgiTestsuite>true</skipOsgiTestsuite>
</properties>
</profile>
<!-- JDK13 -->
<profile>
<id>java13</id>
<activation>
<jdk>13</jdk>
</activation>
<properties>
<!-- Not use alpn agent as Java11+ supports alpn out of the box -->
<argLine.alpnAgent />
<forbiddenapis.skip>true</forbiddenapis.skip>
<!-- Needed because of https://issues.apache.org/jira/browse/MENFORCER-275 -->
<enforcer.plugin.version>3.0.0-M3</enforcer.plugin.version>
<!-- 1.4.x does not work in Java10+ -->
<jboss.marshalling.version>2.0.5.Final</jboss.marshalling.version>
<!-- This is the minimum supported by Java12+ -->
<maven.compiler.source>1.7</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>
<!-- pax-exam does not work on latest Java12 EA 22 build -->
<skipOsgiTestsuite>true</skipOsgiTestsuite>
</properties>
</profile>
<!-- JDK12 -->
<profile>
<id>java12</id>
<activation>
<jdk>12</jdk>
</activation>
<properties>
<argLine.java9.extras />
<!-- Export some stuff which is used during our tests -->
<argLine.java9>--illegal-access=deny ${argLine.java9.extras}</argLine.java9>
<!-- Not use alpn agent as Java11+ supports alpn out of the box -->
<argLine.alpnAgent />
<forbiddenapis.skip>true</forbiddenapis.skip>
<!-- Needed because of https://issues.apache.org/jira/browse/MENFORCER-275 -->
<enforcer.plugin.version>3.0.0-M3</enforcer.plugin.version>
<!-- 1.4.x does not work in Java10+ -->
<jboss.marshalling.version>2.0.5.Final</jboss.marshalling.version>
<!-- This is the minimum supported by Java12+ -->
<maven.compiler.source>1.7</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>
<!-- pax-exam does not work on latest Java12 EA 22 build -->
<skipOsgiTestsuite>true</skipOsgiTestsuite>
</properties>
</profile>
<!-- JDK11 -->
<profile>
<id>java11</id>
<activation>
<jdk>11</jdk>
</activation>
<properties>
<argLine.java9.extras />
<!-- Export some stuff which is used during our tests -->
<argLine.java9>--illegal-access=deny ${argLine.java9.extras}</argLine.java9>
<!-- Not use alpn agent as Java11+ supports alpn out of the box -->
<argLine.alpnAgent />
<forbiddenapis.skip>true</forbiddenapis.skip>
<!-- Needed because of https://issues.apache.org/jira/browse/MENFORCER-275 -->
<enforcer.plugin.version>3.0.0-M3</enforcer.plugin.version>
<!-- 1.4.x does not work in Java10+ -->
<jboss.marshalling.version>2.0.5.Final</jboss.marshalling.version>
<!-- pax-exam does not work on latest Java11 build -->
<skipOsgiTestsuite>true</skipOsgiTestsuite>
</properties>
</profile>
<!-- JDK10 -->
<profile>
<id>java10</id>
<activation>
<jdk>10</jdk>
</activation>
<properties>
<argLine.java9.extras />
<!-- Export some stuff which is used during our tests -->
<argLine.java9>--illegal-access=deny --add-modules java.xml.bind ${argLine.java9.extras}</argLine.java9>
<!-- Not use alpn agent as Java10 supports alpn out of the box -->
<argLine.alpnAgent />
<forbiddenapis.skip>true</forbiddenapis.skip>
<!-- Needed because of https://issues.apache.org/jira/browse/MENFORCER-275 -->
<enforcer.plugin.version>3.0.0-M3</enforcer.plugin.version>
<!-- 1.4.x does not work in Java10+ -->
<jboss.marshalling.version>2.0.5.Final</jboss.marshalling.version>
</properties>
</profile>
<!-- JDK9 -->
<profile>
<id>java9</id>
<properties>
<argLine.java9.extras />
<!-- Export some stuff which is used during our tests -->
<argLine.java9>--illegal-access=deny --add-modules java.xml.bind ${argLine.java9.extras}</argLine.java9>
<!-- Not use alpn agent as Java9 supports alpn out of the box -->
<argLine.alpnAgent />
<!-- Skip as maven plugin not works with Java9 yet -->
<forbiddenapis.skip>true</forbiddenapis.skip>
<!-- Needed because of https://issues.apache.org/jira/browse/MENFORCER-275 -->
<enforcer.plugin.version>3.0.0-M1</enforcer.plugin.version>
</properties>
<activation>
<jdk>9</jdk>
</activation>
</profile>
<profile>
<id>boringssl</id>
<properties>
<tcnative.artifactId>netty-tcnative-boringssl-static</tcnative.artifactId>
<tcnative.classifier />
</properties>
</profile>
<profile>
<id>leak</id>
<properties>
<argLine.leak>-Dio.netty.leakDetectionLevel=paranoid -Dio.netty.leakDetection.targetRecords=32</argLine.leak>
</properties>
</profile>
<profile>
<id>noPrintGC</id>
<properties>
<argLine.printGC>-D_</argLine.printGC>
</properties>
</profile>
<profile>
<id>noUnsafe</id>
<properties>
<argLine.noUnsafe>-Dio.netty.noUnsafe=true</argLine.noUnsafe>
</properties>
</profile>
<profile>
<id>coverage</id>
<properties>
<argLine.coverage>${jacoco.argLine}</argLine.coverage>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.7.7.201606060606</version>
<executions>
<execution>
<id>jacoco-prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
<configuration>
<propertyName>jacoco.argLine</propertyName>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>jdk8</id>
<activation>
<jdk>[1.8,)</jdk>
</activation>
<properties>
<!-- Our Javadoc has poor enough quality to fail the build thanks to JDK8 javadoc which got more strict. -->
<maven.javadoc.failOnError>false</maven.javadoc.failOnError>
</properties>
</profile>
<profile>
<!--
This profile exists because either ALPN or NPN can exits on the class path at once, but not both.
The JDK version is typically used to distinguish which should be used but there is some overlap
where both could be used. ALPN is the default and this profile is enabled with a -Dforcenpn=true arugument
-->
<id>forcenpn</id>
<activation>
<property>
<name>forcenpn</name>
<value>true</value>
</property>
</activation>
<properties>
<jetty.alpnAgent.option>forceNpn=true</jetty.alpnAgent.option>
</properties>
</profile>
</profiles>
2012-06-13 07:03:57 +02:00
<properties>
Enable configuring available processors Motivation: In cases when an application is running in a container or is otherwise constrained to the number of processors that it is using, the JVM invocation Runtime#availableProcessors will not return the constrained value but rather the number of processors available to the virtual machine. Netty uses this number in sizing various resources. Additionally, some applications will constrain the number of threads that they are using independenly of the number of processors available on the system. Thus, applications should have a way to globally configure the number of processors. Modifications: Rather than invoking Runtime#availableProcessors, Netty should rely on a method that enables configuration when the JVM is started or by the application. This commit exposes a new class NettyRuntime for enabling such configuraiton. This value can only be set once. Its default value is Runtime#availableProcessors so that there is no visible change to existing applications, but enables configuring either a system property or configuring during application startup (e.g., based on settings used to configure the application). Additionally, we introduce the usage of forbidden-apis to prevent future uses of Runtime#availableProcessors from creeping. Future work should enable the bundled signatures and clean up uses of deprecated and other forbidden methods. Result: Netty can be configured to not use the underlying number of processors, but rather the constrained number of processors.
2017-01-16 18:36:32 +01:00
<maven.compiler.source>1.6</maven.compiler.source>
<maven.compiler.target>1.6</maven.compiler.target>
<netty.dev.tools.directory>${project.build.directory}/dev-tools</netty.dev.tools.directory>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<netty.build.version>28</netty.build.version>
<jboss.marshalling.version>1.4.11.Final</jboss.marshalling.version>
<jetty.alpnAgent.version>2.0.10</jetty.alpnAgent.version>
<jetty.alpnAgent.path>"${settings.localRepository}"/org/mortbay/jetty/alpn/jetty-alpn-agent/${jetty.alpnAgent.version}/jetty-alpn-agent-${jetty.alpnAgent.version}.jar</jetty.alpnAgent.path>
<argLine.common>
-server
2013-03-16 02:15:42 +01:00
-dsa -da -ea:io.netty...
-XX:+HeapDumpOnOutOfMemoryError
</argLine.common>
<!-- Default to ALPN. See forcenpn profile to force NPN -->
<argLine.alpnAgent>-javaagent:${jetty.alpnAgent.path}=${jetty.alpnAgent.option}</argLine.alpnAgent>
<argLine.leak>-D_</argLine.leak> <!-- Overridden when 'leak' profile is active -->
<argLine.noUnsafe>-D_</argLine.noUnsafe> <!-- Overridden when 'noUnsafe' profile is active -->
<argLine.coverage>-D_</argLine.coverage> <!-- Overridden when 'coverage' profile is active -->
<argLine.printGC>-XX:+PrintGCDetails</argLine.printGC>
<argLine.java9 /> <!-- Overridden when 'java9' profile is active -->
<argLine.javaProperties>-D_</argLine.javaProperties>
<!-- Configure the os-maven-plugin extension to expand the classifier on -->
<!-- Fedora-"like" systems. This is currently only used for the netty-tcnative dependency -->
<osmaven.version>1.7.0</osmaven.version>
<!-- keep in sync with PlatformDependent#ALLOWED_LINUX_OS_CLASSIFIERS -->
<os.detection.classifierWithLikes>fedora,suse,arch</os.detection.classifierWithLikes>
<tcnative.artifactId>netty-tcnative</tcnative.artifactId>
<tcnative.version>2.0.36.Final</tcnative.version>
<tcnative.classifier>${os.detected.classifier}</tcnative.classifier>
<conscrypt.groupId>org.conscrypt</conscrypt.groupId>
<conscrypt.artifactId>conscrypt-openjdk-uber</conscrypt.artifactId>
<conscrypt.version>2.5.1</conscrypt.version>
<conscrypt.classifier />
<jni.classifier>${os.detected.name}-${os.detected.arch}</jni.classifier>
<logging.config>${project.basedir}/../common/src/test/resources/logback-test.xml</logging.config>
<logging.logLevel>debug</logging.logLevel>
<log4j2.version>2.6.2</log4j2.version>
<enforcer.plugin.version>1.4.1</enforcer.plugin.version>
<junit.version>5.7.0</junit.version>
<testJavaHome>${java.home}</testJavaHome>
<testJvm>${testJavaHome}/bin/java</testJvm>
<skipOsgiTestsuite>false</skipOsgiTestsuite>
<skipAutobahnTestsuite>false</skipAutobahnTestsuite>
<skipHttp2Testsuite>false</skipHttp2Testsuite>
<skipJapicmp>false</skipJapicmp>
<graalvm.version>19.2.1</graalvm.version>
<!-- By default skip native testsuite as it requires a custom environment with graalvm installed -->
<skipNativeImageTestsuite>true</skipNativeImageTestsuite>
<skipShadingTestsuite>false</skipShadingTestsuite>
2012-06-13 07:03:57 +02:00
</properties>
<modules>
<module>all</module>
Enable configuring available processors Motivation: In cases when an application is running in a container or is otherwise constrained to the number of processors that it is using, the JVM invocation Runtime#availableProcessors will not return the constrained value but rather the number of processors available to the virtual machine. Netty uses this number in sizing various resources. Additionally, some applications will constrain the number of threads that they are using independenly of the number of processors available on the system. Thus, applications should have a way to globally configure the number of processors. Modifications: Rather than invoking Runtime#availableProcessors, Netty should rely on a method that enables configuration when the JVM is started or by the application. This commit exposes a new class NettyRuntime for enabling such configuraiton. This value can only be set once. Its default value is Runtime#availableProcessors so that there is no visible change to existing applications, but enables configuring either a system property or configuring during application startup (e.g., based on settings used to configure the application). Additionally, we introduce the usage of forbidden-apis to prevent future uses of Runtime#availableProcessors from creeping. Future work should enable the bundled signatures and clean up uses of deprecated and other forbidden methods. Result: Netty can be configured to not use the underlying number of processors, but rather the constrained number of processors.
2017-01-16 18:36:32 +01:00
<module>dev-tools</module>
<module>common</module>
<module>buffer</module>
<module>codec</module>
<module>codec-dns</module>
<module>codec-haproxy</module>
<module>codec-http</module>
<module>codec-http2</module>
<module>codec-memcache</module>
<module>codec-mqtt</module>
<module>codec-redis</module>
<module>codec-smtp</module>
2012-11-07 19:54:00 +01:00
<module>codec-socks</module>
<module>codec-stomp</module>
<module>codec-xml</module>
<module>resolver</module>
<module>resolver-dns</module>
<module>resolver-dns-native-macos</module>
<module>tarball</module>
<module>transport</module>
<module>transport-native-unix-common-tests</module>
<module>transport-native-unix-common</module>
<module>transport-native-epoll</module>
<module>transport-native-kqueue</module>
2013-01-09 11:40:38 +01:00
<module>transport-rxtx</module>
<module>transport-sctp</module>
2013-01-07 16:44:41 +01:00
<module>transport-udt</module>
<module>handler</module>
<module>handler-proxy</module>
<module>example</module>
<module>testsuite</module>
<module>testsuite-autobahn</module>
<module>testsuite-http2</module>
<module>testsuite-osgi</module>
<module>testsuite-shading</module>
<module>testsuite-native</module>
<module>testsuite-native-image</module>
Fix native image build on modern GraalVM versions for the cases when the program uses netty-dns (#10630) Motivation: Since GraalVM version 19.3.0, instances of java.net.InetAddress (and its subclasses Inet4Address and Inet6Address) are not allowed in native image heap (that is, they cannot be stored in static fields of classes initialized at build time or be reachable through static fields of such classes). When building a native image, it makes sense to initialize at build time as many classes as possible. But some fields of some classes in Netty (for example, NetUtil.LOCALHOST4) contain InetAddress instances. If a program is using code path that makes it possible to reach such fields at build time initialization, it becomes impossible to build a native image initializing core Netty classes initialized at runtime. An example of such a program is a client that uses netty-dns. Modifications: - Add netty-testsuite-native-image-client Maven module to test that such an example program can be built after the corresponding fixes - Add native-image.properties to resolver-dns module to move initialization of some classes to runtime (some of them are parsing configuration during initialization, so it makes no sense to initialize them at build time; for others, it's needed to avoid InetAddress reachability at build time) - Add substitutions for NetUtil.LOCALHOST4, NetUtil.LOCALHOST6 and NetUtil.LOCALHOST to overcome the InetAddress-related prohibition - Extract some initialization code from NetUtil to NetUtilInitializations to allow it to be used by the substitutions Result: A client program using netty-dns with --initialize-at-build-time=io.netty builds successfully
2020-10-26 08:34:31 +01:00
<module>testsuite-native-image-client</module>
<module>testsuite-native-image-client-runtime-init</module>
<module>transport-blockhound-tests</module>
<module>microbench</module>
<module>bom</module>
</modules>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-jni-util</artifactId>
<version>0.0.2.Final</version>
<classifier>sources</classifier>
<optional>true</optional>
</dependency>
Enable configuring available processors Motivation: In cases when an application is running in a container or is otherwise constrained to the number of processors that it is using, the JVM invocation Runtime#availableProcessors will not return the constrained value but rather the number of processors available to the virtual machine. Netty uses this number in sizing various resources. Additionally, some applications will constrain the number of threads that they are using independenly of the number of processors available on the system. Thus, applications should have a way to globally configure the number of processors. Modifications: Rather than invoking Runtime#availableProcessors, Netty should rely on a method that enables configuration when the JVM is started or by the application. This commit exposes a new class NettyRuntime for enabling such configuraiton. This value can only be set once. Its default value is Runtime#availableProcessors so that there is no visible change to existing applications, but enables configuring either a system property or configuring during application startup (e.g., based on settings used to configure the application). Additionally, we introduce the usage of forbidden-apis to prevent future uses of Runtime#availableProcessors from creeping. Future work should enable the bundled signatures and clean up uses of deprecated and other forbidden methods. Result: Netty can be configured to not use the underlying number of processors, but rather the constrained number of processors.
2017-01-16 18:36:32 +01:00
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>netty-dev-tools</artifactId>
<version>${project.version}</version>
</dependency>
<!-- Needed for java11 and later as javax.activation is not part of the JDK anymore -->
<dependency>
<groupId>com.sun.activation</groupId>
<artifactId>javax.activation</artifactId>
<version>1.2.0</version>
</dependency>
<!-- JBoss Marshalling - completely optional -->
<dependency>
<groupId>org.jboss.marshalling</groupId>
<artifactId>jboss-marshalling</artifactId>
<version>${jboss.marshalling.version}</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
<!-- SPDY and HTTP/2 - completely optional -->
2014-01-15 12:29:18 +01:00
<dependency>
<groupId>org.eclipse.jetty.npn</groupId>
<artifactId>npn-api</artifactId>
<version>1.1.1.v20141010</version>
<scope>provided</scope> <!-- Provided by npn-boot -->
</dependency>
<dependency>
<groupId>org.eclipse.jetty.alpn</groupId>
<artifactId>alpn-api</artifactId>
<version>1.1.2.v20150522</version>
<scope>provided</scope> <!-- Provided by alpn-boot -->
</dependency>
<!-- Google Protocol Buffers - completely optional -->
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>2.6.1</version>
</dependency>
<dependency>
<groupId>com.google.protobuf.nano</groupId>
<artifactId>protobuf-javanano</artifactId>
<version>3.0.0-alpha-5</version>
</dependency>
2017-04-19 22:37:03 +02:00
<!-- Our own Tomcat Native fork - completely optional, used for accelerating SSL with OpenSSL. -->
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>${tcnative.artifactId}</artifactId>
<version>${tcnative.version}</version>
<classifier>${tcnative.classifier}</classifier>
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
<scope>compile</scope>
<optional>true</optional>
</dependency>
<!-- Conscrypt - needed for running tests, used for acclerating SSL with OpenSSL. -->
<dependency>
<groupId>${conscrypt.groupId}</groupId>
<artifactId>${conscrypt.artifactId}</artifactId>
<classifier>${conscrypt.classifier}</classifier>
<version>${conscrypt.version}</version>
<scope>compile</scope>
<optional>true</optional>
Add an OpenSslEngine and the universal API for enabling SSL Motivation: Some users already use an SSLEngine implementation in finagle-native. It wraps OpenSSL to get higher SSL performance. However, to take advantage of it, finagle-native must be compiled manually, and it means we cannot pull it in as a dependency and thus we cannot test our SslHandler against the OpenSSL-based SSLEngine. For an instance, we had #2216. Because the construction procedures of JDK SSLEngine and OpenSslEngine are very different from each other, we also need to provide a universal way to enable SSL in a Netty application. Modifications: - Pull netty-tcnative in as an optional dependency. http://netty.io/wiki/forked-tomcat-native.html - Backport NativeLibraryLoader from 4.0 - Move OpenSSL-based SSLEngine implementation into our code base. - Copied from finagle-native; originally written by @jpinner et al. - Overall cleanup by @trustin. - Run all SslHandler tests with both default SSLEngine and OpenSslEngine - Add a unified API for creating an SSL context - SslContext allows you to create a new SSLEngine or a new SslHandler with your PKCS#8 key and X.509 certificate chain. - Add JdkSslContext and its subclasses - Add OpenSslServerContext - Add ApplicationProtocolSelector to ensure the future support for NPN (NextProtoNego) and ALPN (Application Layer Protocol Negotiation) on the client-side. - Add SimpleTrustManagerFactory to help a user write a TrustManagerFactory easily, which should be useful for those who need to write an alternative verification mechanism. For example, we can use it to implement an unsafe TrustManagerFactory that accepts self-signed certificates for testing purposes. - Add InsecureTrustManagerFactory and FingerprintTrustManager for quick and dirty testing - Add SelfSignedCertificate class which generates a self-signed X.509 certificate very easily. - Update all our examples to use SslContext.newClient/ServerContext() - SslHandler now logs the chosen cipher suite when handshake is finished. Result: - Cleaner unified API for configuring an SSL client and an SSL server regardless of its internal implementation. - When native libraries are available, OpenSSL-based SSLEngine implementation is selected automatically to take advantage of its performance benefit. - Examples take advantage of this modification and thus are cleaner.
2014-05-17 19:26:01 +02:00
</dependency>
<!--
Bouncy Castle - completely optional, only needed when:
- you generate a temporary self-signed certificate using SelfSignedCertificate, and
- you don't use the JDK which doesn't provide sun.security.x509 package.
-->
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcpkix-jdk15on</artifactId>
<version>1.68</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
<!--
Completely optional and only needed for OCSP stapling to construct and
parse OCSP requests and responses.
-->
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk15on</artifactId>
<version>1.68</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
<dependency>
<groupId>com.fasterxml</groupId>
<artifactId>aalto-xml</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>com.jcraft</groupId>
<artifactId>jzlib</artifactId>
<version>1.1.3</version>
</dependency>
<dependency>
<groupId>com.ning</groupId>
<artifactId>compress-lzf</artifactId>
<version>1.0.3</version>
</dependency>
<dependency>
<groupId>net.jpountz.lz4</groupId>
<artifactId>lz4</artifactId>
<version>1.3.0</version>
</dependency>
<dependency>
<groupId>com.github.jponge</groupId>
<artifactId>lzma-java</artifactId>
<version>1.3</version>
</dependency>
<!-- Java concurrency tools for the JVM -->
<dependency>
<groupId>org.jctools</groupId>
<artifactId>jctools-core</artifactId>
<version>3.1.0</version>
</dependency>
2013-01-09 11:40:38 +01:00
<dependency>
<groupId>org.rxtx</groupId>
<artifactId>rxtx</artifactId>
<version>2.1.7</version>
</dependency>
2013-01-10 07:23:58 +01:00
<dependency>
<groupId>com.barchart.udt</groupId>
<artifactId>barchart-udt-bundle</artifactId>
<version>2.3.0</version>
2013-01-10 07:23:58 +01:00
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.30</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>${log4j2.version}</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
<exclusions>
<exclusion>
<artifactId>mail</artifactId>
<groupId>javax.mail</groupId>
</exclusion>
<exclusion>
<artifactId>jms</artifactId>
<groupId>javax.jms</groupId>
</exclusion>
<exclusion>
<artifactId>jmxtools</artifactId>
<groupId>com.sun.jdmk</groupId>
</exclusion>
<exclusion>
<artifactId>jmxri</artifactId>
<groupId>com.sun.jmx</groupId>
</exclusion>
</exclusions>
<optional>true</optional>
</dependency>
<!-- Metrics providers -->
<dependency>
<groupId>com.yammer.metrics</groupId>
<artifactId>metrics-core</artifactId>
2013-01-10 07:23:58 +01:00
<version>2.2.0</version>
</dependency>
<!-- Common test dependencies -->
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>netty-build-common</artifactId>
<version>${netty.build.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-library</artifactId>
<version>1.3</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.assertj</groupId>
<artifactId>assertj-core</artifactId>
<version>3.18.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>2.18.3</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.1.7</version>
<scope>test</scope>
</dependency>
<!-- Test dependencies for jboss marshalling encoder/decoder -->
<dependency>
<groupId>org.jboss.marshalling</groupId>
<artifactId>jboss-marshalling-serial</artifactId>
<version>${jboss.marshalling.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.marshalling</groupId>
<artifactId>jboss-marshalling-river</artifactId>
<version>${jboss.marshalling.version}</version>
<scope>test</scope>
</dependency>
<!-- Test dependencies for microbench -->
<dependency>
<groupId>com.google.caliper</groupId>
<artifactId>caliper</artifactId>
<version>0.5-rc1</version>
<scope>test</scope>
</dependency>
<!-- Test dependency for Bzip2 compression codec -->
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-compress</artifactId>
<version>1.19</version>
<scope>test</scope>
</dependency>
<!-- Test dependency used by http/2 hpack -->
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.7</version>
<scope>test</scope>
</dependency>
<!-- Test suite dependency for generating a compressed heap dump file -->
<dependency>
<groupId>org.tukaani</groupId>
<artifactId>xz</artifactId>
<version>1.5</version>
</dependency>
<!-- Test dependency for resolver-dns -->
<dependency>
<groupId>org.apache.directory.server</groupId>
<artifactId>apacheds-protocol-dns</artifactId>
<version>1.5.7</version>
<scope>test</scope>
</dependency>
<!-- Test dependency for log4j2 tests -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>${log4j2.version}</version>
<scope>test</scope>
</dependency>
<!-- BlockHound integration -->
<dependency>
<groupId>io.projectreactor.tools</groupId>
<artifactId>blockhound</artifactId>
<version>1.0.3.RELEASE</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<!-- Testing frameworks and related dependencies -->
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>netty-build-common</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-library</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.assertj</groupId>
<artifactId>assertj-core</artifactId>
<scope>test</scope>
</dependency>
<dependency>
2013-01-07 16:44:41 +01:00
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<extensions>
<extension>
<groupId>kr.motd.maven</groupId>
<artifactId>os-maven-plugin</artifactId>
<version>${osmaven.version}</version>
</extension>
</extensions>
<plugins>
<plugin>
<groupId>com.github.siom79.japicmp</groupId>
<artifactId>japicmp-maven-plugin</artifactId>
<version>0.14.3</version>
<configuration>
<parameter>
<ignoreMissingOldVersion>true</ignoreMissingOldVersion>
<breakBuildOnBinaryIncompatibleModifications>true</breakBuildOnBinaryIncompatibleModifications>
<breakBuildOnSourceIncompatibleModifications>true</breakBuildOnSourceIncompatibleModifications>
<oldVersionPattern>\d+\.\d+\.\d+\.Final</oldVersionPattern>
<ignoreMissingClassesByRegularExpressions>
<!-- ignore everything which is not part of netty itself as the plugin can not handle optional dependencies -->
<ignoreMissingClassesByRegularExpression>^(?!io\.netty\.).*</ignoreMissingClassesByRegularExpression>
<ignoreMissingClassesByRegularExpression>^io\.netty\.internal\.tcnative\..*</ignoreMissingClassesByRegularExpression>
</ignoreMissingClassesByRegularExpressions>
<excludes>
<exclude>@io.netty.util.internal.UnstableApi</exclude>
<exclude>io.netty.util.internal.shaded</exclude>
</excludes>
</parameter>
<skip>${skipJapicmp}</skip>
</configuration>
<executions>
<execution>
<phase>verify</phase>
<goals>
<goal>cmp</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-enforcer-plugin</artifactId>
<version>${enforcer.plugin.version}</version>
2011-12-09 04:24:14 +01:00
<executions>
<execution>
<id>enforce-tools</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireJavaVersion>
<!-- Enforce JDK 1.8+ for compilation. -->
<!-- This is needed because of java.util.zip.Deflater and NIO UDP multicast. -->
<version>[1.8.0,)</version>
2011-12-09 04:24:14 +01:00
</requireJavaVersion>
<requireMavenVersion>
<version>[3.1.1,)</version>
2011-12-09 04:24:14 +01:00
</requireMavenVersion>
<requireProperty>
<regexMessage>
x86_64/AARCH64/PPCLE64/s390x_64 JDK must be used.
</regexMessage>
<property>os.detected.arch</property>
<regex>^(x86_64|aarch_64|ppcle_64|s390_64)$</regex>
</requireProperty>
2011-12-09 04:24:14 +01:00
</rules>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<compilerVersion>1.8</compilerVersion>
<fork>true</fork>
Enable configuring available processors Motivation: In cases when an application is running in a container or is otherwise constrained to the number of processors that it is using, the JVM invocation Runtime#availableProcessors will not return the constrained value but rather the number of processors available to the virtual machine. Netty uses this number in sizing various resources. Additionally, some applications will constrain the number of threads that they are using independenly of the number of processors available on the system. Thus, applications should have a way to globally configure the number of processors. Modifications: Rather than invoking Runtime#availableProcessors, Netty should rely on a method that enables configuration when the JVM is started or by the application. This commit exposes a new class NettyRuntime for enabling such configuraiton. This value can only be set once. Its default value is Runtime#availableProcessors so that there is no visible change to existing applications, but enables configuring either a system property or configuring during application startup (e.g., based on settings used to configure the application). Additionally, we introduce the usage of forbidden-apis to prevent future uses of Runtime#availableProcessors from creeping. Future work should enable the bundled signatures and clean up uses of deprecated and other forbidden methods. Result: Netty can be configured to not use the underlying number of processors, but rather the constrained number of processors.
2017-01-16 18:36:32 +01:00
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
<debug>true</debug>
<optimize>true</optimize>
2011-12-09 04:26:45 +01:00
<showDeprecation>true</showDeprecation>
<showWarnings>true</showWarnings>
2013-03-22 03:57:15 +01:00
<compilerArgument>-Xlint:-options</compilerArgument>
<!-- XXX: maven-release-plugin complains - MRELEASE-715 -->
<!--
<compilerArguments>
<Xlint:-options />
<Xlint:unchecked />
<Xlint:deprecation />
</compilerArguments>
-->
<meminitial>256m</meminitial>
<maxmem>1024m</maxmem>
<excludes>
<exclude>**/package-info.java</exclude>
</excludes>
2009-04-03 07:47:12 +02:00
</configuration>
</plugin>
<plugin>
<!-- ensure that only methods available in java 1.6 can
be used even when compiling with java 1.7+ -->
<groupId>org.codehaus.mojo</groupId>
<artifactId>animal-sniffer-maven-plugin</artifactId>
<version>1.16</version>
<configuration>
<signature>
<groupId>org.codehaus.mojo.signature</groupId>
<artifactId>java16</artifactId>
<version>1.1</version>
</signature>
<ignores>
<ignore>java.nio.ByteBuffer</ignore>
</ignores>
<annotations>
<annotation>io.netty.util.internal.SuppressJava6Requirement</annotation>
</annotations>
</configuration>
<executions>
<execution>
<phase>process-classes</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>check-style</id>
<goals>
<goal>check</goal>
</goals>
<phase>validate</phase>
<configuration>
<consoleOutput>true</consoleOutput>
<logViolationsToConsole>true</logViolationsToConsole>
<failsOnError>true</failsOnError>
<failOnViolation>true</failOnViolation>
<configLocation>io/netty/checkstyle.xml</configLocation>
<sourceDirectories>
<sourceDirectory>${project.build.sourceDirectory}</sourceDirectory>
<sourceDirectory>${project.build.testSourceDirectory}</sourceDirectory>
</sourceDirectories>
</configuration>
</execution>
<execution>
<id>nohttp-checkstyle-validation</id>
<phase>validate</phase>
<configuration>
<!-- skip>false</skip -->
<configLocation>nohttp-checkstyle.xml</configLocation>
<suppressionsLocation>nohttp-checkstyle-suppressions.xml</suppressionsLocation>
<!-- propertyExpansion>main.basedir=${main.basedir}</propertyExpansion -->
<encoding>UTF-8</encoding>
<sourceDirectories>${basedir}</sourceDirectories>
<includes>**/*</includes>
<excludes>nohttp-checkstyle-suppressions.xml,**/.git/**/*,**/.idea/**/*,**/target/**/,**/.flattened-pom.xml,**/*.class</excludes>
</configuration>
<goals>
<goal>check</goal>
</goals>
<inherited>false</inherited>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.puppycrawl.tools</groupId>
<artifactId>checkstyle</artifactId>
<version>8.29</version>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>netty-build-common</artifactId>
<version>${netty.build.version}</version>
</dependency>
<dependency>
<groupId>io.spring.nohttp</groupId>
<artifactId>nohttp-checkstyle</artifactId>
<version>0.0.5.RELEASE</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>xml-maven-plugin</artifactId>
<version>1.0.1</version>
<executions>
<execution>
<id>check-style</id>
<goals>
<goal>check-format</goal>
</goals>
<phase>validate</phase>
</execution>
</executions>
<configuration>
<formatFileSets>
<formatFileSet>
<directory>${project.basedir}</directory>
<includes>
<include>**/pom.xml</include>
</includes>
</formatFileSet>
</formatFileSets>
<useDefaultFormatFileSet>false</useDefaultFormatFileSet>
</configuration>
</plugin>
<!-- Download the npn-boot.jar in advance to add it to the boot classpath. -->
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>get-jetty-alpn-agent</id>
<phase>validate</phase>
<goals>
<goal>get</goal>
</goals>
<configuration>
<groupId>org.mortbay.jetty.alpn</groupId>
<artifactId>jetty-alpn-agent</artifactId>
<version>${jetty.alpnAgent.version}</version>
</configuration>
</execution>
</executions>
</plugin>
2012-02-28 19:38:45 +01:00
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<includes>
<include>**/*Test*.java</include>
<include>**/*Benchmark*.java</include>
</includes>
2012-02-28 19:38:45 +01:00
<excludes>
<exclude>**/Abstract*</exclude>
<exclude>**/*TestUtil*</exclude>
2012-02-28 19:38:45 +01:00
</excludes>
<runOrder>random</runOrder>
<systemPropertyVariables>
<logback.configurationFile>${logging.config}</logback.configurationFile>
<logLevel>${logging.logLevel}</logLevel>
</systemPropertyVariables>
<argLine>${argLine.common} ${argLine.printGC} ${argLine.alpnAgent} ${argLine.leak} ${argLine.coverage} ${argLine.noUnsafe} ${argLine.java9} ${argLine.javaProperties}</argLine>
<properties>
<property>
<name>listener</name>
<value>io.netty.build.junit.TimedOutTestsListener</value>
</property>
</properties>
<jvm>${testJvm}</jvm>
<!-- Ensure the whole stacktrace is preserved when an exception is thrown. See https://issues.apache.org/jira/browse/SUREFIRE-1457 -->
<trimStackTrace>false</trimStackTrace>
2012-02-28 19:38:45 +01:00
</configuration>
</plugin>
2013-02-14 21:21:30 +01:00
<!-- always produce osgi bundles -->
2012-06-13 03:43:16 +02:00
<plugin>
2013-02-14 21:21:30 +01:00
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.5.4</version>
<executions>
<execution>
<id>generate-manifest</id>
<phase>process-classes</phase>
<goals>
<goal>manifest</goal>
</goals>
<configuration>
<supportedProjectTypes>
<supportedProjectType>jar</supportedProjectType>
<supportedProjectType>bundle</supportedProjectType>
</supportedProjectTypes>
<instructions>
<Export-Package>${project.groupId}.*</Export-Package>
<!-- enforce JVM vendor package as optional -->
<Import-Package>sun.misc.*;resolution:=optional,sun.nio.ch;resolution:=optional,sun.security.*;resolution:=optional,org.eclipse.jetty.npn;version="[1,2)";resolution:=optional,org.eclipse.jetty.alpn;version="[1,2)";resolution:=optional,*</Import-Package>
<!-- override "internal" private package convention -->
<Private-Package>!*</Private-Package>
</instructions>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.10</version>
<executions>
<execution>
<id>parse-version</id>
<goals>
<goal>parse-version</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
2012-06-13 03:43:16 +02:00
<artifactId>maven-source-plugin</artifactId>
<version>3.2.0</version>
<!-- Eclipse-related OSGi manifests
See https://github.com/netty/netty/issues/3886
More information: https://rajakannappan.blogspot.ie/2010/03/automating-eclipse-source-bundle.html -->
<configuration>
<archive>
<manifestEntries>
<Bundle-ManifestVersion>2</Bundle-ManifestVersion>
<Bundle-Name>${project.name}</Bundle-Name>
<Bundle-SymbolicName>${project.groupId}.${project.artifactId}.source</Bundle-SymbolicName>
<Bundle-Vendor>${project.organization.name}</Bundle-Vendor>
<Bundle-Version>${parsedVersion.osgiVersion}</Bundle-Version>
<Eclipse-SourceBundle>${project.groupId}.${project.artifactId};version="${parsedVersion.osgiVersion}";roots:="."</Eclipse-SourceBundle>
</manifestEntries>
</archive>
</configuration>
2012-06-13 03:43:16 +02:00
<executions>
<execution>
<id>attach-sources</id>
<phase>prepare-package</phase>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
<execution>
<id>attach-test-sources</id>
<phase>prepare-package</phase>
<goals>
<goal>test-jar-no-fork</goal>
</goals>
</execution>
2012-06-13 03:43:16 +02:00
</executions>
</plugin>
2012-07-10 17:23:17 +02:00
<plugin>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.4</version>
2012-07-10 17:33:53 +02:00
<configuration>
<detectOfflineLinks>false</detectOfflineLinks>
<breakiterator>true</breakiterator>
<version>false</version>
<author>false</author>
<keywords>true</keywords>
2012-07-10 17:33:53 +02:00
</configuration>
2012-07-10 17:23:17 +02:00
</plugin>
2012-08-21 07:35:48 +02:00
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.2</version>
2012-08-21 07:35:48 +02:00
<configuration>
<retryFailedDeploymentCount>10</retryFailedDeploymentCount>
</configuration>
</plugin>
<!-- After artifacts were deployed from linux and macos we need to execute the following on macOS (in the root of the project).
mvn -Psonatype-oss-release,full,uber-staging -pl transport-native-kqueue,transport-native-unix-common,all,tarball clean package gpg:sign org.sonatype.plugins:nexus-staging-maven-plugin:deploy -DstagingRepositoryId=${netty-id} -DnexusUrl=https://oss.sonatype.org -DserverId=sonatype-nexus-staging
-->
<plugin>
<artifactId>maven-release-plugin</artifactId>
<!-- Downgrade to 2.4.1 if release fails -->
<version>2.5.3</version>
<configuration>
2012-07-10 17:00:36 +02:00
<useReleaseProfile>false</useReleaseProfile>
<arguments>-P restricted-release,sonatype-oss-release,full</arguments>
2012-07-10 16:02:44 +02:00
<autoVersionSubmodules>true</autoVersionSubmodules>
2013-03-19 07:56:20 +01:00
<allowTimestampedSnapshots>false</allowTimestampedSnapshots>
<tagNameFormat>netty-@{project.version}</tagNameFormat>
</configuration>
2013-12-22 13:48:50 +01:00
<dependencies>
<dependency>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-api</artifactId>
<version>1.9.4</version>
2013-12-22 13:48:50 +01:00
</dependency>
<dependency>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-provider-gitexe</artifactId>
<version>1.9.4</version>
2013-12-22 13:48:50 +01:00
</dependency>
</dependencies>
</plugin>
<!-- Ensure to put maven-antrun-plugin at the end of the plugin list
so that they are run lastly in the same phase. -->
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<!-- Generate the version properties for all artifacts. -->
<execution>
<id>write-version-properties</id>
<phase>initialize</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<taskdef resource="net/sf/antcontrib/antlib.xml" />
<!-- Get the information about the latest commit -->
<exec executable="git" outputproperty="gitOutput.lastCommit" resultproperty="gitExitCode.lastCommit" failonerror="false" failifexecutionfails="false">
<arg value="log" />
<arg value="-1" />
<arg value="--format=format:%h %H %cd" />
<arg value="--date=iso" />
</exec>
<propertyregex property="shortCommitHash" input="${gitOutput.lastCommit}" regexp="^([0-9a-f]+) .*$" select="\1" casesensitive="true" defaultValue="0" />
<propertyregex property="longCommitHash" input="${gitOutput.lastCommit}" regexp="^[0-9a-f]+ ([0-9a-f]{40}) .*$" select="\1" casesensitive="true" defaultValue="0000000000000000000000000000000000000000" />
<propertyregex property="commitDate" input="${gitOutput.lastCommit}" regexp="^[0-9a-f]+ [0-9a-f]{40} (.*)$" select="\1" casesensitive="true" defaultValue="1970-01-01 00:00:00 +0000" />
<!-- Get the information abount whether the repository is clean or dirty -->
<exec executable="git" outputproperty="gitOutput.repoStatus" resultproperty="gitExitCode.repoStatus" failonerror="false" failifexecutionfails="false">
<arg value="status" />
<arg value="--porcelain" />
</exec>
<if>
<equals arg2="0" arg1="${gitExitCode.repoStatus}" />
<then>
<if>
<equals arg2="" arg1="${gitOutput.repoStatus}" />
<then>
<property name="repoStatus" value="clean" />
</then>
<else>
<property name="repoStatus" value="dirty" />
</else>
</if>
</then>
<else>
<property name="repoStatus" value="unknown" />
</else>
</if>
<!-- Print the obtained commit information. -->
<echo>Current commit: ${shortCommitHash} on ${commitDate}</echo>
<!-- Generate the .properties file. -->
<!--
<property name="metaInfDir" value="${project.basedir}/src/main/resources/META-INF" />
-->
<property name="metaInfDir" value="${project.build.outputDirectory}/META-INF" />
<property name="versionPropFile" value="${metaInfDir}/${project.groupId}.versions.properties" />
<mkdir dir="${metaInfDir}" />
<delete file="${versionPropFile}" quiet="true" />
<propertyfile file="${versionPropFile}" comment="Generated by netty-parent/pom.xml">
<entry key="${project.artifactId}.version" value="${project.version}" />
<entry key="${project.artifactId}.buildDate" type="date" value="now" pattern="yyyy-MM-dd HH:mm:ss Z" />
<entry key="${project.artifactId}.commitDate" value="${commitDate}" />
<entry key="${project.artifactId}.shortCommitHash" value="${shortCommitHash}" />
<entry key="${project.artifactId}.longCommitHash" value="${longCommitHash}" />
<entry key="${project.artifactId}.repoStatus" value="${repoStatus}" />
</propertyfile>
</target>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant</artifactId>
<version>1.10.9</version>
</dependency>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant-launcher</artifactId>
<version>1.9.7</version>
</dependency>
<dependency>
<groupId>ant-contrib</groupId>
<artifactId>ant-contrib</artifactId>
<version>1.0b3</version>
<exclusions>
<exclusion>
<groupId>ant</groupId>
<artifactId>ant</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</plugin>
Enable configuring available processors Motivation: In cases when an application is running in a container or is otherwise constrained to the number of processors that it is using, the JVM invocation Runtime#availableProcessors will not return the constrained value but rather the number of processors available to the virtual machine. Netty uses this number in sizing various resources. Additionally, some applications will constrain the number of threads that they are using independenly of the number of processors available on the system. Thus, applications should have a way to globally configure the number of processors. Modifications: Rather than invoking Runtime#availableProcessors, Netty should rely on a method that enables configuration when the JVM is started or by the application. This commit exposes a new class NettyRuntime for enabling such configuraiton. This value can only be set once. Its default value is Runtime#availableProcessors so that there is no visible change to existing applications, but enables configuring either a system property or configuring during application startup (e.g., based on settings used to configure the application). Additionally, we introduce the usage of forbidden-apis to prevent future uses of Runtime#availableProcessors from creeping. Future work should enable the bundled signatures and clean up uses of deprecated and other forbidden methods. Result: Netty can be configured to not use the underlying number of processors, but rather the constrained number of processors.
2017-01-16 18:36:32 +01:00
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-remote-resources-plugin</artifactId>
<version>1.5</version>
</plugin>
<plugin>
<groupId>de.thetaphi</groupId>
<artifactId>forbiddenapis</artifactId>
<version>2.2</version>
</plugin>
</plugins>
2012-02-07 07:30:41 +01:00
<pluginManagement>
<plugins>
<!-- keep surefire and failsafe in sync -->
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
</plugin>
<!-- keep surefire and failsafe in sync -->
<plugin>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.22.2</version>
</plugin>
2012-09-28 10:45:40 +02:00
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>3.0.0</version>
2012-09-28 10:45:40 +02:00
</plugin>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.0.1</version>
2012-09-28 10:45:40 +02:00
</plugin>
<plugin>
<groupId>org.ops4j.pax.exam</groupId>
<artifactId>maven-paxexam-plugin</artifactId>
<version>1.2.4</version>
</plugin>
2012-09-28 10:45:40 +02:00
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<executions>
<execution>
<id>default-jar</id>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
</manifest>
<manifestEntries>
<Automatic-Module-Name>${javaModuleName}</Automatic-Module-Name>
</manifestEntries>
<index>true</index>
<manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</execution>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
2012-09-28 10:45:40 +02:00
</plugin>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
2012-09-28 10:45:40 +02:00
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.6</version>
2012-09-28 10:45:40 +02:00
</plugin>
<plugin>
2013-06-13 09:56:50 +02:00
<!-- Do NOT upgrade -->
2012-09-28 10:45:40 +02:00
<artifactId>maven-jxr-plugin</artifactId>
<version>2.2</version>
</plugin>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<dependencies>
<dependency>
<groupId>ant-contrib</groupId>
<artifactId>ant-contrib</artifactId>
<version>1.0b3</version>
<exclusions>
<exclusion>
<groupId>ant</groupId>
<artifactId>ant</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
2012-09-28 10:45:40 +02:00
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.10</version>
</plugin>
<plugin>
<groupId>org.fusesource.hawtjni</groupId>
<artifactId>maven-hawtjni-plugin</artifactId>
<version>1.14</version>
</plugin>
<plugin>
<groupId>kr.motd.maven</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.0.0.Final</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.1</version>
</plugin>
2012-09-28 10:45:40 +02:00
<!-- Workaround for the 'M2E plugin execution not covered' problem.
See: https://wiki.eclipse.org/M2E_plugin_execution_not_covered -->
2012-02-07 07:30:41 +01:00
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<versionRange>[1.7,)</versionRange>
<goals>
<goal>run</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore />
</action>
</pluginExecution>
2012-02-07 07:30:41 +01:00
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<versionRange>[1.0,)</versionRange>
<goals>
<goal>check</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore />
</action>
</pluginExecution>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<versionRange>[1.0,)</versionRange>
<goals>
<goal>enforce</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore />
2012-02-07 07:30:41 +01:00
</action>
</pluginExecution>
2012-08-08 09:30:04 +02:00
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-clean-plugin</artifactId>
<versionRange>[1.0,)</versionRange>
<goals>
<goal>clean</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore />
2012-08-08 09:30:04 +02:00
</action>
</pluginExecution>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<versionRange>[2.4,)</versionRange>
<goals>
<goal>manifest</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore />
</action>
</pluginExecution>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.fusesource.hawtjni</groupId>
<artifactId>maven-hawtjni-plugin</artifactId>
<versionRange>[1.10,)</versionRange>
<goals>
<goal>generate</goal>
<goal>build</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore />
</action>
</pluginExecution>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<versionRange>[2.8,)</versionRange>
<goals>
<goal>get</goal>
<goal>copy</goal>
<goal>properties</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore />
</action>
</pluginExecution>
2012-02-07 07:30:41 +01:00
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
Enable configuring available processors Motivation: In cases when an application is running in a container or is otherwise constrained to the number of processors that it is using, the JVM invocation Runtime#availableProcessors will not return the constrained value but rather the number of processors available to the virtual machine. Netty uses this number in sizing various resources. Additionally, some applications will constrain the number of threads that they are using independenly of the number of processors available on the system. Thus, applications should have a way to globally configure the number of processors. Modifications: Rather than invoking Runtime#availableProcessors, Netty should rely on a method that enables configuration when the JVM is started or by the application. This commit exposes a new class NettyRuntime for enabling such configuraiton. This value can only be set once. Its default value is Runtime#availableProcessors so that there is no visible change to existing applications, but enables configuring either a system property or configuring during application startup (e.g., based on settings used to configure the application). Additionally, we introduce the usage of forbidden-apis to prevent future uses of Runtime#availableProcessors from creeping. Future work should enable the bundled signatures and clean up uses of deprecated and other forbidden methods. Result: Netty can be configured to not use the underlying number of processors, but rather the constrained number of processors.
2017-01-16 18:36:32 +01:00
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-remote-resources-plugin</artifactId>
<version>1.5</version>
<configuration>
<resourceBundles>
<resourceBundle>io.netty:netty-dev-tools:${project.version}</resourceBundle>
</resourceBundles>
<outputDirectory>${netty.dev.tools.directory}</outputDirectory>
<!-- don't include netty-dev-tools in artifacts -->
<attachToMain>false</attachToMain>
<attachToTest>false</attachToTest>
</configuration>
<executions>
<execution>
<goals>
<goal>process</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>de.thetaphi</groupId>
<artifactId>forbiddenapis</artifactId>
<version>2.2</version>
<executions>
<execution>
<id>check-forbidden-apis</id>
<configuration>
<targetVersion>${maven.compiler.target}</targetVersion>
<!-- allow undocumented classes like sun.misc.Unsafe: -->
<internalRuntimeForbidden>false</internalRuntimeForbidden>
<!-- if the used Java version is too new, don't fail, just do nothing: -->
<failOnUnsupportedJava>false</failOnUnsupportedJava>
<bundledSignatures>
<!-- This will automatically choose the right signatures based on 'targetVersion': -->
<!-- enabling these should be done in the future -->
<!-- bundledSignature>jdk-unsafe</bundledSignature -->
<!-- bundledSignature>jdk-deprecated</bundledSignature -->
<!-- bundledSignature>jdk-system-out</bundledSignature -->
</bundledSignatures>
<signaturesFiles>
<signaturesFile>${netty.dev.tools.directory}/forbidden/signatures.txt</signaturesFile>
</signaturesFiles>
<suppressAnnotations><annotation>**.SuppressForbidden</annotation></suppressAnnotations>
</configuration>
<phase>compile</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
<execution>
<id>check-forbidden-test-apis</id>
<configuration>
<targetVersion>${maven.compiler.target}</targetVersion>
<!-- allow undocumented classes like sun.misc.Unsafe: -->
<internalRuntimeForbidden>true</internalRuntimeForbidden>
<!-- if the used Java version is too new, don't fail, just do nothing: -->
<failOnUnsupportedJava>false</failOnUnsupportedJava>
<bundledSignatures>
<!-- This will automatically choose the right signatures based on 'targetVersion': -->
<!-- enabling these should be done in the future -->
<!-- bundledSignature>jdk-unsafe</bundledSignature -->
<!-- bundledSignature>jdk-deprecated</bundledSignature -->
</bundledSignatures>
<signaturesFiles>
<signaturesFile>${netty.dev.tools.directory}/forbidden/signatures.txt</signaturesFile>
</signaturesFiles>
<suppressAnnotations><annotation>**.SuppressForbidden</annotation></suppressAnnotations>
</configuration>
<phase>test-compile</phase>
<goals>
<goal>testCheck</goal>
</goals>
</execution>
</executions>
</plugin>
2012-02-07 07:30:41 +01:00
</plugins>
</pluginManagement>
</build>
2012-11-26 06:53:15 +01:00
</project>