Go to file
Trustin Lee f86356f083 Generate non-test JAR for netty-testsuite
Motivation:

So far, we generated and deployed test JARs to Maven repositories. The
deployed JAR had the classifier 'test-jar'.  The test JAR is consumed by
transport-native-epoll as a test dependency.

The problem is, when netty-transport-native-epoll pulls the test JAR as
a dependency, that Maven resolves its transitive dependencies at
'compile' and 'runtime' scope only, which is incorrect.

I was bitten by this problem recently while trying to add a new
dependency to netty-testsuite.  Because I added a new dependency at the
'test' scope, the new dependency was not pulled transitively by
transport-native-epoll and caused an unexpected build failure.

- d6160208c3
- bf77bb4c3a

Modifications:

- Move all classes in netty-testsuite from src/test to src/main
- Update the 'compile' scope dependencies of netty-testsuite
- Override the test directory configuration properties of the surefire
  plugin
- Do not generate the test JAR anymore
- Update the dependency of netty-transport-native-epoll

Result:

It is less error-prone to add a new dependency to netty-testsuite.
2014-12-15 09:18:20 +09:00
all [maven-release-plugin] prepare for next development iteration 2014-10-29 11:48:40 +01:00
buffer Ensure buffer is not released when call array() / memoryAddress() 2014-12-11 11:30:10 +01:00
codec Rocumented decoder pitfalls to avoid mistakes found in [#3184] 2014-12-01 20:26:09 +01:00
codec-http Fix AbstractDiskHttpData int conversion from long 2014-12-08 06:27:13 +01:00
codec-socks [maven-release-plugin] prepare for next development iteration 2014-10-29 11:48:40 +01:00
common Fixing minor typo in FastThreadLocal javadoc. 2014-12-08 14:14:45 +01:00
example Do not write LastHttpContent twice in HttpStaticFileServer example 2014-11-21 11:46:10 +09:00
handler Make sure to notify handshake success even if SSLEngine is closed 2014-12-12 11:47:52 +09:00
license Remove license of deque as we not use it anymore 2014-08-04 12:21:33 +02:00
microbench Benchmark for HttpRequestDecoder 2014-11-12 14:37:11 +01:00
tarball [maven-release-plugin] prepare for next development iteration 2014-10-29 11:48:40 +01:00
testsuite Generate non-test JAR for netty-testsuite 2014-12-15 09:18:20 +09:00
transport Fix documentation for ChannelHandlerContext#fireChannelReadComplete 2014-12-12 18:43:27 +01:00
transport-native-epoll Generate non-test JAR for netty-testsuite 2014-12-15 09:18:20 +09:00
transport-rxtx [maven-release-plugin] prepare for next development iteration 2014-10-29 11:48:40 +01:00
transport-sctp [maven-release-plugin] prepare for next development iteration 2014-10-29 11:48:40 +01:00
transport-udt Small performance improvements 2014-11-20 00:58:35 -05:00
.fbprefs Updated Find Bugs configuration 2009-03-04 10:33:09 +00:00
.gitignore Add JVM crash logs to .gitignore 2014-05-18 21:37:12 +09:00
.travis.yml Travis CI branch whitelisting 2013-03-11 09:55:43 +09:00
CONTRIBUTING.md Move the pull request guide to the developer guide 2014-03-12 13:18:14 +09:00
LICENSE.txt Relicensed to Apache License v2 2009-08-28 07:15:49 +00:00
NOTICE.txt Remove license of deque as we not use it anymore 2014-08-04 12:21:33 +02:00
pom.xml Fix build errors due to missing dependency 2014-12-14 21:30:57 +09:00
README.md Add a link to the 'native transports' page 2014-07-21 12:54:43 -07:00
run-example.sh Add logLevel property to enable different log levels for the examples. 2014-11-21 10:48:13 +09:00

Netty Project

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.

How to build

For the detailed information about building and developing Netty, please visit the developer guide. This page only gives very basic information.

You require the following to build Netty:

Note that this is build-time requirement. JDK 5 (for 3.x) or 6 (for 4.0+) is enough to run your Netty-based application.

Branches to look

The 'master' branch is where the development of the latest major version lives on. The development of all other major versions takes place in each branch whose name is identical to its major version number. For example, the development of 3.x and 4.x resides in the branch '3' and the branch '4' respectively.