Eclipse Jetty is an open source project with a long pedigree of contribution. Starting over 20 years ago, Jetty has had many committers over the years and owes much of its success to the people that make up the community. There are many ways that you may contribute to Jetty, and the goal of this guide is help you get there!

Participate in the Community

One of the best ways to start contribute and work with Eclipse Jetty is to get plugged into one of the existing communities. In any one of these you will come across users of neophyte to expert experience and as time permits the developers of Jetty themselves.

Mailing Lists

Mailing lists are a wonderful way to interact with the community at large and for a certain class of issue have the best chances of achieving resolution. There are a number of mailing lists available within the Jetty project and a good rule of thumb to choose between the developer and user lists is to ask yourself if your question is broadly interesting to the community, use the users list and if narrowly focused on Jetty internals or minutiae, then the dev list might be a better option.

Stack Overflow

From a simple support perspective it is hard to beat StackOverflow for interacting with a Jetty community. Numerous users have asked and had answered their questions on the platform by other users and developers alike.

  • Check out the general Jetty tag!

  • The Embedded-Jetty tag has a fair amount of traffic as well.

Github: Issues and Features

While not necessarily a support channel for solving a specific user problem, the issue tracker for Eclipse Jetty is a great location for addressing issues or suggesting features you want to see (or ideally contribute) in Jetty.

When you file a Github Issue in the Eclipse Jetty project there are a number of labels available and we encourage to you use them appropriately.

We have additionally identified and labeled a number of issues that may be appropriate for users of different levels of expertise that might want to contribute to Jetty but not have a specific goal or issue in mind.

Long story short, if you are interested in getting involved with the community, there are a number of options available and you are encouraged to participate at whatever level you like!

Participate in the Code

If you are more interested in digging into what makes Jetty tick then this some information that you will need to arm yourself with. First we start with how to checkout and build Jetty, then on to our general coding standards followed by the actual patch contribution process.

Source Control

The Eclipse Jetty project is located at Github under the Eclipse Foundation parent project. There are a number of branches that are generally of interest.

Table 1. Active Eclipse Jetty Branches



Servlet 5.0

Java 11+


Development (default branch)

Servlet 4.0

Java 11+



Servlet 3.1

Java 8



Servlet 3.0

Java 8



Servlet 2.0

Java 7



Servlet 1.0

Java 6

If you are planning on working with a specific issue within Jetty it is important to target the correct branch for a pull request. Pull requests that are targeted at Maintenance Branches are typically merged forward into subsequent branches while historical branches are left alone merge wise. Depending on the nature of an issue a historical branch may have an issue cherrypicked forward, but maintenance releases are merged wholesale forward as a matter of project policy.

Primary SCM

The primary repository for Jetty is:

Jetty Project Repository


Secondary SCM

These are the URLs for Jetty-related code and metadata. These are not needed to use Jetty; these are primarily of use for developers who are working with the open source project within Eclipse.

Administrative pom.xml file


Build related artifacts that release separately, common assembly descriptors, remote resources, etc.


Files associated with the development of Jetty — code styles, formatting, iplogs, etc.


Maven Build

Eclipse Jetty uses Apache Maven for managing the project metadata and controlling the build.

Building Jetty should simply be a matter of changing into the relevant directory and executing the following commands:

$ git clone https://github.com/eclipse/jetty.project.git
$ cd jetty.project
$ mvn install

All relevant dependencies should be downloaded into your local repository automatically and the build should proceed normally.

Jetty has a great many test cases that run through the course of its build. Many of these tests spin up embedded instances of Jetty itself, and it is not uncommon to see hundreds or more instances of Jetty start and stop during tests. Periodically we find some test cases to be more time dependent than they should be and this results in intermittent test failures. You can help track these down by opening an Issue.

Coding Standards

Jetty uses number of conventions for its source code. The developers of Jetty use a variety of tooling and editors when developing Jetty so standards and conventions are important!


The suggested configuration for Intelli-J when working with Jetty is available here: Intelli-J Codestyle


The Eclipse format configuration can be found here: Eclipse Java Formatting

There are also some templates available for Eclipse here: Eclipse Code Templates

Code Conventions

The following is an example of the Java formatting and naming styles to apply to Jetty:

import some.exact.ClassName;      // GOOD
import some.wildcard.package.*;   // BAD!

package org.always.have.a.package;

/* --------------------------------------------------------- */
/** Always have some javadoc
class MyClassName
    // indent by 4 spaces.
    // use spaced to indent
    // The code must format OK with default tabsize of 8.

    private static final int ALL_CAPS_FOR_PUBLIC_CONSTANTS=1;

    // Field prefixed with __ for static of _ for normal fields.
    // This convention is no longer mandatory, but any given
    // class should either consistently use this style or not.
    private static String __staticField;
    private Object _privateField;

    // use getters and setters rather than public fields.
    public void setPrivateField(Object privateField)

    public Object getPrivateField()
        return _privateField;

    public void doSomething()
        throws SomeException
        Object local_variable = _privateField;
        if (local_variable==null)
             // do Something

While Eclipse Jetty is an open source project it is also a member of the Eclipse Foundation which carries along some additional responsibilities. Intellectual Property is a hallmark concern of the Eclipse Foundation so you are encouraged to understand what that entails before diving in. As much as we would like to accept a tremendous pull request, without the proper chain of events being completed our hands are tied. That being said, the steps are not particularly onerous and we are happy to work with you to get them accomplished.

Logging Conventions

When deciding when and what to log, bear in mind a few things:

  • never use LOG.debug without a preceding if (LOG.isDebugEnabled())

  • we don’t want to pollute the log with very long stacktraces unless necessary

  • we don’t want to routinely produce logging events in response to data sent by a user

  • we should not call more than one LOG method for a single event: otherwise log messages may be interleaved and more confusing

  • we should never LOG.warn and then throw that exception, as that will result in double handling

  • we should seldom LOG.debug and then throw as that will make debug verbose and add little information

  • when interacting with a request, or information received from a client:

    • no logging unless isDebugEnabled, in which case you output at DEBUG level eg:

  catch (Throwable t)
     if (LOG.isDebugEnabled())
       LOG.debug("Something happened {} {} {}",x, y, z, t);
  • when calling into application code that throws an exception:

    • use INFO level, and use isDebugEnabled to cut down on the size of the logging of stack traces:

  catch (Throwable t)
    if (LOG.isDebugEnabled())
      LOG.info("Something happened {} {} {}", x, y, z, t);
      LOG.info("Something happened {} {} {} {}", x, y, z, t.toString());
  • when exceptions happen in jetty code:

    • mostly use WARN or ERROR level

    • if the exception is not entirely unexpected, can happen relatively frequently, or can potentially have a very long stack trace and you don’t want to clutter up the log, you can use isDebugEnabled to cut down on the size of the logging of the stacktrace:

  catch (Throwable t)
    if (LOG.isDebugEnabled())
      LOG.warn("Something happened {} {} {}", x, y, z, t);
      LOG.warn("Something happened {} {} {} {}", x, y, z, t.toString());
Be aware that LOG.warn("Something happened", t) is the same as LOG.warn("Something happened {}", t), at least for the default jetty logging. In both cases, the full stacktrace is output. If you only want the log message, you need to do LOG.warn("Something happened {}", t.toString()).

Contributing Patches

We love seeing people contribute patches to the Jetty project and the process is relatively simple. The requirements to commit are modest but very important to the Eclipse Foundation and the intellectual property of the open source project. The following is the general process by which we operate.

  • You must have a signed Eclipse Contributor Agreement.

  • This agreement must be under the same email address as the Git pull request originates from.

  • The commit must be signed.

  • When the pull request is made, a git-hook will validate the email address.

    • If the result is a green checkbox then the Jetty committers can review the pull request.

    • If the result is a red X then there is absolutely nothing the Jetty committers can do to accept the commit at this point.

  • This may not be the final form a commit will take, there may be some back and forth and you may be asked to re-issue a pull request.

Not everything is specifically relevant since we are at GitHub but the crux of things are detailed there. The ECA is critically important to the process.

Sign an Eclipse Contributor Agreement (ECA)

The Eclipse Foundation has a strong Intellectual Property policy which tracks contributions in detail to ensure that:

  1. Did the contributor author 100% of the content?

  2. Does the contributor have the rights to contribute this content to Eclipse?

  3. Is the contribution under the project’s license(s) (e.g. EPL)

A contributor needs to e-sign a Eclipse Contributor Agreement (for more explanation see the Eclipse ECA FAQ ) regardless of how their contribution patch is provided. You can familiarize yourself with the Eclipse wiki page at Contributing via Git. In order to have a pull request accepted by any Eclipse project you must complete this agreement.

Log into the Eclipse home page (you will need to create an account with the Eclipse Foundation if you have not already done so), click on "Eclipse ECA", and complete the form. Be sure to use the same email address when you create any Git commit records.

Configuring Git

GitHub has copious amounts of quality documentation on how to interact with the system and you will minimally need to configure the user.email property. Check out the following guide on GitHub for more information.

Making the Commit

When making the commit for the pull request it is vital that you "sign-off" on the commit using git commit -s option. Without this sign-off, your patch cannot be applied to the Jetty repository because it will be rejected.

You can check out the guide at Github for more information.

One way to think of this is that when you sign the ECA you are indicating that you are free to contribute to eclipse, but that doesn’t mean everything you ever do can be contributed. Using the commit signing mechanism indicates that your commit is under the auspices of your agreement.

If a pull request is for a particular issue in our repository then the format of the commit message is important. The message should follow the form "Issue #123 <description of the commit>". When the Jetty project runs releases we have an automated process that scans for commits with this format for inclusion in our VERSION.txt file.

> git commit -s -m "Issue #123 resolving the issue by adding widget"

The Pull Request

Pull requests are very much a GitHub process so best explained by Github.

Our Policies

We wholeheartedly welcome contributions to Jetty and will do our best to process them in a timely fashion. While not every contribution will be accepted, our commitment is to work with interested parties on the things they care about. With that in mind, we can only handle pull requests with actively engaged parties. We reserve the right to abandon pull requests whose authors do no respond in a timely fashion.

We will generally adhere to the following time frames for contributions:

  • Invalid Pull Requests - 1 week

    • These pull requests do not follow the contribution requirements for some reason, be it missing contributor agreement or the wrong email.

    • We will try and follow up with the pull request author to resolve the issue but much of this is out of our hands and are between committer and the Eclipse Foundation.

    • If we do not hear from the contributor after a week we will close the pull request.

  • Valid Pull Requests - 2 weeks

    • These pull requests have a green check mark after the commit title.

    • If the pull request can be immediately applied we will do so.

    • There may need to be some conversation on the issue in which case a committer will follow up with the author in the pull request.

    • If the original contributor does not respond within 2 weeks we may close the commit.

    • If we see value in the commit yet the author has not responded after 2 weeks we may make some variation of the commit ourselves.

Participate in the Documentation

Another wonderful way to help with Eclipse Jetty is to help contribute to our corpus of documentation. We have made an effort to reduce the barriers to contributing to our documentation, and many contributors find our documentation as a low-key way to participate and learn the process.

Source Control and Maven Build.

The Jetty documentation is a module within the overall Jetty project and is build as a part of the standard build process. As such to checkout the documentation you can follow the same process as checking out Jetty itself.

As a part of the main Jetty project the documentation is build through the same process as Jetty. However, it is a more independent module and can be worked with much simpler by building strictly the jetty-documentation module.

$ git clone https://github.com/eclipse/jetty.project.git
$ cd jetty.project/jetty-documentation
$ mvn install

While maven is running you may see a lot of files being downloaded. If you are not familiar with Maven you are seeing Maven set up the execution environment for generating the documentation.

The build is finished once you see a message akin to:

[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9.272 s
[INFO] Finished at: 2018-04-09T13:06:10-05:00
[INFO] Final Memory: 74M/247M
[INFO] ------------------------------------------------------------------------

At this point you open your web browser and view the produced documentation (under the target/html directory)!

Pay close attention to the build output for lines like:

asciidoctor: WARNING: 9-jsp.adoc: line 0: id assigned to section already in use: ag-http2

This indicates that an ID is being reused and should be resolved or else deep linking will work correctly.

The Render Chain Explained

The Jetty documentation is all written in asciidoc. The maven build uses the asciidoctor-maven-plugin to process specific index.adoc[] files which act as the root structure for various guides (Administrative, Developer, QuickStart, etc). The main pom.xml file also provides a maven profile which when activated can produce the guides in both pdf and epub formats.

Project Structure

It may be useful to understand the layout of the documentation before digging into the details. The following table lists some helpful directories and their purpose.

Table 2. Documentation Layout


root of asciidoc layout


root structure for each individual guide


post build, where the rendered html files will appear


post build (-Palt-formats) pdf files


post build (-Palt-formats) epub files

Guide Structure

Each guide starts with an index.adoc file which acts as the point of origin for the document structure. It will declare useful metadata for the proper rendering of the overall guide and use the asciidoc include directive to pull in content for each chapter which are conveniently named by chapter number and name.


Below is list of conventions that should be followed when developing documentation within this framework. These are not set in stone but you are encouraged to follow them when possible.

ventilated prose

Each sentence should generally be on its own line with a hard return at the end of the line. Asciidoc rendering does not treat this style as separate lines and will produce paragraphs correctly. The primary benefit is that you can easily see changes between versions of files, and it makes it trivial to quickly look through a pull request. Additional benefits are the ability to comment out a sentence mid paragraph or move sentences around within a paragraph. Enabling Soft Line Wrap in your favorite editor can make this a bit easier to stomach.


Critically important for being able to generate url’s that can be used in a persistent fashion. Without sane id’s the chapters and sections will have generated id which are rooted in some obscure location based voodoo. A url using these 'e12c8673' type links will not be durable across generations of the documentation. These id’s need to be used on chapters and sections two deep, and anywhere that you intend to cross link deeper. The id values go into a global namespace so they must be unique across the entire document or the last example will win and any cross links will go there. Links inside of a guides narrative structure should be prefixed with an acronym (contributor guide = cg-) while any links within the topics structure should be prefixed with t- and ideally the name of the topic it corresponds to.

link vs xref

The link: item should be generally used for linking around the document when you want to choose the text that will be rendered in the link itself. However if you are linking to a section and want to use the title itself as the link text, use the xref: tag without the hashmark in front of the link id.

cross guide linkage

To link to another guide it is best to use a property to address it. The following guide shortcuts are provided.





This is a test to link to link:{DISTGUIDE}[Distribution Guide]

This is a test to deep link to link:{DISTGUIDE}#startup[Distribution Guide Deep Link]

This is a test to link to Distribution Guide

This is a test to deep link to Distribution Guide Deep Link


Images are placed in the /images* directory of the guide they should appear in and then referenced with a image: tag.



version differences

In general differences in functionality within a release should go into nested sections and use titles like 'Prior to: ' or 'In version: '.

license blocks

Each adoc file should contain the license block that exists in the index.adoc file and a copy has been added to the bottom of this page as well for reference.

// ========================================================================
// Copyright (c) 1995 Mort Bay Consulting Pty Ltd and others.
// This program and the accompanying materials are made available under the
// terms of the Eclipse Public License v. 2.0 which is available at
// https://www.eclipse.org/legal/epl-2.0, or the Apache License, Version 2.0
// which is available at https://www.apache.org/licenses/LICENSE-2.0.
// SPDX-License-Identifier: EPL-2.0 OR Apache-2.0
// ========================================================================

Some admonition examples:

A note about the previous case to be aware of.
Important notes are marked with an icon.
Tips that make your life easier.
Places where you have to be careful what you are doing.
Where extreme care has to be taken. Data corruption or other nasty things may occur if these warnings are ignored.


  • If an included file ends with a list entry, it needs to have two empty lines at the end of the file in order for the section rendering to work correctly.


Reporting Security Issues

There are a number of avenues for reporting security issues to the Jetty project available. If the issue is directly related to Jetty itself then reporting to the Jetty developers is encouraged. The most direct method is to send e-mail to security@webtide.com. Since Webtide is comprised of the active committers of the Jetty project this is our preferred reporting method. We are generally flexible in how we work with reporters of security issues from an attribution perspective but we reserve the right to act in the interests of the Jetty project in all circumstances.

If the issue is related to Eclipse or its Jetty integration then we encourage you to reach out to security@eclipse.org.

If the issue is related to some third party integration with Jetty we are happy to work with you to identify the proper entity and worth with them to properly address any issue so either of the above outreaches is fine.

We prefer that security issues are reported directly to Jetty developers via email as opposed through GitHub Issues since there is currently no facility for private issues. There is an unofficial thread for this support at github you are welcome to follow along on.

Thank you!

Your interest in contributing to Eclipse Jetty is welcome and if there is anything you feel this guide is lacking please let us know. Feel free to open an Issue as described in this document and perhaps even contribute your suggestion to this document itself!

Our current guides are:

  • {GUIDEBASEURL}/quickstart/[Distribution Quickstart Guide]

  • {GUIDEBASEURL}/contribution/[Contribution Guide]