Correct contribution-guide documentation

Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
This commit is contained in:
Joakim Erdfelt 2024-02-06 10:24:01 -06:00
parent a7d14d6874
commit 721b1743cb
No known key found for this signature in database
GPG Key ID: 2D0E1FB8FE4B68B4
9 changed files with 1 additions and 660 deletions

View File

@ -1,19 +0,0 @@
//
// ========================================================================
// 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
// ========================================================================
//
[[cg-introduction]]
== Welcome!
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!

View File

@ -1,56 +0,0 @@
//
// ========================================================================
// 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
// ========================================================================
//
[[cg-community]]
== 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.
[[cg-mailing-lists]]
=== 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.
* Jetty Developers List
** Join - https://dev.eclipse.org/mailman/listinfo/jetty-dev
** Archives - http://dev.eclipse.org/mhonarc/lists/jetty-dev/
* Jetty Users List
** Join - https://dev.eclipse.org/mailman/listinfo/jetty-users
** Archives - http://dev.eclipse.org/mhonarc/lists/jetty-users/
* Jetty Announcements List
** Join - https://dev.eclipse.org/mailman/listinfo/jetty-announce
** Archives - http://dev.eclipse.org/mhonarc/lists/jetty-announce/
[[cg-stackoverflow]]
=== Stack Overflow
From a simple support perspective it is hard to beat http://stackoverflow.com[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 https://stackoverflow.com/questions/tagged/jetty[Jetty] tag!
* The https://stackoverflow.com/questions/tagged/embedded-jetty[Embedded-Jetty] tag has a fair amount of traffic as well.
[[cg-issues]]
=== 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.
* http://github.com/eclipse/jetty.project[Issues at Github].
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.
* https://github.com/eclipse/jetty.project/issues?q=is%3Aopen+is%3Aissue+label%3A%22Help+Wanted%22[Help Wanted]
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!

View File

@ -1,303 +0,0 @@
//
// ========================================================================
// 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
// ========================================================================
//
[[cg-source]]
== 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.
[[cg-community-source]]
=== Source Control
The https://github.com/eclipse/jetty.project[Eclipse Jetty project] is located at https://github.com[Github] under the Eclipse Foundation https://github.com/eclipse[parent project]. There are a number of branches that are generally of interest.
.Active Eclipse Jetty Branches
[cols="4"]
|===
| https://github.com/eclipse/jetty.project/tree/jetty-12.0.x[jetty-12.0.x] | Development | Servlet 6.0 | Java 17+
| https://github.com/eclipse/jetty.project/tree/jetty-11.0.x[jetty-11.0.x] | Development | Servlet 5.0 | Java 11+
| https://github.com/eclipse/jetty.project/tree/jetty-10.0.x[jetty-10.0.x] | Development (default branch) | Servlet 4.0 | Java 11+
| https://github.com/eclipse/jetty.project/tree/jetty-9.4.x[jetty-9.4.x] | End of Community Support | Servlet 3.1 | Java 8
| https://github.com/eclipse/jetty.project/tree/jetty-9.3.x[jetty-9.3.x] | End of Life | Servlet 3.1 | Java 8
| jetty-8 | Historical | Servlet 3.1 | Java 6
| jetty-7 | Mythical | Servlet 2.5 | Java 5
|===
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::
https://github.com/eclipse/jetty.project
==== 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::
https://github.com/eclipse/jetty.parent
Build related artifacts that release separately, common assembly descriptors, remote resources, etc.::
https://github.com/eclipse/jetty.toolchain
[[cg-contributing-build]]
=== Maven Build
Eclipse Jetty uses http://maven.apache.org/[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:
[source, screen, subs="{sub-order}"]
....
$ 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.
____
[NOTE]
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 https://github.com/eclipse/jetty.project/issues[Issue].
____
[[cg-coding-standards]]
=== 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!
==== IntelliJ IDE
The suggested configuration for the IntelliJ IDE when working with Jetty is available in the code tree
`/build-resources/jetty-codestyle-intellij.xml`
==== Eclipse IDE
The Eclipse IDE format can be found in the code tree
`/build-resources/jetty-codestyle-eclipse-ide.xml`
==== Code Conventions
The following is an example of the Java formatting and naming styles to apply to Jetty:
[source, java, subs="{sub-order}"]
----
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)
{
_privateField=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:
[source, java, subs="{sub-order}"]
----
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:
[source, java, subs="{sub-order}"]
----
catch (Throwable t)
{
if (LOG.isDebugEnabled())
LOG.info("Something happened {} {} {}", x, y, z, t);
else
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:
[source, java, subs="{sub-order}"]
----
catch (Throwable t)
{
if (LOG.isDebugEnabled())
LOG.warn("Something happened {} {} {}", x, y, z, t);
else
LOG.warn("Something happened {} {} {} {}", x, y, z, t.toString());
}
----
____
[TIP]
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())`.
____
[[cg-patches]]
=== 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.
[[cg-contributing-eca]]
==== 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 projects license(s) (e.g. EPL)
A contributor needs to e-sign a Eclipse Contributor Agreement (for more explanation see the http://www.eclipse.org/legal/ecafaq.php[Eclipse ECA FAQ] ) regardless of how their contribution patch is provided.
You can familiarize yourself with the Eclipse wiki page at http://wiki.eclipse.org/Development_Resources/Contributing_via_Git[Contributing via Git].
In order to have a pull request accepted by any Eclipse project you *must* complete this agreement.
____
[TIP]
Log into the https://www.eclipse.org[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.
____
[[t-contributing-git-config]]
==== 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 link:https://help.github.com/articles/setting-your-email-in-git[guide on GitHub] for more information.
[[t-contributing-making-the-commit]]
==== 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 link:https://help.github.com/articles/signing-tags-using-gpg[guide at Github] for more information.
____
[TIP]
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.
[source, screen]
----
> git commit -s -m "Issue #123 resolving the issue by adding widget"
----
[[cg-the-pull-request]]
==== The Pull Request
Pull requests are very much a GitHub process so best link:https://help.github.com/articles/creating-a-pull-request[explained by Github].
[[cg-our-policies]]
==== 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.

View File

@ -1,201 +0,0 @@
//
// ========================================================================
// 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
// ========================================================================
//
[[cg-documentation]]
== 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.
[[cg-documentation-format]]
=== 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 link:#cg-community-source[same process] as checking out Jetty itself.
As a part of the main Jetty project the documentation is build through the link:#cg-contributing-build[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.
[source, screen, subs="{sub-order}"]
....
$ 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:
[source, screen, subs="{sub-order}"]
....
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[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)!
[TIP]
====
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.
====
[[cg-documentation-render]]
=== The Render Chain Explained
The Jetty documentation is all written in https://asciidoctor.org/docs/user-manual/[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.
[[cg-documentation-structure]]
=== 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.
.Documentation Layout
[cols="2"]
|===
| src/main/asciidoc | root of asciidoc layout
| src/main/asciidoc/*-guide | root structure for each individual guide
| target/html | post build, where the rendered html files will appear
| target/pdf | post build (-Palt-formats) pdf files
| target/epub | post build (-Palt-formats) epub files
|===
[[cg-documentation-guide]]
=== 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.
[[cg-documentation-conventions]]
=== Conventions
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.
id's::
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.
* DISTGUIDE
* EMBEDGUIDE
* QUICKGUIDE
* CONTRIBUIDE
....
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 link:{DISTGUIDE}[Distribution Guide]
This is a test to deep link to link:{DISTGUIDE}#startup[Distribution Guide Deep Link]
images::
Images are placed in the `/images*` directory of the guide they should appear in and then referenced with a `image:` tag.
....
image:small_powered_by.gif[image,width=340]
....
image:small_powered_by.gif[image,width=340]
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:
______________________________________________
[NOTE]
A note about the previous case to be aware of.
______________________________________________
________________________________________
[IMPORTANT]
Important notes are marked with an icon.
________________________________________
________________________________
[TIP]
Tips that make your life easier.
________________________________
_______________________________________________________
[CAUTION]
Places where you have to be careful what you are doing.
_______________________________________________________
__________________________________________________________________________________________________________________
[WARNING]
Where extreme care has to be taken. Data corruption or other nasty
things may occur if these warnings are ignored.
__________________________________________________________________________________________________________________
==== Oddities
* 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.

View File

@ -1,30 +0,0 @@
//
// ========================================================================
// 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
// ========================================================================
//
[[cg-security]]
== Security
[[cg-security-reporting]]
=== 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 https://github.com/isaacs/github/issues/37[unofficial thread] for this support at github you are welcome to follow along on.

View File

@ -1,25 +0,0 @@
//
// ========================================================================
// 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
// ========================================================================
//
[[cg-conclusion]]
== 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 {GITDOCURL}/contribution-guide[this document] itself!
[[cg-contributing-guides]]
Our current guides are:
* {GUIDEBASEURL}/quickstart/[Distribution Quickstart Guide]
* {GUIDEBASEURL}/contribution/[Contribution Guide]

View File

@ -1,25 +0,0 @@
//
// ========================================================================
// 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
// ========================================================================
//
:doctitle: Eclipse Jetty: Contribution Guide
:toc-title: Contribution Guide
:breadcrumb: Home:../index.html | Contribution Guide:./index.html
:idprefix: cg-
include::../config.adoc[]
include::1-introduction.adoc[]
include::2-community.adoc[]
include::3-source.adoc[]
include::4-documentation.adoc[]
include::5-security.adoc[]
include::6-conclusion.adoc[]

View File

@ -23,7 +23,7 @@ The Eclipse Jetty Operations Guide targets sysops, devops, and developers who wa
The Eclipse Jetty Programming Guide targets developers who want to use the Eclipse Jetty libraries in their applications, and advanced sysops/devops that want to customize the deployment of web applications.
== xref:contribution-guide/index.adoc[Jetty Contribution Guide]
== https://eclipse.dev/jetty/documentation/contribution-guide/index.html[Jetty Contribution Guide]
The Eclipse Jetty Programming Guide targets developers that wish to contribute to the Jetty Project with code patches or documentation improvements.