Go to file
Trustin Lee 568295d6c0 Simplify native library resolution using os-maven-plugin
Motivation:

So far, we used a very simple platform string such as linux64 and
linux32.  However, this is far from perfection because it does not
include anything about the CPU architecture.

Also, the current build tries to put multiple versions of .so files into
a single JAR.  This doesn't work very well when we have to ship for many
different platforms.  Think about shipping .so/.dynlib files for both
Linux and Mac OS X.

Modification:

- Use os-maven-plugin as an extension to determine the current OS and
  CPU architecture reliable at build time
- Use Maven classifier instead of trying to put all shared libraries
  into a single JAR
- NativeLibraryLoader does not guess the OS and bit mode anymore and it
  always looks for the same location regardless of platform, because the
  Maven classifier does the job instead.

Result:

Better scalable native library deployment and retrieval
2014-05-02 04:22:11 +09:00
all [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
buffer [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
codec [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
codec-http [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
codec-socks [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
common Simplify native library resolution using os-maven-plugin 2014-05-02 04:22:11 +09:00
example [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
handler [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
license [#1259] Add optimized queue for SCMP pattern and use it in NIO and native transport 2014-02-27 11:44:06 +01:00
microbench [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
tarball [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
testsuite [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
transport [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
transport-native-epoll Simplify native library resolution using os-maven-plugin 2014-05-02 04:22:11 +09:00
transport-rxtx [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
transport-sctp [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
transport-udt [maven-release-plugin] prepare for next development iteration 2014-04-30 15:40:54 +02:00
.fbfilter.xml Update license headers 2012-06-04 13:31:44 -07:00
.fbprefs Updated Find Bugs configuration 2009-03-04 10:33:09 +00:00
.gitignore Format and partially describe Gitignore 2013-12-10 07:04:38 +01: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 [#1259] Add optimized queue for SCMP pattern and use it in NIO and native transport 2014-02-27 11:44:06 +01:00
pom.xml Simplify native library resolution using os-maven-plugin 2014-05-02 04:22:11 +09:00
README.md Update README.md 2014-01-16 14:38:36 +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.