netty5/pom.xml

1661 lines
62 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>5.0.0.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>aggregate</id>
<properties>
<checkstyle.skip>true</checkstyle.skip>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate</goal>
</goals>
</execution>
</executions>
<configuration>
<sourceFileExcludes>
<exclude>**/com/sun/**/*.java</exclude>
<exclude>**/example/**/*.java</exclude>
<exclude>**/testsuite/**/*.java</exclude>
<exclude>**/microbench/**/*.java</exclude>
<exclude>**/microbenchmark/**/*.java</exclude>
<exclude>**/generated/**/*.java</exclude>
<exclude>**/*Benchmark.java</exclude>
<exclude>**/*Bench.java</exclude>
<exclude>**/*Test.java</exclude>
</sourceFileExcludes>
<docfilessubdirs>true</docfilessubdirs>
<outputDirectory>${project.build.directory}/api</outputDirectory>
<overview>${project.basedir}/src/javadoc/overview.html</overview>
<doctitle>Netty API Reference (${project.version})</doctitle>
<windowtitle>Netty API Reference (${project.version})</windowtitle>
<detectJavaApiLink>false</detectJavaApiLink>
<links>
<link>https://docs.oracle.com/javase/8/docs/api/</link>
<link>https://developers.google.com/protocol-buffers/docs/reference/java/</link>
<link>https://www.slf4j.org/apidocs/</link>
</links>
<groups>
<group>
<title>Low-level data representation</title>
<packages>io.netty.buffer*</packages>
</group>
<group>
<title>Central interface for all I/O operations</title>
<packages>io.netty.channel*</packages>
</group>
<group>
<title>Client &amp; Server bootstrapping utilities</title>
<packages>io.netty.bootstrap*</packages>
</group>
<group>
<title>Reusable I/O event interceptors</title>
<packages>io.netty.handler*</packages>
</group>
<group>
<title>DNS / Host resolvers</title>
<packages>io.netty.resolver*</packages>
</group>
<group>
<title>Utils</title>
<packages>io.netty.util*</packages>
</group>
</groups>
<locale>en_US</locale>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jxr-plugin</artifactId>
<executions>
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate</goal>
</goals>
</execution>
</executions>
<configuration>
<linkJavadoc>true</linkJavadoc>
<destDir>${project.build.directory}/site/xref</destDir>
<javadocDir>${project.build.directory}/site/apidocs</javadocDir>
<docTitle>Netty Source Xref (${project.version})</docTitle>
<windowTitle>Netty Source Xref (${project.version})</windowTitle>
<excludes>
<exclude>**/com/sun/**/*.java</exclude>
<exclude>**/example/**/*.java</exclude>
<exclude>**/microbench/**/*.java</exclude>
<exclude>**/microbenchmark/**/*.java</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
</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>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
<!-- pax-exam does not work on latest Java12 EA 22 build -->
<skipOsgiTestsuite>true</skipOsgiTestsuite>
<!-- doesn't work with java16 -->
<skipJapicmp>true</skipJapicmp>
</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>11</maven.compiler.source>
<maven.compiler.target>11</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>
<!-- 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>
<!-- 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>
<!-- 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>
Introduce alternative Buffer API (#11347) Motivation: In Netty 5 we wish to have a simpler, safe, future proof, and more consistent buffer API. We developed such an API in the incubating buffer repository, and taking it through multiple rounds of review and adjustments. This PR/commit bring the results of that work into the Netty 5 branch of the main Netty repository. Modifications: * `Buffer` is an interface, and all implementations are hidden behind it. There is no longer an inheritance hierarchy of abstract classes and implementations. * Reference counting is gone. After a buffer has been allocated, calling `close` on it will deallocate it. It is then up to users and integrators to ensure that the life-times of buffers are managed correctly. This is usually not a problem as buffers tend to flow through the pipeline to be released after a terminal IO operation. * Slice and duplicate methods are replaced with `split`. By removing slices, duplicate, and reference counting, there is no longer a possibility that a buffer and/or its memory can be shared and accessible through multiple routes. This solves the problem of data being accessed from multiple places in an uncoordinated way, and the problem of buffer memory being closed while being in use by some unsuspecting piece of code. Some adjustments will have to be made to other APIs, idioms, and usages, since `split` is not always a replacement for `slice` in some use cases. * The `split` has been added which allows memory to be shared among multiple buffers, but in non-overlapping regions. When the memory regions don't overlap, it will not be possible for the different buffers to interfere with each other. An internal, and completely transparent, reference counting system ensures that the backing memory is released once the last buffer view is closed. * A Send API has been introduced that can be used to enforce (in the type system) the transfer of buffer ownership. This is not expected to be used in the pipeline flow itself, but rather for other objects that wrap buffers and wish to avoid becoming "shared views" — the absence of "shared views" of memory is important for avoiding bugs in the absence of reference counting. * A new BufferAllocator API, where the choice of implementation determines factors like on-/off-heap, pooling or not. How access to the different allocators will be exposed to integrators will be decided later. Perhaps they'll be directly accessible on the `ChannelHandlerContext`. * The `PooledBufferAllocator` has been copied and modified to match the new allocator API. This includes unifying its implementation that was previously split across on-heap and off-heap. * The `PooledBufferAllocator` implementation has also been adjusted to allocate 4 MiB chunks by default, and a few changes have been made to the implementation to make a newly created, empty allocator use significantly less heap memory. * A `Resource` interface has been added, which defines the life-cycle methods and the `send` method. The `Buffer` interface extends this. * Analogues for `ByteBufHolder` has been added in the `BufferHolder` and `BufferRef` classes. * `ByteCursor` is added as a new way to iterate the data in buffers. The byte cursor API is designed to be more JIT friendly than an iterator, or the existing `ByteProcessor` interface. * `CompositeBuffer` no longer permit the same level of access to its internal components. The composite buffer enforces its ownership of its components via the `Send` API, and the components can only be individually accessed with the `forEachReadable` and `forEachWritable` methods. This keeps the API and behavioral differences between composite and non-composite buffers to a minimum. * Two implementations of the `Buffer` interface are provided with the API: One based on `ByteBuffer`, and one based on `sun.misc.Unsafe`. The `ByteBuffer` implementation is used by default. More implementations can be loaded from the classpath via service loading. The `MemorySegment` based implementation is left behind in the incubator repository. * An extensive and highly parameterised test suite has been added, to ensure that all implementations have consistent and correct behaviour, regardless of their configuration or composition. Result: We have a new buffer API that is simpler, better tested, more consistent in behaviour, and safer by design, than the existing `ByteBuf` API. The next legs of this journey will be about integrating this new API into Netty proper, and deprecate (and eventually remove) the `ByteBuf` API. This fixes #11024, #8601, #8543, #8542, #8534, #3358, and #3306.
2021-06-28 12:06:44 +02:00
<!-- Enable Unsafe buffer implementation. -->
<profile>
<id>unsafeBuffer</id>
<properties>
<argLine.java9>-Dio.netty.tryReflectionSetAccessible=true --add-opens java.base/java.nio=ALL-UNNAMED --add-opens java.base/jdk.internal.misc=ALL-UNNAMED -Dio.netty.buffer.api.MemoryManager=Unsafe</argLine.java9>
</properties>
</profile>
<profile>
<id>boringssl</id>
<activation>
<!--
Automatically active on windows as we only release static boringssl version of
netty-tcnative for windows.
-->
<os>
<family>windows</family>
</os>
</activation>
<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>relaxjavadoc</id>
<activation>
<jdk>[11,)</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>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
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
<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>29</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>-Xlog:gc</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.40.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.2</conscrypt.version>
<conscrypt.classifier />
<bouncycastle.version>1.68</bouncycastle.version>
<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>
<graalvm.version>19.3.6</graalvm.version>
<brotli4j.version>1.4.2</brotli4j.version>
<testJavaHome>${java.home}</testJavaHome>
<testJvm>${testJavaHome}/bin/java</testJvm>
<skipOsgiTestsuite>false</skipOsgiTestsuite>
<skipAutobahnTestsuite>false</skipAutobahnTestsuite>
<skipHttp2Testsuite>false</skipHttp2Testsuite>
<skipJapicmp>true</skipJapicmp>
<!-- By default skip native testsuite as it requires a custom environment with graalvm installed -->
<skipNativeImageTestsuite>true</skipNativeImageTestsuite>
<skipShadingTestsuite>false</skipShadingTestsuite>
<skipDeploy>false</skipDeploy>
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>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>
<module>transport-sctp</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.3.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 accelerating 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.
-->
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcpkix-jdk15on</artifactId>
<version>${bouncycastle.version}</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>${bouncycastle.version}</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>
<dependency>
<groupId>com.aayushatharva.brotli4j</groupId>
<artifactId>brotli4j</artifactId>
<version>${brotli4j.version}</version>
</dependency>
<dependency>
<groupId>com.aayushatharva.brotli4j</groupId>
<artifactId>native-linux-x86_64</artifactId>
<version>${brotli4j.version}</version>
</dependency>
<dependency>
<groupId>com.aayushatharva.brotli4j</groupId>
<artifactId>native-osx-x86_64</artifactId>
<version>${brotli4j.version}</version>
</dependency>
<dependency>
<groupId>com.aayushatharva.brotli4j</groupId>
<artifactId>native-windows-x86_64</artifactId>
<version>${brotli4j.version}</version>
</dependency>
<!-- Java concurrency tools for the JVM -->
<dependency>
<groupId>org.jctools</groupId>
<artifactId>jctools-core</artifactId>
<version>3.1.0</version>
</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.jupiter</groupId>
<artifactId>junit-jupiter-params</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.2.3</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 for Brotli compression codec -->
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.8.0</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.6.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.jupiter</groupId>
<artifactId>junit-jupiter-params</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 11+ for compilation. -->
<!-- This is needed because of java.util.zip.Deflater and NIO UDP multicast. -->
<version>[11.0.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>11</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>
<release>${maven.compiler.target}</release>
<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>
<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>5.1.1</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>
<skip>${skipDeploy}</skip>
2012-08-21 07:35:48 +02:00
</configuration>
</plugin>
<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.9.15</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>
<artifactId>maven-jxr-plugin</artifactId>
<version>3.1.1</version>
2012-09-28 10:45:40 +02:00
</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>