Developer guide

Looking for a user guide? Please note that this guide is not a 'user guide'. It is not intended for the 'users' who build an application using Netty but for the contributors ('dev') who want to develop Netty itself. If you are looking for the documentation for users, please visit the documentation home.

Working with the source code

Important!

Before pushing your commits or issuing a pull request, make sure:

• your work builds without any failure - run 'mvn test' from shell.
• your work does not introduce any new inspection warning - see below.

Setting up IntelliJ IDEA inspection profile

Netty project team uses IntelliJ IDEA as the primary IDE. Download, unzip, and import this inspection profile into your IntelliJ IDEA and use it as the default for Netty project. Ensure your modification does not introduce any inspection warning. If you think it's a false positive, suppress the warning by using the @SuppressWarnings annotation or noinspection line comment as guided by the IDE. For more information about using the inspector, please refer to the web help pages.

Setting up Eclipse with M2E and Java 7

Netty project can be imported into Eclipse 3.7 or later with M2E integration out of the box.

Netty project Maven pom.xml settings dictate use of Java SE 1.6, while implicitly using Java 7 (1.7) features if present. This may result in compilation errors in Eclipse.

One way to deal with this - look in Eclipse -> Window -> Preferences -> Installed JRE

• make sure you have Java 7 installation available under Installed JRE
• map this Java 7 installation onto Java 6 : Installed JRE -> Execution Environments -> Java SE 1.6

Alternatively, Java 7 JRE can be selected on per-project basis for each Netty module.

Git line ending configuration

We use native line ending for all source code (i.e. '\r' for *nix and MacOS X, '\r\n' for Windows.) Please configure your Git installation so that your build does not fail and you push bad files, following the instructions below:

• Dealing with line endings by Github
• Mind the End of Your Line by Tim Clem, for more information

Merging a pull request

A pull request often contains multiple comments. Those commits must be squashed into smaller number of commits with explanatory comments.

Do not merge a pull request via the web UI unless there's a good reason doing that. Refer to the 'Patch and Apply' section in the Github help page.

Writing a new post

Our web site is generated from an Awestruct project here. To post a new article, create a new branch, write a new post, and issue a pull request like usual contributions.

Design ideas

• Thread model in 4.x