This is an automated email from the ASF dual-hosted git repository.
jamesbognar pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/juneau.git
The following commit(s) were added to refs/heads/master by this push:
new 5a7478c43e Update docs
5a7478c43e is described below
commit 5a7478c43e28642813d77b881dcea563a9df6488
Author: James Bognar <[email protected]>
AuthorDate: Sun Dec 28 18:27:40 2025 -0500
Update docs
---
docs/pages/developer-info/01.00.DeveloperLinks.md | 20 ++
.../developer-info/02.01.BecomingAContributor.md | 17 ++
.../02.02.NonCommittersContribute.md | 31 ++
.../developer-info/02.03.NewMemberGuidelines.md | 308 ++++++++++++++++++++
.../developer-info/02.04.NewReleaseGuidelines.md | 312 +++++++++++++++++++++
.../developer-info/02.05.VersioningGuidelines.md | 205 ++++++++++++++
.../02.06.CodeFormattingStylesheet.md | 258 +++++++++++++++++
.../developer-info/02.08.DevelopmentWishList.md | 84 ++++++
docs/pages/developer-info/03.00.CurrentMembers.md | 27 ++
docs/pages/developer-info/04.00.BlogIndex.md | 32 +++
.../pages/developer-info/04.01.JUnitTestResults.md | 10 +
.../04.02.RESTMediaTypeLessPOJORequests.md | 16 ++
.../04.03.Juneau720DocumentationPreview.md | 18 ++
...SupportForAutoValidationInSwaggerAnnotations.md | 29 ++
.../developer-info/04.05.DocumentationReorg.md | 16 ++
.../04.06.BehaviorChangeOnDefaultRestMethodPath.md | 18 ++
.../04.07.DualPurposeRESTJavaInterfaces.md | 27 ++
.../04.08.PetStoreApplicationNowUsesJPA.md | 16 ++
.../04.09.NewArticleDualPurposeInterfaces.md | 12 +
.../04.10.DefaultSystemConfiguration.md | 43 +++
.../developer-info/04.11.SpringBootIntegration.md | 22 ++
.../pages/developer-info/04.12.SourceJavadocTag.md | 16 ++
.../04.13.ImportStatementsInConfigurationFiles.md | 16 ++
....SerializerAndParserConfigurationAnnotations.md | 23 ++
.../04.15.NewAndImprovedRestClient.md | 59 ++++
docs/pages/developer-info/05.00.ArticlesIndex.md | 17 ++
docs/sidebars.ts | 167 +++++++++++
.../how-to/NonCommittersContribute.1.png | Bin 0 -> 56741 bytes
.../how-to/NonCommittersContribute.2.png | Bin 0 -> 120619 bytes
29 files changed, 1819 insertions(+)
diff --git a/docs/pages/developer-info/01.00.DeveloperLinks.md
b/docs/pages/developer-info/01.00.DeveloperLinks.md
new file mode 100644
index 0000000000..9e026b3ffa
--- /dev/null
+++ b/docs/pages/developer-info/01.00.DeveloperLinks.md
@@ -0,0 +1,20 @@
+---
+id: 01.00.DeveloperLinks
+title: Developer Links
+---
+
+## Developer Links
+
+Useful links for Apache Juneau developers:
+
+- **[Jenkins](https://ci-builds.apache.org/job/Juneau/)** - Continuous
integration and deployment
+- **[Confluence](https://cwiki.apache.org/confluence/display/JUNEAU)** -
Collaborative documentation and project management
+- **[Confluence
Blog](https://cwiki.apache.org/confluence/display/JUNEAU/Blog)** - Project
updates and announcements
+- **[Twitter](https://twitter.com/apachejuneau)** - Follow Apache Juneau on
Twitter
+- **[Slack](https://apachejuneau.slack.com)** - Real-time discussions and
collaboration
+- **[Apache Mailing Lists](https://juneau.apache.org/mail-lists.html)** -
Project communication
+ - **[email protected]** - Development discussions
+ - **[email protected]** - Commit notifications
+ - **[email protected]** - User discussions
+- **[Pony Mail](https://lists.apache.org/[email protected])** -
Email archive system
+
diff --git a/docs/pages/developer-info/02.01.BecomingAContributor.md
b/docs/pages/developer-info/02.01.BecomingAContributor.md
new file mode 100644
index 0000000000..e32bd9d883
--- /dev/null
+++ b/docs/pages/developer-info/02.01.BecomingAContributor.md
@@ -0,0 +1,17 @@
+---
+id: 02.01.BecomingAContributor
+title: Becoming a contributor
+---
+
+We are actively looking for contributors to join and take an active role in
the project!
+
+To become a contributor, we recommend joining and contributing code changes
through the mailing list. Once you're contributing and your work is good, one
of our team may invite you to be a committer. After that, the team will call
for a vote. When that happens, if you accept, the following process kicks into
place:
+
+* Download and print the Apache Contributor License Agreement from the [New
committers guide](https://www.apache.org/dev/new-committers-guide.html).
+* Sign and fax (or email) the CLA to Apache.
+* Wait for your name to appear on the [list of received
CLAs](https://whimsy.apache.org/officers/cla). Once that's done, let us know
and we can apply to Apache Infrastructure to have your account created. We'll
need the following information: Full name, preferred email address, preferred
unix account name.
+* Read the [New committers
guide](https://www.apache.org/dev/new-committers-guide.html).
+* More information for new committers can be found in the [Committers
information doc](https://www.apache.org/dev/committers.html).
+
+The Juneau project does not currently have distinct roles for Committers and
PMC (Project Management Committee). All Committers are also voting members.
+
diff --git a/docs/pages/developer-info/02.02.NonCommittersContribute.md
b/docs/pages/developer-info/02.02.NonCommittersContribute.md
new file mode 100644
index 0000000000..6a391c6333
--- /dev/null
+++ b/docs/pages/developer-info/02.02.NonCommittersContribute.md
@@ -0,0 +1,31 @@
+---
+id: 02.02.NonCommittersContribute
+title: How non-committers can contribute code
+---
+
+This guide is for those who are new to Juneau and want to contribute code,
specifically those who do not have write access to our repositories:
+- [https://github.com/apache/juneau](https://github.com/apache/juneau)
+-
[https://github.com/apache/juneau-website](https://github.com/apache/juneau-website)
+
+## Step-by-step guide
+
+1. **Create a fork** of the repository you want to contribute to -
[https://github.com/apache/juneau](https://github.com/apache/juneau) or
[https://github.com/apache/juneau-website](https://github.com/apache/juneau-website)
- the fork button is in the top right corner
+
+ 
+
+2. **Clone your fork** of the repository locally
+3. **Make changes** to your local clone. If you haven't already, create a JIRA
issue.
+4. **Commit them locally**, using the commit format of `"JIRA-TICKET - What
you changed"` e.g. `"JUNEAU-123 - Made JUNEAU better."`
+5. **Push these changes** to your fork
+6. **Navigate back** to your fork or to our github repositories and you'll see
an option to create a new pull request.
+7. **Click on the blue link "Pull request"** to bring up the create pull
request screen.
+8. **After you've filled out a title and description**, click on the green
"Create pull request" button.
+
+ 
+
+## External links
+
+- [Fork a
Repository](https://docs.github.com/en/get-started/quickstart/fork-a-repo)
+- [Creating a Pull request from a
Fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork)
+- [Creating a Pull
request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request)
+
diff --git a/docs/pages/developer-info/02.03.NewMemberGuidelines.md
b/docs/pages/developer-info/02.03.NewMemberGuidelines.md
new file mode 100644
index 0000000000..44800a124b
--- /dev/null
+++ b/docs/pages/developer-info/02.03.NewMemberGuidelines.md
@@ -0,0 +1,308 @@
+---
+id: 02.03.NewMemberGuidelines
+title: New member guidelines
+---
+
+This document provides information on adding new Committers/PMC members to
Apache Juneau.
+
+The Apache Juneau team does not differentiate between Committers and PMC
members. Any member of the PMC can propose a new member of the PMC.
+
+## Summary
+
+The general process is as follows:
+
+1. Discussion
+2. Call a vote
+3. Close the vote
+4. Invite the new committer
+
+If they accept, then do:
+
+1. If committer is also to be a PMC member, nominator sends email to board@
asking for acknowledgement of new PMC member
+2. Wait 72 hours for lazy acceptance by the board
+3. If the candidate is already a committer on another project, accept the
committer and skip to step 8
+4. Accept the committer and request they file an ICLA, notifying the PMC and
choosing an available Apache id
+5. Wait until we see that receipt of iCLA (Individual Contributor License
Agreement) is recorded
+6. Request creation of the committer account if not already done by Secretary
+7. Now wait until root says it is done
+8. PMC Chair to enable svn and other access
+9. Add committer to the appropriate groups in JIRA and CWiki
+10. Notify the committer of completion
+11. Announce the new committer
+
+## Discussion
+
+Before approving membership, it's assumed that the person has actively
contributed through this process:
+[Contributing for
Non-committers](https://cwiki.apache.org/confluence/display/JUNEAU/Contributing+for+Non-committers)
+
+Once it's been shown that the member submits good work, the team can invite
them to be a full member.
+
+```text
+To: [email protected]
+[DISCUSS] Jane Doe PMC membership
+
+I'd like to discuss adding Jane Doe as a PMC member.
+
+State reason why.
+```
+
+## Call for vote
+
+If there is consensus that the proposed member is suitable, then there should
be a formal vote in the PMC private alias:
+
+```text
+To: [email protected]
+[VOTE] Jane Doe PMC membership
+
+I'm pleased to be calling this vote for inviting [Jane Doe] to be a member of
the Juneau PMC.
+
+This vote will be open at least until 04-May-2016 1:30pm and passes if a
majority of at least three +1 Apache Juneau PMC votes are cast.
+(needs to be at least 72 weekday hours)
+
+[ ] +1 Approve invitation
+[ ] 0 I don't feel strongly about it, but don't object
+[ ] -1 Do not approve invitation because...
+
+State reason why.
+```
+
+## Close the vote
+
+If the vote is successful, the proposer should send a message to the PMC
private alias.
+
+```text
+To: [email protected]
+[VOTE][RESULT] Jane Doe PMC membership
+
+Voting for PMC membership for [Jane Doe] is now closed. The vote has passed
with the following tally:
+
+John Smith, PMC, +1
+...
+```
+
+## Board notification
+
+Adding a new PMC member requires sending an email notification to the Board's
mailing list copying the PMC's private mailing list and waiting 72 hours. Once
the notification appears in the archives, an invitation may be sent out 72
hours later (unless a Director objects to the nomination). The detailed process
can be found in the June 2013 board minutes under section "7 G. Amend the
Procedure for PMC Membership Changes"
+
+**Do NOT send an unconditional invite to the potential member before the 72
hour NOTICE period has expired!** It would be very awkward if the invite has to
be withdrawn if the board objects.
+
+This notification may be sent by the PMC Chair, or by any other PMC member if
they include a link to the formal PMC decision or vote on their private@ list.
+
+Ensure the PMC private list is copied - but do not Cc the potential member.
For example:
+
+```text
+To: [email protected]
+Cc: [email protected]
+[NOTICE] Jane Doe for Juneau PMC
+
+Juneau proposes to invite [Jane Doe] (janedoe) to join the PMC.
+
+(include if a vote was held)
+The vote result is available here: https://lists.apache.org/...
+```
+
+**It should noted that there is a grace period of 72 hours from when the above
NOTICE is sent to the board to when the proposed member is formally invited.
This is an important part of the overall process. Failure to do this can result
in an embarrassing situation for people involved.**
+
+## PMC Invite
+
+After 72 hours, Jane Doe should be invited to join the PMC. Check to see if
the proposed committer already has an Apache id.
+
+### Sample message for proposed committers without an Apache id:
+
+```text
+To: [email protected]
+Cc: [email protected]
+Subject: You're invited to join the Juneau PMC!
+
+Hello [Jane Doe],
+
+The Juneau Project Management Committee (PMC) hereby offers you committer
privileges to the project as well as membership in the PMC. These privileges
are offered on the understanding that you'll use them reasonably and with
common sense. We like to work on trust rather than unnecessary constraints.
+
+Being a committer enables you to more easily make changes without needing to
go through the patch submission process. Being a PMC member enables you to
guide the direction of the project.
+
+Being a committer does not require you to participate any more than you
already do. It does tend to make one even more committed. You will probably
find that you spend more time here.
+
+Of course, you can decline and instead remain as a contributor, participating
as you do now.
+
+A. This personal invitation is a chance for you to accept or decline in
private. Either way, please let us know in reply to the
[email protected] address only.
+
+B. If you accept, the next step is to register an iCLA if you do not have an
Apache id.
+
+If you have an Apache id, let the PMC know by return email what your id is.
+
+1. If you do not have an Apache id, details of the iCLA and the forms are
found here:
+ http://www.apache.org/licenses/#clas
+
+2. Instructions for its completion and return to the Secretary of the ASF are
found here:
+ http://www.apache.org/licenses/#submitting
+
+3. When you transmit the completed iCLA, request to notify the Apache Juneau
and choose a unique Apache id. Look to see if your preferred id is already
taken at http://people.apache.org/committer-index.html. This will allow the
Secretary to notify the PMC when your iCLA has been recorded.
+
+When recording of your iCLA is noticed, you will receive a follow-up message
with the next steps for establishing you as a committer.
+```
+
+### Sample message for existing Apache committers:
+
+```text
+To: [email protected]
+Cc: [email protected]
+Subject: You're invited to join the Juneau PMC!
+
+Hello [Jane Doe],
+
+The Juneau Project Management Committee (PMC) hereby offers you committer
privileges to the project as well as membership in the PMC. These privileges
are offered on the understanding that you'll use them reasonably and with
common sense. We like to work on trust rather than unnecessary constraints.
+
+Being a committer enables you to more easily make changes without needing to
go through the patch submission process. Being a PMC member enables you to
guide the direction of the project.
+
+Being a committer does not require you to participate any more than you
already do. It does tend to make one even more committed. You will probably
find that you spend more time here.
+
+Of course, you can decline and instead remain as a contributor, participating
as you do now.
+
+This personal invitation is a chance for you to accept or decline in private.
Either way, please let us know in reply to the [email protected]
address only.
+```
+
+## PMC Accept
+
+This is the followup email after the new committer has accepted the
invitation.
+
+This message can be skipped for existing Apache committers.
+
+### Message for new Apache committers:
+
+```text
+To: [email protected]
+Cc: [email protected]
+Subject: Re: invitation to become Juneau PMC member
+
+Welcome. Here are the next steps. After that we will make an announcement to
the juneau-dev list.
+
+You need to have an Apache id. If you do not already have one, you will need
to send an individual Contributor License Agreement to the ASF. If you also
make contributions done in work time or using work resources then consult with
your company to see if they want to file a corporate CLA. Ask us (the PMC) if
you have any questions.
+
+http://www.apache.org/licenses/#clas
+
+You need to choose a preferred ASF user name and alternatives. In order to
ensure it is available you can view a list of taken ids at
+
+http://people.apache.org/committer-index.html
+
+Please notify us when you have submitted the iCLA and by what means you did
so. This will enable us to monitor its progress.
+
+We will arrange for your Apache user account when the iCLA has been recorded.
+
+After that is done, please make followup replies to the [email protected]
list. We generally discuss everything there and keep the
[email protected] list for occasional matters which must be private.
+
+Most important links for developers can be found here:
+
+http://juneau.apache.org/index.html#community.html
+
+The developer section of the Apache website describes the roles and provides
other resources:
+
+http://www.apache.org/foundation/how-it-works.html
+http://www.apache.org/dev/
+
+Just as before you became a committer, participation in any ASF community
requires adherence to the ASF Code of Conduct:
+
+https://www.apache.org/foundation/policies/conduct.html
+
+Best regards,
+The Apache Juneau PMC
+```
+
+## PMC Account Creation
+
+### For new Apache committers:
+
+* Request new account for new committer:
+ https://whimsy.apache.org/officers/acreq
+* Follow the instructions here.
+
+### For new and existing Apache committers:
+
+* Make sure user is listed on this page to ensure iCLA has been received.
+ https://svn.apache.org/repos/private/foundation/officers/iclas.txt
+* Add user to Juneau project using Whimsy
+ https://whimsy.apache.org/roster/committee/juneau
+* Add user permissions to edit the Confluence pages:
+
https://cwiki.apache.org/confluence/spaces/editspacepermissions.action?key=JUNEAU
+* Add user to list of developers in juneau-root/pom.xml.
+* Add user to list of members in juneau-website/templates/community.html.
+
+## PMC Done
+
+After the committer account is established, send the following message:
+
+### Message for new Apache committers:
+
+```text
+To: [email protected], [email protected]
+Subject: Account request: Jane Doe
+
+As you know, the ASF Infrastructure has set up your committer account as the
username '[janedoe]'.
+
+Please follow the instructions to set up your SSH, svn password, svn
configuration, mail forwarding, etc.
+http://www.apache.org/dev/#committers
+
+Please subscribe to the Juneau Project Management Committee mailing list
[email protected].
+
+You have commit access to specific sections of the ASF repository, as follows:
+https://gitbox.apache.org/repos/asf/juneau.git
+https://gitbox.apache.org/repos/asf/juneau-website.git
+
+If you haven't done so already, you'll need to use the GitBox Account Linking
Utility to get write access to these repositories.
+https://gitbox.apache.org/setup/
+
+The general "committers" at:
+https://svn.apache.org/repos/private/committers
+
+If you have any questions during this phase, then please see the following
resources:
+Apache developer's pages: http://www.apache.org/dev/
+
+Naturally, if you don't understand anything be sure to ask us on the Juneau
dev mailing list.
+
+Documentation is maintained by volunteers and hence can be out-of-date and
incomplete - of course you can now help fix that.
+
+A PMC member will announce your election to the dev list soon.
+```
+
+### Message for existing Apache committers:
+
+```text
+To: [email protected], [email protected]
+Subject: Account request: Jane Doe
+
+Welcome to Apache Juneau!
+
+Please subscribe to the Juneau Project Management Committee mailing list
[email protected].
+
+You have commit access to specific sections of the ASF repository, as follows:
+https://gitbox.apache.org/repos/asf/juneau.git
+https://gitbox.apache.org/repos/asf/juneau-website.git
+
+The general "committers" at:
+https://svn.apache.org/repos/private/committers
+
+If you have any questions during this phase, then please see the following
resources:
+Apache developer's pages: http://www.apache.org/dev/
+
+Naturally, if you don't understand anything be sure to ask us on the Juneau
dev mailing list.
+
+Documentation is maintained by volunteers and hence can be out-of-date and
incomplete - of course you can now help fix that.
+
+A PMC member will announce your election to the dev list soon.
+```
+
+## PMC Announce
+
+This is the email to announce to juneau-dev once the account has been created.
+
+```text
+To: [email protected]
+Subject: New PMC member: Jane Doe
+
+The Project Management Committee (PMC) for Apache Juneau has invited [Jane
Doe] to become a PMC member and we are pleased to announce that he has accepted.
+
+(add specific details here)
+
+Being a committer enables easier contribution to the project since there is no
need to go via the patch submission process. This should enable better
productivity. Being a PMC member enables assistance with the management and to
guide the direction of the project.
+```
+
diff --git a/docs/pages/developer-info/02.04.NewReleaseGuidelines.md
b/docs/pages/developer-info/02.04.NewReleaseGuidelines.md
new file mode 100644
index 0000000000..23c9d7ad5b
--- /dev/null
+++ b/docs/pages/developer-info/02.04.NewReleaseGuidelines.md
@@ -0,0 +1,312 @@
+---
+id: 02.04.NewReleaseGuidelines
+title: New release guidelines
+---
+
+This document provides a mixture of information, advice and examples of best
practices for releasing versions of Apache Juneau.
+
+The instructions provided here are consistent with, but not a replacement for
the **ASF Release Guidelines**.
+
+## 1 - Intro
+
+The Apache Juneau project uses the Nexus installation at the Apache Software
Foundation to stage Maven artifacts before the release and later publish them;
the POM in the root project contains all the necessary configuration. This
guide covers deploying to Nexus using Maven. For alternatives see the **ASF
wide documentation**. If this is the first time you are publishing to the ASF's
Nexus instance you'll need to **prepare your development environment**.
+
+Juneau components are expected to use Maven to build the jar/zip files. The
version of Maven used is assumed to be Maven 3 throughout. At a minimum, Juneau
releases **must** include full source distributions packaged in zip archives.
+
+This document assumes that the release is being prepared on a linux/unix
system, and that steps are being executed from the command-line. The principles
are the same, however, for a release prepared on other operating systems.
+
+These instructions assume you are taking on the role of release manager. This
implies you are at least one of the developers.
+
+<div class="info">
+
+**Note:** If you're using macOS, you'll want to install **wget**.
+
+**Note:** Yellow blocks are code blocks that can be executed as-is UNLESS you
see red text indicating values that need to be replaced.
+
+</div>
+
+## 2 - Preparation
+
+### 2.1 - Determine version number
+
+Consult the **versioning guidelines** and check that the current level of
compatibility is suitable for the proposed version number.
+
+### 2.2 - Propose email to dev@juneau
+
+Send an email to the **dev@juneau** mailing list informing the community you
plan on creating a new release. The message can be simple:
+
+```text
+To: [email protected]
+Subject: [PROPOSE] Release Apache Juneau 9.x.x RCx
+
+Hi everyone,
+
+I'm going to create a new release of Juneau because <state short reason why>.
+
+If I do not hear any objections within the next 24 hours, I'm going to go
ahead and start the process.
+
+The release will be called 9.x.x-RCx. The next release will be set to 7.x.y.
+```
+
+## 3 - Creating a release candidate
+
+### 3.1 - Create new release in JIRA
+
+Log into **JIRA** and create the new version (e.g. **7.0.1**). Change the
**Release date** on the current version to today.
+
+Generate the release notes for the current release as plain text. Click on the
current release and click the **Release Notes** button. Click the **Configure
Release Notes** button to select plain text. Copy the contents of this file to
the root **RELEASE-NOTES.txt** file and commit the change.
+
+### 3.2 - Update Release Notes section in overview.html
+
+We maintain externally-consumable new-and-noteworthy information for all our
releases in our javadocs.
+
+Using the release notes above as a guide, create release notes in the
**Release Notes** section of the **/docs/src/javadoc/overview.html** document.
Use the previous release as a guideline.
+
+### 3.3 - Update LICENSE and NOTICE files
+
+Check the contents of the **LICENSE** and **NOTICE** files in the root
directory.
+
+Ensure that the LICENSE files contain the latest information specified in the
**Apache Licenses** page.
+
+Check that the years in the copyright statement in the NOTICE file are
correct. The notice file should contain the following:
+
+```
+Apache Juneau
+Copyright 2016-{this-year} The Apache Software Foundation
+
+This product includes software developed at
+The Apache Software Foundation (http://www.apache.org/).
+```
+
+Developer documentation on how to apply the Apache License can be found in
**Applying the Apache License, Version 2.0** and **ASF Source Header and
Copyright Notice Policy.**
+
+### 3.4 - Run release script
+
+If you've already successfully performed a release, you can run the automated
Python script to perform the release. If you do not wish to use the script,
skip to section **3.5 - Prepare your build machine**.
+
+The release script is located at:
+
+* **scripts/release.py**
+
+Run the script from the juneau root directory. It will walk you through the
entire process.
+
+If successful, you can skip to section **4 - Voting.**
+
+### 3.5 - Prepare your build machine
+
+Run the following commands to set environment variables that will be used
throughout this page.
+Set **X_RELEASE** to the version you plan on release and **X_STAGING** to the
staging directory to use on your machine:
+
+```bash
+export X_VERSION=7.0.0
+export X_NEXT_VERSION=7.0.1-SNAPSHOT
+export X_RELEASE=juneau-7.0.0-RC1
+export X_STAGING=~/tmp/dist-release-juneau
+export X_USERNAME=<your apache username>
+export [email protected]
+```
+
+Run the following commands:
+
+```bash
+cd ~/.m2
+mv repository repository-old
+rm -rf repository-old &
+rm -rf $X_STAGING
+mkdir -p $X_STAGING
+mkdir $X_STAGING/git
+cd $X_STAGING/git
+git clone https://gitbox.apache.org/repos/asf/juneau.git
+git clone https://gitbox.apache.org/repos/asf/juneau-website.git
+cd juneau
+git config user.name $X_USERNAME
+git config user.email $X_EMAIL
+```
+
+Make sure you're running at least Java 17 and Maven 3:
+
+```bash
+java -version
+mvn -version
+```
+
+<div class="info">
+
+**Note:** If you're not running Java 17+, you'll get errors when trying to
generate the Javadocs.
+
+</div>
+
+### 3.6 - Update KEYS file if necessary
+
+Check that the **KEYS** file contains your correct key and fingerprint. If
not, then follow the instructions in this section.
+
+You need to have **gpg** and preferably a **GPG Agent** installed on the
machine you will build the release on. This needs to be configured with your
**GPG release key**.
+
+Find your PGP fingerprint:
+
+```bash
+gpg --fingerprint $X_EMAIL
+```
+
+You should see something like the following:
+
+```
+jamesbognar-ltm:dist-release-juneau james.bognar$ gpg --fingerprint
[email protected]
+pub rsa2048 2016-09-21 [SC]
+ 59E1 A375 4EF6 0E6F CE42 ABFE 3629 2BD2 BA7D 3A86
+uid [ultimate] James Bognar <[email protected]>
+sub rsa2048 2016-09-21 [E]
+```
+
+Your key should list your **@apache.org email address**. Also check your key
has **not expired** - you can use **gpg --edit-key** and **gpg --send-key** to
update.
+
+The public key must first be **uploaded to a public keyserver**. To do this,
take the _last_ 8 digits from the hex **fingerprint** and upload them with the
following command:
+
+```bash
+gpg --keyserver pgp.mit.edu --send-key BA7D3A86
+```
+
+Edit your details on **id.apache.org** to provide your **OpenPGP Public Key
Primary Fingerprint**, e.g.:
+
+```
+59E1 A375 4EF6 0E6F CE42 ABFE 3629 2BD2 BA7D 3A86
+```
+
+## 4 - Voting
+
+Once the release candidate has been created and uploaded, a vote must be held
on the **dev@juneau** mailing list. The vote must be open for at least 72 hours
and requires a minimum of 3 binding +1 votes from PMC members.
+
+The release script will generate a vote email for you. Send this email to
**[email protected]**.
+
+## 5 - Verifying the release
+
+Before voting, it's important to verify the release artifacts. The release
script includes automated verification steps, but you should also manually
verify:
+
+1. Download the source distribution
+2. Verify the PGP signatures
+3. Verify the SHA-512 checksums
+4. Build the project from source
+5. Run the test suite
+
+## 6 - After a successful vote
+
+If the vote passes and it's been agreed on **dev@juneau**, then:
+
+* Tag the release in Git
+* Promote the release candidate to a release
+* Update download page
+* Send announcement email
+
+### 6.1 - Tag the release in Git
+
+Copy the final tag:
+
+```bash
+git tag juneau-7.0.0 juneau-7.0.0-RC1
+git push --tags
+```
+
+### 6.2 - Moving to release area
+
+Use full URL **svn mv** to move the accepted release candidate to the release
folder structure on **dist.apache.org**, e.g.
**https://dist.apache.org/repos/dist/release/juneau/source/** but remember to
remove the -RC1 part from the folder name.
+
+```bash
+svn mv https://dist.apache.org/repos/dist/dev/juneau/source/juneau-7.0.0-RC1 \
+ https://dist.apache.org/repos/dist/release/juneau/source/juneau-7.0.0 \
+ -m "Releasing apache juneau-7.0.0"
+svn mv https://dist.apache.org/repos/dist/dev/juneau/binaries/juneau-7.0.0-RC1
\
+ https://dist.apache.org/repos/dist/release/juneau/binaries/juneau-7.0.0 \
+ -m "Releasing apache juneau-7.0.0"
+```
+
+### 6.3 - Releasing Maven repository
+
+Tick the correct **staging repository** (perhaps do a quick check of an SHA1
sum against the vote email), then click **Release**. It should then propagate
to **Apache's release Maven repository** and eventually mirrored to **Maven
Central**.
+
+### 6.4 - Update download page
+
+Wait 24 hours for the download mirrors to pick up the new release from
**dist.apache.org**, otherwise eager users (or users who just happened to want
to download that day) may get **404 Not Found** errors.
+
+Update (or make) the corresponding pages under **downloads.html** including
the correct version number for the Maven dependencies and the release dates.
+
+Download links should be using the mirror redirector
**https://www.apache.org/dyn/closer.cgi**, e.g.
**https://www.apache.org/dyn/closer.cgi/juneau/source/juneau-7.0.0/juneau-7.0.0-source-release.zip**
+
+The **asc/md5/sha1** links should go directly to
**https://www.apache.org/dist/** - e.g.
**https://www.apache.org/dist/juneau/source/juneau-7.0.0/juneau-7.0.0-source-release.zip.asc**
(important bit: **https**)
+
+Remove the staged release from **Nexus**.
+
+### 6.5 - Removing old versions
+
+**After** the download page has been published, the download mirrors have
synchronized and the new version is live you must remove the old versions from
**https://dist.apache.org/repos/dist/release/juneau/source/**
+
+```bash
+svn rm https://dist.apache.org/repos/dist/release/juneau/source/juneau-6.9.9/
+svn rm https://dist.apache.org/repos/dist/release/juneau/binaries/juneau-6.9.9/
+```
+
+Older versions are archived under
**http://archive.apache.org/dist/juneau/source/** but won't appear on the
download mirrors.
+
+### 6.6 - Create announcements
+
+Announce the availability of the new release.
+
+Please **remember to give a brief description of your component**.
+
+```text
+To: [email protected], [email protected]
+Subject: [ANNOUNCEMENT] Apache Juneau 9.x.x Released
+
+Hello all,
+
+The Apache Juneau team is proud to announce the release of Juneau 9.x.x.
+
+Apache Juneau is...
+- A toolkit for marshalling POJOs to a variety of content types using a common
framework.
+- A REST server API for creating Swagger-based self-documenting REST
interfaces using POJOs.
+- A REST client API for interacting with REST interfaces using POJOs.
+- A remote proxy API built on top of REST.
+- A sophisticated INI config file API.
+- A REST microservice API that combines all the features above for creating
lightweight standalone REST interfaces that start up in milliseconds.
+
+<A description of latest updates>
+
+The release is available here (don't forget to verify the signatures):
+xxx
+
+Release notes can be found here:
+xxx
+
+We welcome your help and feedback. For more information on the project and how
to get involved, visit the project website at
+http://juneau.apache.org/
+```
+
+Send this mail from your @apache.org account. Please spell check the document!
+
+Wait to send the release announcement until you have verified that:
+
+1. The release artifacts are available on the mirrors.
+2. The component website including the updated download page has been updated
on the public site **http://juneau.apache.org/proper/juneau**.
+3. If the component publishes maven artifacts, these artifacts have been
replicated to the central maven repo at **repo.maven.apache.org**.
+ (Clear your local repo of the release artifacts and either activate the
clirr report with the updated version info or update a local project with a
dependency to the new release version to get maven to try to download the
release artifacts. Or just access repo using a web browser.)
+
+## 7 - Updating Website
+
+The website contents are located in GitHub:
https://github.com/apache/juneau-website
+
+Checkout the contents of this repo to the same git folder of the juneau
project (e.g. /juneau and /juneau-website should be in the same parent git
folder).
+
+Generate the Javadocs for the new version by doing the following:
+
+1. Make sure the version is set correctly in the root **pom.xml** (should
already be done at this point).
+2. Run the following command in the **/juneau** folder to generate the
Javadocs and add them to the website: **scripts/build-docs.py**
+3. Verify that a new folder is created at **docs/static/javadocs/x.x.x**
containing the newly-generated javadocs.
+
+Update the downloads page and regenerate templates.
+
+1. Update the **juneau-website/templates/downloads.html** to reflect the
newest release.
+ 1. Change **Current release** section.
+ 2. Add new entry to **Older releases** section.
+2. Update the settings in **juneau-website.properties** to reflect new
versions.
+3. Run the **juneau-website.sh** script to regenerate the templated files.
+
+After completion, commit and push the changes to the master branch. The
website should be updated immediately.
diff --git a/docs/pages/developer-info/02.05.VersioningGuidelines.md
b/docs/pages/developer-info/02.05.VersioningGuidelines.md
new file mode 100644
index 0000000000..34b671dce4
--- /dev/null
+++ b/docs/pages/developer-info/02.05.VersioningGuidelines.md
@@ -0,0 +1,205 @@
+---
+id: 02.05.VersioningGuidelines
+title: Versioning guidelines
+---
+
+This document provides:
+
+* A set of guidelines intended to help the Apache Juneau team balance the need
to provide a stable interface to clients with the growth and evolution of
components over time.
+* A language for describing the changes to a component and the types of
incompatibilities such changes may create.
+* A protocol for communicating those changes and incompatibilities to users
and developers.
+
+## 1 - Quick guidelines
+
+In a nutshell, Juneau release numbers are usually of the form
**major.minor.point**.
+
+* **Major releases** introduce breaking changes.
+* **Minor releases** introduce new significant features.
+* **Point releases** introduce new minor features and bug fixes.
+
+## 2 - Interface types
+
+We identify two distinct categories of APIs within a component: _external_,
_internal_.
+
+### 2.1 - The external interface
+
+Composed of the public-facing classes, methods and fields that are likely to
be consumed by external developers. In general, these consist of all public
classes/methods/fields, and protected methods/fields on classes meant to be
extended.
+
+We try to avoid or at least acknowledge changes to the external interface.
+
+### 2.2 - The internal interface
+
+Composed of classes, methods, and fields not meant for external consumption.
+
+We mark interfaces as internal in the following ways:
+
+* Making them private or package-protected.
+* By placing them in packages containing the name "**internal**". (e.g.
"**org.apache.juneau.internal**").
+* By placing them in packages containing the name "**proto**". These identify
new code not yet ready for consumption.
+* By specifying in the Javadoc that it's an internal interface not meant for
consumption.
+
+Developers have free reign to make changes to the internal interface. These
interfaces should not be included in the Javadocs.
+
+## 3 - Types of change
+
+We can categorize the changes to a component according to the degree to which
these changes are compatible with previous releases of the component. We define
three such categories: _fully-compatible_, _interface-compatible_, and
_external-interface-compatible_.
+
+### 3.1 - Fully-compatible changes
+
+Release _B_ is said to be _fully-compatible_ with Release _A_ if _B_ can
simply replace _A_ in (nearly) all circumstances and deployments without
changing the client code or configuration, and without changing the semantics
of any public or protected member.
+
+**Examples of fully-compatible changes include:**
+
+* adding a non-abstract method to a class
+* adding a class or interface to a component
+* changing a member from private to protected
+* changing a private attribute to a private method
+* changing an implementation such that a given external library is no longer
needed by the component
+* changing a method or class from final to non-final
+* deprecating, but not otherwise changing, a class, interface or member
+* changing a component in order to fix a defect (a deviation from the
documented or reasonably expected behavior), assuming no other
incompatibilities are introduced
+
+**Examples of changes which are not fully-compatible include:**
+
+* a release that no longer supports the same set of JREs, or that requires new
libraries to be added to the classpath
+* changing a public or protected method signature
+* changing the default value of an attribute in a behaviour-impacting way
+* removing a class, interface, method or attribute from either the internal or
external interface of the component
+
+Note that not every non-fully-compatible change will cause compilation or
readily apparent run-time problems.
+
+Generally speaking, a fully-compatible change will at most change the private
interface of a component, or simply add classes, methods and attributes whose
use is optional to both internal and external interface clients.
+
+### 3.2 - Interface-compatible changes
+
+Release _B_ is said to be "interface-compatible" with Release _A_ if (nearly)
all clients that can be compiled with _A_ in the classpath can also be compiled
with _B_ in the classpath, without changing the semantics of any public or
protected member. A configuration or classpath change may be required.
+
+**Examples of interface-compatible changes include:**
+
+* all fully-compatible changes
+* changing a component such that it now depends upon an additional external
library or configuration file
+
+**Examples of changes which are not interface-compatible include:**
+
+* changing a public or protected method signature
+* changing the default value of an attribute in a behaviour changing way
+* removing a class, interface, method or attribute from either the internal or
external interface of the component
+
+Generally speaking, an interface-compatible change will at most change the
private interface of a component, or simply add classes, methods and attributes
whose use is optional to both internal and external interface clients.
+
+### 3.3 - External-interface-compatible changes
+
+Release _B_ is said to be "external-interface-compatible" with Release _A_ if
(nearly) all clients that depend only on the external interface of a component
and that can be compiled with _A_ in the classpath can also be compiled with
_B_ in the classpath, without changing the semantics of any member in the
_external_ interface. A configuration or classpath change may be required.
+
+**Examples of external-interface-compatible changes include:**
+
+* all interface-compatible changes
+* removing a class, interface, method or attribute from the internal interface
of the component
+* a change to the internal or private interface of a component that requires a
change in configuration settings or in the external libraries required to use
the component
+* changes to the internal or private interface of a component without
impacting the external interface
+
+**Examples of changes which are not external-interface-compatible include:**
+
+* changing the method signature of any method that is part of the external
interface of the component
+* changing the default value of any attribute that is part of the external
interface of the component in a behaviour changing way
+* removing a class, interface, method or attribute from external interface of
the component
+
+Generally speaking, external-interface-compatible changes correspond to
changes to at most the internal interface of the component or the addition of
optional classes, interfaces or members to the external interface.
+
+## 4 - Release types
+
+We identify five types of releases: "**Major**", "**Minor**", "**Point**",
"**Beta**" and "**Milestone**".
+
+Developers are encouraged to "upgrade" a release to a stronger type whenever
the nature or scope of the change warrants it.
+
+### 4.1 - Major releases
+
+Major releases signify significant changes to a component. Developers _may_
perform a major release if there have been substantial improvements to the
component. Developers _must_ perform a major release whenever the new release
is not at least interface-compatible with the previous release.
+
+### 4.2 - Minor releases
+
+Minor releases signify enhancements to a component that do not necessitate a
major release. Developers _may_ perform a minor release if the release is at
least external-interface-compatible with the previous release.
+
+In other words, whenever a client depends upon at most the external interface
of a component with a given minor release, it will work with all subsequent
minor releases within that major release.
+
+### 4.3 - Point releases
+
+A point release typically involves simple bug fixes or optimizations and minor
new features. Developers _may_ perform a point release if the release is at
least interface-compatible with the previous release.
+
+In other words, whenever a client depends upon a component with a given point
release, it will work with all subsequent point releases within that minor
release.
+
+### 4.4 - Beta releases
+
+Developers may, at their option, perform a beta preview of any major, minor or
point release. Beta releases may be performed for a variety of purposes such as:
+
+* Showcasing new, untested features
+* Providing early corrections of critical bugs
+* Generating a stable version before large-scale changes
+
+While every effort should be made to ensure the quality of released code,
"beta" releases are essentially provided as-is with no guarantees of stability
or maintenance.
+
+### 4.5 - Milestone releases
+
+Developers may, at their option, offer a milestone preview of any major
release. A milestone release is appropriate when part of the overall component
is fully functioning and the team wants to make it more widely available for
testing. Those features implemented and those remaining to be implemented
should be clearly defined and documented.
+
+While every effort should be made to ensure the quality of released code,
"milestone" releases are essentially provided as-is with no guarantees of
stability or maintenance.
+
+## 5 - Release numbers
+
+### 5.1 - Dissecting the release number
+
+A release number is comprised of 3 components: the major release number, the
minor release number, and an optional point release number. Here is a sample
release number:
+
+**2.0.4**
+
+and it can be broken into three parts:
+
+* **major release**: 2
+* **minor release**: 0
+* **point release**: 4
+
+The next release of this component would increment the appropriate part of the
release number, depending on the type of release (major, minor, or point). For
example, a subsequent minor release would be version 2.1, or a subsequent major
release would be 3.0.
+
+Note that release numbers are composed of three **integers**, not three
_digits_. Hence if the current release is 3.9.4, the next minor release is
3.10.0.
+
+### 5.2 - Beta release numbers
+
+Beta releases are denoted by adding "B" followed by the beta version number
after the release number. For example, if the current release version is 2.0.4,
and a developer wished to preview the next major release, the release would be
labeled 3.0-B1.
+
+### 5.3 - Milestone release numbers
+
+Milestone releases are denoted by adding "M" followed by the milestone version
number after the release number. For example, if the current release version is
2.0.4, and a developer wished to preview the next major release, the release
would be labeled 3.0-M1.
+
+## 6 - Development states
+
+We identify four possible states: "**in development**", "**beta**",
"**released**", and "**unsupported**".
+
+### 6.1 - In development state
+
+When a component is "in development", it is new and still relatively unstable.
Typically components in this state do not have any binary releases available
beyond the nightly builds. Users should be made aware that this component may
change its functionality or interface before a stable release is achieved. A
"milestone" release may be made while the component is still "in development"
to make the features currently implemented more widely available for testing in
a more stable test version.
+
+### 6.2 - Beta state
+
+When a component has made significant progress toward release-quality code,
the committers may vote to perform a "beta" release. At this point, the
component state will change from "in development" to "beta". The component will
remain in this state until it is ready for its first major release.
+
+Note that developers may skip vote to skip the "beta" state and go directly to
"released", if the component is sufficiently stable.
+
+### 6.3 - Released state
+
+When a new component is finally production-quality, the developers may vote to
perform the first major release. At this point, the component status will be
changed from "beta" to "released". In the future this component will always be
considered to be in the "released" state, even when new releases are initiated.
The only exception is in the case of "unsupported" components.
+
+### 6.4 - Unsupported state
+
+Under rare circumstances, committers may vote to make a component
"unsupported", if there are no resources to maintain the library or if it has
been completely supplanted by another component. Only "released" components may
become "unsupported"; components in other states will simply be terminated
after a brief warning period.
+
+## 7 - Comments
+
+Using this approach it is possible to very precisely and concisely define the
dependencies between a component and its clients.
+
+For example, suppose that the application Foo depends (only) upon features of
the juneau-core component that are part of the external interface in release
2.3.0. Then the maintainers of Foo can state with a high degree of certainty
that Foo will work with any 2.x release of juneau-core (x >= 3).
+
+Similarly, suppose the application Bar depends upon features of juneau-core
that were part of the internal interface of release 2.3.0. Then the maintainers
of Bar can state with a high degree of certainty that Bar will work with any
2.3.x release of juneau-core. Only once 2.4 (or 3.0) is released will Bar's
developers have to re-evaluate.
+
+## 8 - End Notes
+
+* We say "nearly" here since there are rare or unusual circumstances in which
changes that are usually "safe" may cause problems for a small number of users.
For example, adding a new method to a component class shouldn't in general
cause problems for any clients. But it may cause problems for some clients
who've extended that class and already added a method with the same signature
in their subclass.
diff --git a/docs/pages/developer-info/02.06.CodeFormattingStylesheet.md
b/docs/pages/developer-info/02.06.CodeFormattingStylesheet.md
new file mode 100644
index 0000000000..dd95b12853
--- /dev/null
+++ b/docs/pages/developer-info/02.06.CodeFormattingStylesheet.md
@@ -0,0 +1,258 @@
+---
+id: 02.06.CodeFormattingStylesheet
+title: Using the code formatting stylesheet
+---
+
+This page contains comprehensive information about using the `javadoc.css`
stylesheet for Apache Juneau JavaDoc documentation.
+
+## Overview
+
+The `javadoc.css` file is located at `docs/src/javadoc/javadoc.css` and
provides comprehensive styling for all generated JavaDoc HTML pages. It
includes both standard JavaDoc styles and extensive Juneau-specific
customizations for enhanced documentation presentation.
+
+## Configuration
+
+The stylesheet is automatically configured in the root `pom.xml` file for the
Maven Javadoc plugin:
+
+```xml
+<stylesheetfile>${maven.multiModuleProjectDirectory}/docs/src/javadoc/javadoc.css</stylesheetfile>
+```
+
+This ensures that all generated JavaDoc HTML files use the custom stylesheet
when running:
+- `mvn javadoc:javadoc`
+- `mvn site`
+
+## Standard JavaDoc Styles
+
+The stylesheet includes comprehensive styling for standard JavaDoc elements:
+
+### Typography
+- **Fonts**: Uses DejaVu Sans for body text, DejaVu Sans Mono for code
+- **Base font size**: 14px
+- **Headings**: H1 (20px) through H6 (13px) with appropriate sizing
+
+### Navigation
+- **Top navigation bar**: Blue background (#4D7A97) with white text
+- **Sub-navigation**: Light gray background (#dee3e9)
+- **Active page indicator**: Orange highlight (#F8981D)
+- **Responsive design**: Mobile-friendly navigation with collapsible menu
+
+### Tables
+- **Summary tables**: Alternating row colors (white and #EEEEEF)
+- **Table tabs**: Interactive tabs for switching between different views
+- **Responsive columns**: Grid-based layouts that adapt to screen size
+
+### Links
+- **Standard links**: Blue (#4A6782) with orange hover (#bb7a2a)
+- **External links**: Automatically marked with an external link icon
+- **No underlines**: Clean link styling without default underlines
+
+## Juneau-Specific Custom Styles
+
+### Code Highlighting Tags
+
+The stylesheet provides extensive inline code highlighting tags for syntax
coloring:
+
+#### Java Code Tags
+- `<jc>` - Java comment (green)
+- `<jd>` - Javadoc comment (#3f5fbf)
+- `<jt>` - Javadoc tag (#7f9fbf, bold)
+- `<jk>` - Java keyword (#7f0055, bold)
+- `<js>` - Java string (#00B)
+- `<jf>` - Java field (DarkBlue)
+- `<jsf>` - Java static field (DarkBlue, italic)
+- `<jsm>` - Java static method (italic)
+- `<ja>` - Java annotation (grey)
+- `<jp>` - Java parameter (#654040)
+- `<jv>` - Java local variable (#654040)
+
+#### XML Code Tags
+- `<xt>` - XML tag (DarkCyan)
+- `<xa>` - XML attribute (purple)
+- `<xc>` - XML comment (mediumblue)
+- `<xs>` - XML string (#00B, italic)
+- `<xv>` - XML value (black)
+
+#### Other Code Tags
+- `<mk>` - Manifest file key (DarkRed, bold)
+- `<mv>` - Manifest file value (DarkBlue)
+- `<cc>` - Config file comment (green)
+- `<cs>` - Config file section (DarkRed, bold)
+- `<ck>` - Config file key (DarkRed)
+- `<cv>` - Config file value (DarkBlue)
+
+#### Code Block Classes
+- `.bcode`, `.bjava`, `.bjson`, `.bxml`, `.bini`, `.buon`, `.burlenc`,
`.bconsole`, `.bschema` - Bordered code blocks with left border and background
+- `.code` - Unbordered code block
+
+**Example:**
+```html
+<p class='bjava'>
+ <jk>public static void</jk> myMethod(<jk>int</jk> <jv>foo</jv>, String
<jv>bar</jv>) {
+ System.<jsm>out</jsm>.println(<js>"Hello world!"</js>);
+ }
+</p>
+```
+
+### Special Classes
+
+#### Topic Headers
+- `h2.topic`, `h3.topic`, `h4.topic`, `h5.topic` - Styled topic headers with
borders and background gradients
+- Automatically includes a decorative icon
+
+#### Tables
+- `table.styled` - Table with alternating row colors and styled borders
+- `table.unstyled` - Plain table with borders but no row coloring
+- `table.borderless` - Table without borders
+- `table.plain` - Table with plain borders
+- `table.striped` - Table with striped rows
+
+#### Lists
+- `ul.toc`, `ol.toc` - Table of contents with styled background
+- `ul.spaced-list`, `ol.spaced-list` - Lists with extra spacing between items
+- `ul.javatree`, `ol.javatree` - Java class hierarchy lists with special
markers
+- `ul.seealso` - "See Also" lists with automatic label
+- `ul.notes` - Notes lists with automatic label
+- `ul.values` - Values lists with automatic label
+- `ul.format` - Format lists with automatic label
+
+#### Alert Blocks
+- `div.info` - Information block (blue border, light blue background)
+- `div.warn` - Warning block (orange border, light orange background)
+- `div.severe` - Severe warning block (red border, light red background)
+- `p.severe`, `p.warn`, `p.info`, `p.todo` - Paragraph-level alerts
+
+#### Special Elements
+- `.bordered` - Adds border around images or blocks
+- `.fixedWidth` - Forces block to be 800px wide
+- `a.doclink` - Styled link to documentation with dotted underline
+- `<l>` - Literal text tag
+- `<review>` - Review marker block (yellow background)
+- `<reviewed>` - Reviewed marker block (green background)
+
+#### Width Utilities
+- `.w400` - 400px width
+- `.w500` - 500px width
+- `.w800` - 800px width
+- `.w900` - 900px width
+- `.w1000` - 1000px width
+
+### Java Hierarchy Markers
+
+Special list item classes for displaying Java class hierarchies:
+- `li.jc` - Java class (green circle)
+- `li.jac` - Java abstract class (yellow circle)
+- `li.jic` - Java interface (purple diamond)
+- `li.ja` - Java annotation (cyan circle)
+- `li.je` - Java enum (brown circle)
+- `li.jf` - Java field (green circle)
+- `li.jm` - Java method (green circle)
+- `li.jp` - Java package (orange circle)
+
+## Usage Examples
+
+### Code Blocks with Syntax Highlighting
+
+```html
+/**
+ * Example method with highlighted code.
+ *
+ * <p class='bjava'>
+ * <jk>public</jk> <jk>void</jk> processData(<jk>String</jk>
<jv>input</jv>) {
+ * <jc>// Process the input</jc>
+ * System.<jsm>out</jsm>.println(<js>"Processing: "</js> +
<jv>input</jv>);
+ * }
+ * </p>
+ */
+```
+
+### Styled Tables
+
+```html
+/**
+ * Configuration options:
+ *
+ * <table class='styled'>
+ * <tr><th>Option</th><th>Description</th></tr>
+ * <tr><td>option1</td><td>First option</td></tr>
+ * <tr><td>option2</td><td>Second option</td></tr>
+ * </table>
+ */
+```
+
+### Alert Blocks
+
+```html
+/**
+ * <div class='warn'>
+ * <b>Warning:</b> This method may throw an exception.
+ * </div>
+ *
+ * <div class='info'>
+ * <b>Note:</b> This feature was added in version 9.0.
+ * </div>
+ */
+```
+
+### Topic Headers
+
+```html
+/**
+ * <h3 class='topic'>Advanced Usage</h3>
+ *
+ * This section covers advanced usage patterns.
+ */
+```
+
+### Java Hierarchy
+
+```html
+/**
+ * Class hierarchy:
+ * <ul class='javatree'>
+ * <li class='jp'>com.example</li>
+ * <li class='jc'>BaseClass</li>
+ * <li class='jc'>MyClass extends BaseClass</li>
+ * </ul>
+ */
+```
+
+## Customization
+
+To customize the JavaDoc appearance:
+
+1. Edit the `docs/src/javadoc/javadoc.css` file
+2. Regenerate the JavaDoc documentation:
+ ```bash
+ mvn javadoc:javadoc
+ ```
+ or
+ ```bash
+ mvn site
+ ```
+
+Changes will be reflected in all generated JavaDoc pages.
+
+## Responsive Design
+
+The stylesheet includes comprehensive responsive design support:
+- Mobile navigation with collapsible menu
+- Responsive table layouts that adapt to screen size
+- Flexible grid systems for multi-column layouts
+- Optimized typography for different screen sizes
+
+## Color Scheme
+
+The stylesheet uses a consistent color palette:
+- **Primary blue**: #4D7A97 (navigation, links)
+- **Orange accent**: #F8981D (active states, highlights)
+- **Hover orange**: #bb7a2a (link hovers)
+- **Light gray**: #dee3e9 (backgrounds, borders)
+- **Dark text**: #353833 (body text)
+- **Dark blue**: #2c4557 (headings)
+
+## Additional Resources
+
+For more information, see:
+- [Oracle JavaDoc
Documentation](https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html)
+- [Maven Javadoc
Plugin](https://maven.apache.org/plugins/maven-javadoc-plugin/)
+
diff --git a/docs/pages/developer-info/02.08.DevelopmentWishList.md
b/docs/pages/developer-info/02.08.DevelopmentWishList.md
new file mode 100644
index 0000000000..4f332cf0d6
--- /dev/null
+++ b/docs/pages/developer-info/02.08.DevelopmentWishList.md
@@ -0,0 +1,84 @@
+---
+id: 02.08.DevelopmentWishList
+title: Development wish list
+---
+
+This page contains an informal list of possible future feature work in Juneau.
Please feel free to add to this list with ideas and put (+1 userid) next to
items you're interested in.
+
+## Overall
+
+1. Investigate OpenAPI 3 support. The Swagger API is currently at Swagger 2.0.
+2. Proofread documentation. It would be good to clean up areas that are
confusing.
+
+## juneau-marshall
+
+1. YAML support.
+ This is kind of big though. Essentially cloning the JSON serializers and
parsers and converting them to use YAML syntax.
+2. Other possible languages: BSON, Protobuf, Amazon Ion
+3. @JsonSchema validation support for all serializers and parsers.
+ This is also kind of big. Basically adding SERIALIZER_validating and
PARSER_validating settings (disabled by default) that would allow automatic
schema validation of input and output just like we do for the OpenAPI
serializer and parser.
+4. FreeMarker integration.
+5. Test @Header("\*") using maps/beans and related annotations.
+6. Simplify @Body annotation by merging @Schema into it.
+7. Test RestRequest.getRequest() and @Request as an annotation.
+8. Document RestRequest.getRequest().
+9. Find references to JsonSerializer.Simple
+
+## juneau-examples-core
+
+1. Creating generic JSON objects
+2. Defining XML namespaces
+
+## juneau-rest-examples
+
+1. Packaging as WAR files (documentation or article?)
+2. Customizing OPTIONS pages
+3. Rendering form entry pages
+4. Using the ZipFileList response handler
+5. Implementing console-output pages in HTML
+6. Using configuration files
+7. Making a bean traversable
+8. Using the Queryable converter
+9. Sending raw output
+10. Retrieving raw input
+11. Accessing request query parameters
+12. Accessing request path variables
+13. Accessing request content
+14. Accessing request header values
+15. Accessing the path pattern remainder
+16. Creating ResourceGroup pages
+17. Using matchers to define multiple Java methods to the same path pattern
+18. Using the Remoteable API
+19. Sending a redirect request
+20. Changing the stylesheet used by the HTML serializer
+21. Using the Introspector API to invoke methods on Java objects through REST
calls
+22. Customizing serializers and parsers at the method level
+23. Accessing config file values
+24. Accessing request query parameters on URL-Encoded FORM posts without
triggering HTML body to be read
+25. Accessing localized messages
+26. Defining your own response handlers
+27. Guarding access to a servlet or method
+28. Handling servlet initialization errors
+29. Handling exceptions that occur during response processing
+30. Customizing logging
+31. Creating an ATOM feed
+32. Creating a REST API against a file system
+33. Creating a Docker REST API
+34. Creating a REST API for storing and retrieving images
+35. Creating a REST API for echoing requests
+36. Creating a Tumblr REST API
+37. Creating a Cloudant REST API
+38. Using onPreCall() to intercept requests before processing
+39. Using onPostCall() to intercept requests after processing
+40. Creating child resources programmatically
+41. Defining default request headers
+42. Defining default response headers
+43. Defining your own var-resolver variables
+44. Serving up static files inside the /htdocs embedded package
+45. Defining MIME types of files in the /htdocs folder using the
createMimitypesFileTypeMap() method
+46. Defining the title and description of a servlet programmatically using
getDescription() and getTitle().
+47. Setting properties programmatically using RestServlet.setProperty()
+48. Setting and saving config file properties
+49. Defining your own abstract subclass of RestServlet or RestServletDefault
+50. Adding GZip support
+51. Accessing environment variables in config files
diff --git a/docs/pages/developer-info/03.00.CurrentMembers.md
b/docs/pages/developer-info/03.00.CurrentMembers.md
new file mode 100644
index 0000000000..76f88c1934
--- /dev/null
+++ b/docs/pages/developer-info/03.00.CurrentMembers.md
@@ -0,0 +1,27 @@
+---
+id: 03.00.CurrentMembers
+title: Current Members
+---
+
+## Apache Juneau Project Management Committee (PMC) and Committers
+
+The following is a list of current PMC members and committers for the Apache
Juneau project.
+
+| Name | Role | User ID |
+|------|------|---------|
+| John D. Ament | PMC / Committer | johnadament |
+| Steve Blackmon | PMC / Committer | sblackmon |
+| James Bognar | PMC Chair / Committer | jamesbognar |
+| David M Goddard | PMC / Committer | dmg |
+| Peter Haumer | PMC / Committer | phaumer |
+| Raphi D Lee | PMC / Committer | yidonguk |
+| Ayeshmantha Perera | PMC / Committer | akayeshmantha |
+| Craig L Russell | PMC / Committer | clr |
+| Stian Soiland-Reyes | PMC / Committer | stain |
+| Shalitha Suranga | PMC / Committer | shalithasuranga |
+| Jochen Wiedmann | PMC / Committer | jochen |
+| Marcelo Vieira | PMC / Committer | marcelosouzav |
+| Gary Gregory | PMC / Committer | ggregory |
+
+For the most up-to-date information, please refer to the [GitHub
Wiki](https://github.com/apache/juneau/wiki).
+
diff --git a/docs/pages/developer-info/04.00.BlogIndex.md
b/docs/pages/developer-info/04.00.BlogIndex.md
new file mode 100644
index 0000000000..05c717a7e8
--- /dev/null
+++ b/docs/pages/developer-info/04.00.BlogIndex.md
@@ -0,0 +1,32 @@
+---
+id: 04.00.BlogIndex
+title: Blog Posts
+---
+
+## Blog Posts
+
+This page contains blog posts from the Apache Juneau project.
+
+### 2018
+
+- [JUnit Test Results](/docs/developer-info/04.01.JUnitTestResults) (May 11,
2018)
+- [REST Media-Type-less POJO
requests](/docs/developer-info/04.02.RESTMediaTypeLessPOJORequests) (May 15,
2018)
+- [Juneau 7.2.0 documentation
preview](/docs/developer-info/04.03.Juneau720DocumentationPreview) (July 25,
2018)
+- [Support for auto-validation in Swagger
annotations](/docs/developer-info/04.04.SupportForAutoValidationInSwaggerAnnotations)
(July 25, 2018)
+- [Documentation reorg](/docs/developer-info/04.05.DocumentationReorg) (July
25, 2018)
+- [Behavior change on default @RestMethod(path)
value](/docs/developer-info/04.06.BehaviorChangeOnDefaultRestMethodPath) (July
29, 2018)
+- [Dual-purpose REST Java
interfaces](/docs/developer-info/04.07.DualPurposeRESTJavaInterfaces) (October
7, 2018)
+- [Pet Store application now uses
JPA](/docs/developer-info/04.08.PetStoreApplicationNowUsesJPA) (October 7, 2018)
+- [New article: Dual-purpose (end-to-end)
interfaces](/docs/developer-info/04.09.NewArticleDualPurposeInterfaces)
(October 19, 2018)
+- [Default system
configuration](/docs/developer-info/04.10.DefaultSystemConfiguration) (December
6, 2018)
+- [Spring Boot Integration](/docs/developer-info/04.11.SpringBootIntegration)
(December 7, 2018)
+- [Source javadoc tag](/docs/developer-info/04.12.SourceJavadocTag) (December
8, 2018)
+- [Import statements in configuration
files](/docs/developer-info/04.13.ImportStatementsInConfigurationFiles)
(December 31, 2018)
+
+### 2019
+
+- [Serializer and parser configuration
annotations](/docs/developer-info/04.14.SerializerAndParserConfigurationAnnotations)
(May 14, 2019)
+
+### 2020
+
+- [New and Improved
RestClient](/docs/developer-info/04.15.NewAndImprovedRestClient) (July 22, 2020)
diff --git a/docs/pages/developer-info/04.01.JUnitTestResults.md
b/docs/pages/developer-info/04.01.JUnitTestResults.md
new file mode 100644
index 0000000000..ad5b67d941
--- /dev/null
+++ b/docs/pages/developer-info/04.01.JUnitTestResults.md
@@ -0,0 +1,10 @@
+---
+id: 04.01.JUnitTestResults
+title: JUnit Test Results
+date: 2018-05-11
+authors:
+ - name: James Bognar
+---
+
+FYI....JUnit testcase results have been added to the Jenkins builds...
+
diff --git a/docs/pages/developer-info/04.02.RESTMediaTypeLessPOJORequests.md
b/docs/pages/developer-info/04.02.RESTMediaTypeLessPOJORequests.md
new file mode 100644
index 0000000000..c617b37d36
--- /dev/null
+++ b/docs/pages/developer-info/04.02.RESTMediaTypeLessPOJORequests.md
@@ -0,0 +1,16 @@
+---
+id: 04.02.RESTMediaTypeLessPOJORequests
+title: REST Media-Type-less POJO requests
+date: 2018-05-15
+authors:
+ - name: James Bognar
+---
+
+In 7.2.0, I'm adding support for POJO REST requests that don't include Accept
and Media-Type headers.
+
+Previously, if your requests did not contain Accept or Content-Type headers,
you had to use Readers and Writers to work with the HTTP request and response
bodies. Otherwise you would get Not Acceptable (406) and Unsupported Media Type
(415) response codes.
+
+This behavior is now being relaxed. If your request does not contain
media-type headers, then you can still used POJOs for requests and responses.
+
+For example, this is a snippet from the Javadoc on the Body annotation
describing the types of objects you can use in REST Java methods to represent
the body of the request:
+
diff --git a/docs/pages/developer-info/04.03.Juneau720DocumentationPreview.md
b/docs/pages/developer-info/04.03.Juneau720DocumentationPreview.md
new file mode 100644
index 0000000000..015aa6b60a
--- /dev/null
+++ b/docs/pages/developer-info/04.03.Juneau720DocumentationPreview.md
@@ -0,0 +1,18 @@
+---
+id: 04.03.Juneau720DocumentationPreview
+title: Juneau 7.2.0 documentation preview
+date: 2018-07-25
+authors:
+ - name: James Bognar
+---
+
+Juneau 7.2.0 is close to release but there is still a considerable amount of
documentation to be written. The Javadocs on the classes themselves should be
mostly complete, but much remains to be written in the overview document.
+
+I've uploaded a preview of the Javadocs so far here:
+
+http://juneau.apache.org/site/apidocs_preview/index.html
+
+To help identify new and in-progress documentation, I've added temporary color
coding to new and modified sections...
+
+If there is any documentation lacking, now would be a good time to point it
out (smile)
+
diff --git
a/docs/pages/developer-info/04.04.SupportForAutoValidationInSwaggerAnnotations.md
b/docs/pages/developer-info/04.04.SupportForAutoValidationInSwaggerAnnotations.md
new file mode 100644
index 0000000000..71bd493903
--- /dev/null
+++
b/docs/pages/developer-info/04.04.SupportForAutoValidationInSwaggerAnnotations.md
@@ -0,0 +1,29 @@
+---
+id: 04.04.SupportForAutoValidationInSwaggerAnnotations
+title: Support for auto-validation in Swagger annotations
+date: 2018-07-25
+authors:
+ - name: James Bognar
+---
+
+In 7.2, we're introducing auto-validation of Swagger annotations. What this
means is that the various Swagger annotations are not just used for populating
the Swagger JSON / UI, but are actively used in serializing/parsing/validating
the HTTP parts.
+
+For example:
+
+This example shows a parameter of type **PetStatus[]** (which happens to be
enums, but could also be POJOs as well). The **type** and **collectionFormat**
attributes tell the framework to parse the incoming value as a comma-delimited
list. The **_enum** shows the possible valid values. A **BadRequest** is thrown
if any values don't match.
+
+Part of this change includes combining the client-side and server-side
annotations into a single set of annotations (no more confusing
**org.apache.juneau.remoteable.Query** with
**org.apache.juneau.rest.annotation.Query**).
+
+Features include:
+
+* Support for all of Swagger 2.0.
+* Auto-validation for:
+ * Numeric values (**minimum**, **maximum**, **exclusiveMinimum**,
**exclusiveMaximum**, **multipleOf**).
+ * String values (**minLength**, **maxLength**, **enum**).
+ * Collection values (**items**, **minItems**, **maxItems**, **uniqueItems**).
+ * Object values (**properties**, **maxProperties**, **minProperties**,
**additionalProperties**).
+ * Existence of values (**required**, **allowEmptyValue**).
+* Support for both client-side and server-side annotations.
+* Works on the **Body** annotation as well. If the media-type of the body does
not match an existing serializer/parser, then the Swagger rules are used for
marshalling.
+* UON notation is still supported, so you can still represent arbitrary POJOs
as any of the HTTP parts. However, you have to explicitly specify
**format="uon"**.
+
diff --git a/docs/pages/developer-info/04.05.DocumentationReorg.md
b/docs/pages/developer-info/04.05.DocumentationReorg.md
new file mode 100644
index 0000000000..276f46643c
--- /dev/null
+++ b/docs/pages/developer-info/04.05.DocumentationReorg.md
@@ -0,0 +1,16 @@
+---
+id: 04.05.DocumentationReorg
+title: Documentation reorg
+date: 2018-07-25
+authors:
+ - name: James Bognar
+---
+
+FYI....I've broken up the **overview.html** file into individual topics:
+
+The overview document was just getting too unwieldy (the Eclipse HTML editor
struggled with it). The smaller parts should be easier to work with, and
reorganizing pages should now be much easier. Also, broken links should now be
fewer in number.
+
+The **DocGenerator** class will take all the individual pages and combine them
into the same **overview.html** page as before.
+
+The generator is not currently part of the build process so it has to be
executed manually to generate the overview.
+
diff --git
a/docs/pages/developer-info/04.06.BehaviorChangeOnDefaultRestMethodPath.md
b/docs/pages/developer-info/04.06.BehaviorChangeOnDefaultRestMethodPath.md
new file mode 100644
index 0000000000..bd09a701cd
--- /dev/null
+++ b/docs/pages/developer-info/04.06.BehaviorChangeOnDefaultRestMethodPath.md
@@ -0,0 +1,18 @@
+---
+id: 04.06.BehaviorChangeOnDefaultRestMethodPath
+title: Behavior change on default @RestMethod(path) value
+date: 2018-07-29
+authors:
+ - name: James Bognar
+---
+
+There's a behavior change being made to the default value on
**@RestMethod(path)**. If not specified, the value is now inferred from the
Java method name.
+
+This can result in cleaner-looking code.
+
+The previous behavior was to default to the value **"/\*"**.
+
+More information can be found here:
+
+http://juneau.apache.org/site/apidocs_preview/overview-summary.html#juneau-rest-server.RestMethod
+
diff --git a/docs/pages/developer-info/04.07.DualPurposeRESTJavaInterfaces.md
b/docs/pages/developer-info/04.07.DualPurposeRESTJavaInterfaces.md
new file mode 100644
index 0000000000..4c1e6da403
--- /dev/null
+++ b/docs/pages/developer-info/04.07.DualPurposeRESTJavaInterfaces.md
@@ -0,0 +1,27 @@
+---
+id: 04.07.DualPurposeRESTJavaInterfaces
+title: Dual-purpose REST Java interfaces
+date: 2018-10-07
+authors:
+ - name: James Bognar
+---
+
+**New in Juneau 7.2.1:**
+
+Method and argument annotations such as @RestMethod, @Path, etc..., are now
inheritable from parent classes and interfaces.
+
+This means you can now define the same Java interface for both your server and
client side APIs.
+
+For example, the Pet Store application now defines a top-level **PetStore**
interface:
+
+The **PetStoreResource** class implements this interface using the normal
RestServlet API.
+
+In this particular case, the @RestMethod annotations are specified in the
implementation class, although they could be located in the interface as well.
+
+The **PetStore** interface can be used as the remote proxy interface like so:
+
+The advantages to this design approach are:
+
+* It's much easier to keep server and client side APIs in sync since they're
working off the same interface.
+* The annotations can be moved into your interface where they won't interfere
with the readability of your servlet code.
+
diff --git a/docs/pages/developer-info/04.08.PetStoreApplicationNowUsesJPA.md
b/docs/pages/developer-info/04.08.PetStoreApplicationNowUsesJPA.md
new file mode 100644
index 0000000000..bea5ed4195
--- /dev/null
+++ b/docs/pages/developer-info/04.08.PetStoreApplicationNowUsesJPA.md
@@ -0,0 +1,16 @@
+---
+id: 04.08.PetStoreApplicationNowUsesJPA
+title: Pet Store application now uses JPA
+date: 2018-10-07
+authors:
+ - name: James Bognar
+---
+
+The Pet Store application has been upgraded to use JPA for persistence. It's
now possible to marshall JPA beans using Juneau serializers and parsers.
+
+For example, the Pet bean below combines JPA and Juneau annotations:
+
+One noted enhancements is that you can now define bean-property annotations
(e.g. @BeanProperty, @Html, @Schema, ...) on private bean fields just like JPA
annotations.
+
+Also, the @Schema annotation has been enhanced to provide more information for
bean properties in the auto-generated Swagger:
+
diff --git a/docs/pages/developer-info/04.09.NewArticleDualPurposeInterfaces.md
b/docs/pages/developer-info/04.09.NewArticleDualPurposeInterfaces.md
new file mode 100644
index 0000000000..25b81155a9
--- /dev/null
+++ b/docs/pages/developer-info/04.09.NewArticleDualPurposeInterfaces.md
@@ -0,0 +1,12 @@
+---
+id: 04.09.NewArticleDualPurposeInterfaces
+title: New article: Dual-purpose (end-to-end) interfaces
+date: 2018-10-19
+authors:
+ - name: James Bognar
+---
+
+FYI...new article added to Javadocs:
+
+http://juneau.apache.org/site/apidocs_preview/overview-summary.html#juneau-rest-client.RestProxies.DualPurposeInterfaces
+
diff --git a/docs/pages/developer-info/04.10.DefaultSystemConfiguration.md
b/docs/pages/developer-info/04.10.DefaultSystemConfiguration.md
new file mode 100644
index 0000000000..a9a271bb36
--- /dev/null
+++ b/docs/pages/developer-info/04.10.DefaultSystemConfiguration.md
@@ -0,0 +1,43 @@
+---
+id: 04.10.DefaultSystemConfiguration
+title: Default system configuration
+date: 2018-12-06
+authors:
+ - name: James Bognar
+---
+
+In 8.0, I'll be adding the concept of a default system configuration. One of
the annoyances of setting up the Juneau REST resources to work with Spring Boot
is that you have to manually set the "juneau.configFile" system property so
that our servlets know where to look for configuration. With a default system
configuration, this requirement goes away.
+
+Being added is a Config.getSystemDefault() static method that returns the
system default configuration.
+
+If "juneau.configFile" is set, it will continue to look for a configuration
file with that name in either the home directory or classpath. If not, then it
will look for the following:
+
+* In the home directory:
+ * `<jar-name>.cfg`
+ * Any files that end with .cfg in the JVM home directory.
+* In the classpath (as part of the jar):
+ * `<jar-name>.cfg`
+ * `juneau.cfg`
+ * `default.cfg`
+
+Note that by placing it in your jar, you gain having everything packaged as a
single uber-jar, but lose persistence (since it's not writeable).
+
+Also being added:
+
+* ConfigClasspathStore - A ConfigStore for reading configs from the context
classpath. Note that this is a read-only store.
+* ConfigStore.exists(name) - New method on interface for checking for the
existence of a configuration.
+
+Your REST servlets can refer to the system default configuration with the
special keyword "SYSTEM_DEFAULT".
+
+For example:
+
+```java
+// Always use system default
+@RestResource(config="SYSTEM_DEFAULT")
+
+// Use system property if set or the system default if not.
+@RestResource(config="$S{juneau.configFile,SYSTEM_DEFAULT}")
+```
+
+There is a corresponding Config.setSystemDefault(Config) for overriding the
system default configuration.
+
diff --git a/docs/pages/developer-info/04.11.SpringBootIntegration.md
b/docs/pages/developer-info/04.11.SpringBootIntegration.md
new file mode 100644
index 0000000000..4618473a13
--- /dev/null
+++ b/docs/pages/developer-info/04.11.SpringBootIntegration.md
@@ -0,0 +1,22 @@
+---
+id: 04.11.SpringBootIntegration
+title: Spring Boot Integration
+date: 2018-12-07
+authors:
+ - name: James Bognar
+---
+
+Hi all,
+
+I've made some modifications to the work that Marcelo contributed for the
Spring Boot integration. I still consider this in flux though and suggestions
are welcome.
+
+Here's the updated project layout:
+
+Here's what it looks like to start up a Spring app with Juneau Examples REST
resources:
+
+Another option is to add the @JuneauRest annotation on your configuration bean
method:
+
+The root resource will be initialized with the **SpringRestResourceResolver**
which allows for child resources to be defined as injectable Spring beans.
+
+The app can be launched from Eclipse using the
**juneau-examples-rest-springboot.launch** file. It will bring up the REST
examples on port 5000.
+
diff --git a/docs/pages/developer-info/04.12.SourceJavadocTag.md
b/docs/pages/developer-info/04.12.SourceJavadocTag.md
new file mode 100644
index 0000000000..0d99908040
--- /dev/null
+++ b/docs/pages/developer-info/04.12.SourceJavadocTag.md
@@ -0,0 +1,16 @@
+---
+id: 04.12.SourceJavadocTag
+title: Source javadoc tag
+date: 2018-12-08
+authors:
+ - name: James Bognar
+---
+
+I've added a Javadoc taglet for quickly linking to source code on GitHub:
"**`{@source}`**" or "**`{@source label}`**"
+
+It can be added to class-level javadocs like so:
+
+Based on the file location in the source tree, it will calculate the GitHub
link:
+
+I think this will be particularly useful if you want to provide source links
in example code javadocs.
+
diff --git
a/docs/pages/developer-info/04.13.ImportStatementsInConfigurationFiles.md
b/docs/pages/developer-info/04.13.ImportStatementsInConfigurationFiles.md
new file mode 100644
index 0000000000..8b32785082
--- /dev/null
+++ b/docs/pages/developer-info/04.13.ImportStatementsInConfigurationFiles.md
@@ -0,0 +1,16 @@
+---
+id: 04.13.ImportStatementsInConfigurationFiles
+title: Import statements in configuration files
+date: 2018-12-31
+authors:
+ - name: James Bognar
+---
+
+Support for import statements in configuration files has just been added:
+
+This is still a work-in-progress. The most difficult aspect was correctly
handling listener events for changes made in imported configurations, including
changes due to dynamically added or removed import statements. I'm still not
certain I've got all the concurrency aspects worked out correctly yet and
there's still more testing to be done.
+
+More information can be found in the docs:
+
+http://juneau.apache.org/site/apidocs-8.0.1/overview-summary.html#juneau-config.Imports
+
diff --git
a/docs/pages/developer-info/04.14.SerializerAndParserConfigurationAnnotations.md
b/docs/pages/developer-info/04.14.SerializerAndParserConfigurationAnnotations.md
new file mode 100644
index 0000000000..429ef8298a
--- /dev/null
+++
b/docs/pages/developer-info/04.14.SerializerAndParserConfigurationAnnotations.md
@@ -0,0 +1,23 @@
+---
+id: 04.14.SerializerAndParserConfigurationAnnotations
+title: Serializer and parser configuration annotations
+date: 2019-05-14
+authors:
+ - name: James Bognar
+---
+
+Added in 8.0.1 is a simplified approach for customizing serializers and
parsers in REST interfaces using annotations.
+
+The following example shows the old approach of using a generic
**@RestResource(properties)** annotations, and the new approach of using
specialized annotations:
+
+Annotations are provided for all serializers and parsers:
+
+Features:
+
+* Annotations can be applied to classes and methods.
+* Annotations can also be applied to parent classes and methods and are
combinable and overridable, applied in parent-to-child order.
+* All annotations support SVL variables (e.g. "$C{myConfigVar}").
+* Default values for all annotations can be set as system properties.
+* Default values for all annotations can also be set in the main configuration
file or application.properties file.
+* Annotations can be applied to serializers and parsers directly using new
**applyAnnotations(Class)** and **applyAnnotations(Method)** defined on the
serializer and parser builder and group builder classes.
+
diff --git a/docs/pages/developer-info/04.15.NewAndImprovedRestClient.md
b/docs/pages/developer-info/04.15.NewAndImprovedRestClient.md
new file mode 100644
index 0000000000..fb84f31746
--- /dev/null
+++ b/docs/pages/developer-info/04.15.NewAndImprovedRestClient.md
@@ -0,0 +1,59 @@
+---
+id: 04.15.NewAndImprovedRestClient
+title: New and Improved RestClient
+date: 2020-07-22
+authors:
+ - name: James Bognar
+---
+
+It's been a while since I've made any updates and wanted to let the community
know what I've been working on in 8.1.4. Currently in the snapshot release is
an entirely new RestClient API!
+
+The old RestClient API sort of grew organically as a 2nd-class citizen to the
server-side API. As such, it wasn't well tested and didn't fully take advantage
of the existing Apache HttpClient APIs. I was often finding bugs and
functionality often duplicated what already existed in HttpClient.
+
+The new API includes all the same functionality of the old, but with the
following advantages:
+
+* Extends directly from the Apache HttpComponents and Apache HttpClient APIs
instead of merely using them.
+* APIs are written for easy extension.
+* Adds fluent-style coding to HTTP calls including easy-to-use fluent
assertions.
+* Adds support for multiple simultaneous languages (including universal
language support).
+* Is nearly 100% unit tested.
+
+Here's an example of a fluent call from client creation to HTTP request and
handling:
+
+Constructing clients for supporting multiple languages is now as easy as:
+
+Parsers and serializers can be easily configured via convenience builder
methods like so:
+
+HTTP parts (headers, query/form-data parameters) now support dynamically
changing values through Suppliers:
+
+Full support for OpenAPI part schema serialization is provided on all HTTP
parts using a simple syntax on requests:
+
+...and responses:
+
+Response bodies can now be processed multiple times:
+
+This combined with a new powerful assertions API allows you to easily perform
complex fluent calls:
+
+For example, it's even possible to do complex assertions that involve parsing
and serialization:
+
+The new API still supports Remote proxy interfaces (but with some added new
features):
+
+Logging and debugging has been simplified:
+
+...which produces the following console output:
+
+The RestClient class extends directly from Apache HttpClient and so inherits
the same functionality. Fluent setters have been provided on the builder class
to make using these existing features easy:
+
+The RestClient class (and other classes) can be extended as well to provide
any sort of customization needed:
+
+Additionally, the two separate MockRest (for server side testing) and
MockRemote (for remote interface testing) have been replaced with a single
MockRestClient class that extends directly from RestClient which allows you to
take full advantage of the new assertions APIs as part of your unit tests:
+
+The MockRestClient class can also wrap instantiated beans which is
particularly useful if you're using Spring Boot for deployment of your REST
servlets:
+
+The following shows how to test remote interfaces using the new unified API:
+
+See the updated Javadocs for more information:
+
+* 9 - juneau-rest-client
+* 10 - juneau-rest-mock
+
diff --git a/docs/pages/developer-info/05.00.ArticlesIndex.md
b/docs/pages/developer-info/05.00.ArticlesIndex.md
new file mode 100644
index 0000000000..d6dc6d836f
--- /dev/null
+++ b/docs/pages/developer-info/05.00.ArticlesIndex.md
@@ -0,0 +1,17 @@
+---
+id: 05.00.ArticlesIndex
+title: Articles
+---
+
+## Articles
+
+This page contains links to technical articles about Apache Juneau published
on external sites.
+
+### 2018
+
+- **November 12, 2018** - [Serializing and deserializing POJOs into many
formats using Apache
Juneau](https://medium.com/@shalithasuranga/serializing-and-deserializing-pojos-in-to-many-formats-using-apache-juneau-6b68d97aee6c)
by Shalitha Suranga
+- **December 15, 2018** - [Construct HTML fragments, Atom feeds, Swagger
documents using Apache
Juneau](https://medium.com/@ayeshmanthaperera/construct-html-fragments-as-java-objects-using-apache-juneau-aeb9a9c5c2ca)
by Ayeshmantha Perera
+
+### 2019
+
+- **October 21, 2019** - [Pet Store with Apache Juneau Part
1](https://dev.to/robledokari/pet-store-with-apache-juneau-part-1-5cgm) by
Karina Robledo
diff --git a/docs/sidebars.ts b/docs/sidebars.ts
index 43074b89b0..9c324883ef 100644
--- a/docs/sidebars.ts
+++ b/docs/sidebars.ts
@@ -1945,6 +1945,158 @@ const sidebars: SidebarsConfig = {
},
],
},
+ // Developer Info section
+ {
+ type: 'category',
+ label: 'Developer Info',
+ collapsed: false,
+ items: [
+ {
+ type: 'doc',
+ id:
'developer-info/01.00.DeveloperLinks',
+ label: '1. Developer Links',
+ },
+ {
+ type: 'category',
+ label: '2. How-to Articles',
+ collapsed: false,
+ items: [
+ {
+ type: 'doc',
+ id:
'developer-info/02.01.BecomingAContributor',
+ label: '2.1. Becoming a
contributor',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/02.02.NonCommittersContribute',
+ label: '2.2. How
non-committers can contribute code',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/02.03.NewMemberGuidelines',
+ label: '2.3. New member
guidelines',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/02.04.NewReleaseGuidelines',
+ label: '2.4. New
release guidelines',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/02.05.VersioningGuidelines',
+ label: '2.5. Versioning
guidelines',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/02.06.CodeFormattingStylesheet',
+ label: '2.6. Using the
code formatting stylesheet',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/02.08.DevelopmentWishList',
+ label: '2.7.
Development wish list',
+ },
+ ],
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/03.00.CurrentMembers',
+ label: '3. Current Members',
+ },
+ {
+ type: 'category',
+ label: '4. Blog',
+ collapsed: false,
+ items: [
+ {
+ type: 'doc',
+ id:
'developer-info/04.00.BlogIndex',
+ label: '4.0. Blog
Posts',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.01.JUnitTestResults',
+ label: '4.1. JUnit Test
Results (2018-05-11)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.02.RESTMediaTypeLessPOJORequests',
+ label: '4.2. REST
Media-Type-less POJO requests (2018-05-15)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.03.Juneau720DocumentationPreview',
+ label: '4.3. Juneau
7.2.0 documentation preview (2018-07-25)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.04.SupportForAutoValidationInSwaggerAnnotations',
+ label: '4.4. Support
for auto-validation in Swagger annotations (2018-07-25)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.05.DocumentationReorg',
+ label: '4.5.
Documentation reorg (2018-07-25)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.06.BehaviorChangeOnDefaultRestMethodPath',
+ label: '4.6. Behavior
change on default @RestMethod(path) (2018-07-29)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.07.DualPurposeRESTJavaInterfaces',
+ label: '4.7.
Dual-purpose REST Java interfaces (2018-10-07)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.08.PetStoreApplicationNowUsesJPA',
+ label: '4.8. Pet Store
application now uses JPA (2018-10-07)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.09.NewArticleDualPurposeInterfaces',
+ label: '4.9. New
article: Dual-purpose interfaces (2018-10-19)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.10.DefaultSystemConfiguration',
+ label: '4.10. Default
system configuration (2018-12-06)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.11.SpringBootIntegration',
+ label: '4.11. Spring
Boot Integration (2018-12-07)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.12.SourceJavadocTag',
+ label: '4.12. Source
javadoc tag (2018-12-08)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.13.ImportStatementsInConfigurationFiles',
+ label: '4.13. Import
statements in configuration files (2018-12-31)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.14.SerializerAndParserConfigurationAnnotations',
+ label: '4.14.
Serializer and parser configuration annotations (2019-05-14)',
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/04.15.NewAndImprovedRestClient',
+ label: '4.15. New and
Improved RestClient (2020-07-22)',
+ },
+ ],
+ },
+ {
+ type: 'doc',
+ id:
'developer-info/05.00.ArticlesIndex',
+ label: '5. Articles',
+ },
+ ],
+ },
// Release Notes section
{
type: 'category',
@@ -1955,6 +2107,21 @@ const sidebars: SidebarsConfig = {
type: 'category',
label: 'Version 9.x',
items: [
+ {
+ type: 'doc',
+ id:
'release-notes/9.2.0',
+ label: '9.2.0',
+ },
+ {
+ type: 'doc',
+ id:
'release-notes/9.1.0',
+ label: '9.1.0',
+ },
+ {
+ type: 'doc',
+ id:
'release-notes/9.0.1',
+ label: '9.0.1',
+ },
{
type: 'doc',
id:
'release-notes/9.0.0',
diff --git a/docs/static/developer-info/how-to/NonCommittersContribute.1.png
b/docs/static/developer-info/how-to/NonCommittersContribute.1.png
new file mode 100644
index 0000000000..46c58f11a4
Binary files /dev/null and
b/docs/static/developer-info/how-to/NonCommittersContribute.1.png differ
diff --git a/docs/static/developer-info/how-to/NonCommittersContribute.2.png
b/docs/static/developer-info/how-to/NonCommittersContribute.2.png
new file mode 100644
index 0000000000..02cde8c126
Binary files /dev/null and
b/docs/static/developer-info/how-to/NonCommittersContribute.2.png differ
