This is an automated email from the ASF dual-hosted git repository.
lukaszlenart pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/struts-site.git
The following commit(s) were added to refs/heads/master by this push:
new 192213d Contributors guide (#147)
192213d is described below
commit 192213dc05bbd0eec83dc935ec690d17927c840d
Author: Lukasz Lenart <lukaszlen...@apache.org>
AuthorDate: Sun Oct 4 09:50:34 2020 +0200
Contributors guide (#147)
* Creates Contributors Guide starting page
* Drops WIP
* Adds how to build
* Adds Contributors Guide to the menu
* Adding section how create a release
* Uses the latest Maven summary
* Adds One time steps page
* Adds Sample Announcements page
* Converts new pages related to creating distro
* Uses proper back navigation
* Converts release guidelines
* Small updates
* Adds missing pages
---
source/_includes/header.html | 1 +
source/contributors/building-fast-track-release.md | 48 +++++
source/contributors/building-normal-release.md | 229 +++++++++++++++++++++
source/contributors/building-struts-annotations.md | 46 +++++
source/contributors/building-struts-master.md | 112 ++++++++++
.../building-the-framework-from-source.md | 70 +++++++
source/contributors/building-with-maven.md | 189 +++++++++++++++++
.../creating-and-signing-a-distribution.md | 37 ++++
source/contributors/documentation-style-guide.md | 214 +++++++++++++++++++
source/contributors/editing-the-documentation.md | 51 +++++
source/contributors/index.md | 36 ++++
source/contributors/obtaining-an-idea-license.md | 29 +++
source/contributors/one-time-steps.md | 128 ++++++++++++
source/contributors/precise-error-reporting.md | 31 +++
source/contributors/sample-announcements.md | 196 ++++++++++++++++++
source/core-developers/index.md | 2 +-
source/updating-website.md | 6 +-
17 files changed, 1421 insertions(+), 4 deletions(-)
diff --git a/source/_includes/header.html b/source/_includes/header.html
index 53cb691..25b579f 100644
--- a/source/_includes/header.html
+++ b/source/_includes/header.html
@@ -79,6 +79,7 @@
<li><a href="/youatstruts.html">You at Struts</a></li>
<li><a href="/helping.html">How to Help FAQ</a></li>
<li><a href="/dev-mail.html">Development Lists</a></li>
+ <li><a href="/contributors/">Contributors Guide</a></li>
<li class="divider"></li>
<li><a href="/submitting-patches.html">Submitting
patches</a></li>
<li><a href="/builds.html">Source Code and Builds</a></li>
diff --git a/source/contributors/building-fast-track-release.md
b/source/contributors/building-fast-track-release.md
new file mode 100644
index 0000000..7983c9d
--- /dev/null
+++ b/source/contributors/building-fast-track-release.md
@@ -0,0 +1,48 @@
+---
+layout: default
+title: Building Fast Track Release
+parent:
+ title: Creating and Signing a Distribution
+ url: creating-and-signing-a-distribution
+---
+
+# Building fast track release
+{:.no_toc}
+
+* Will be replaced with the ToC, excluding a header
+{:toc}
+
+## Getting ready
+
+Follow the same steps as for [Normal Release](building-normal-release)
+
+Please be aware you should create a new Security Bulletin in secret, you
should assign only `struts-committers` group
+to be visible for. If the release will fix a - hopefully yet undisclosed -
security issue, you must update
+the [Security
Bulletins](https://cwiki.apache.org/confluence/display/WW/Security+Bulletins)
page. It also needs to be
+accessible only by members of the `struts-committers` group.
+
+## Apply security patch
+
+Apply and commit security patch.
+
+## Next steps
+
+Follow the same steps as for [Normal Release](building-normal-release)
+
+- Prepare release
+- Perform the release
+- Jira stuff
+- Vote on it
+ - Post a release/quality vote to the dev list (and **only** the dev list).
The example mail is on [Sample announcements](sample-announcements)
+ page. Include the term "fast-track" in the subject, as: [VOTE] Struts
2.0.9.1 quality (fast track).
+ Please be aware this vote should be open only 24h!
+- Copy files
+- Promote release
+- Clean up old releases
+- Wait for rsync
+- Update site
+- Post announcements
+ - Announce the release and the vulnerability. Typically, this will be sent
to the reporter, the project's users list
+ (user@struts.a.o), the project's dev list (dev@struts.a.o), the project's
announce list (announcements@struts.a.o),
+ secur...@apache.org, full-disclos...@lists.grok.org.uk and
bugt...@securityfocus.com.
+ Samples are available at [Sample announcements](sample-announcements) page.
diff --git a/source/contributors/building-normal-release.md
b/source/contributors/building-normal-release.md
new file mode 100644
index 0000000..c154b18
--- /dev/null
+++ b/source/contributors/building-normal-release.md
@@ -0,0 +1,229 @@
+---
+layout: default
+title: Building Normal Release
+parent:
+ title: Creating and Signing a Distribution
+ url: creating-and-signing-a-distribution
+---
+
+# Building Normal Release
+{:.no_toc}
+
+* Will be replaced with the ToC, excluding a header
+{:toc}
+
+## Getting ready
+
+1. Ensure that the master POM and Struts Annotations have current releases
+2. Review JIRA for any issues without a fix version set, and for any issues
that should be resolved for the pending release.
+3. Ensure that there are no `repositories` or `pluginRepositories` listed in
the poms.
+4. Release the upcoming version in JIRA (under Administration/Manage Releases)
and tag the release date
+5. Add next milestone version to the JIRA roadmap
+6. Create DONE and TODO filters for the new version, share with all, and
remove obsolete TODO filter
+7. Create a new Version Notes page in Confluence, link from [Migration
Guide](https://cwiki.apache.org/confluence/display/WW/Migration+Guide),
+ and link to prior release page and JIRA DONE filters of the version to
release
+
+> Please remember to keep BOM subproject in sync -
<struts-version.version>X.X.X</struts-version.version> - must be
+> the same as the parent pom. The latest Maven version handles this case very
well, but it's worth checking if the bits
+> are in sync.
+
+> If needed, you can use [Versions Maven
Plugin](http://mojo.codehaus.org/versions-maven-plugin/) to set -SNAPSHOT
version
+> in all poms, like below:
+> `mvn versions:set -DnewVersion=2.3.16.1-SNAPSHOT -DgenerateBackupPoms=false`
+
+## Prepare release
+
+Tag the release by using the "release:prepare" goal of Maven:
+
+```
+mvn release:prepare -DautoVersionSubmodules=true
+```
+
+For a [dry
run](http://maven.apache.org/plugins/maven-release-plugin/usage.html), add
`-DdryRun=true`. If you do a dry
+run, use `mvn release:clean` to clean up after you have looked at the output.
+
+When prompted for the SCM tag name, follow this pattern:
`STRUTS_2_5_[PATCH_VERSION]`
+
+> If you get an error message, try to re-run `mvn release:prepare
-DautoVersionSubmodules=true` command again,
+> -Dresume flag is set to true by default and the plugin will resume the
release process from where it failed before.
+
+Follow the link to get [more
information](http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html)
+about performed operation by release plugin.
+
+## Perform the release
+
+```
+mvn release:perform -DretryFailedDeploymentCount=10
+```
+
+Follow the link to get [more
information](http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html)
+about performed operation by release plugin. After this step the artifacts
will be hosted by [Nexus](http://repository.apache.org/).
+
+The `-DretryFailedDeploymentCount=10` is needed when there are problems with
network connection (used just in case).
+
+If you need to run perform again, (or in a different box), do:
+
+```
+git checkout STRUTS_2_5_[PATCH_VERSION]
+mvn javadoc:javadoc deploy --no-plugin-updates -DperformRelease=true
-Papache-release
+```
+
+Next, log in to [Nexus](http://repository.apache.org/) and **close** staging
repository.
+
+> Repository is identified by user name and public IP address, so if in
meantime your IP changed, a new staging repository
+> will be created, so you must drop the old one (check the dates!) - if IP is
the same, artifacts will be uploaded
+> to the same repository as first attempt.
+
+## Move the assemblies
+
+To simplify testing, the assemblies have to be moved to the
`https://dist.apache.org/repos/dist/dev/struts/$VERSION` dir.
+
+After closing repository in Nexus, check if the release files are available
from staging repository as bellow:
+
+```
+https://repository.apache.org/content/groups/staging/org/apache/struts/struts2-assembly/$VERSION/
+```
+
+In order to move the assemblies login to people.apache.org and execute the
following code:
+
+```
+#!/bin/sh
+
+#create the destination directory
+echo "Creating working dir $VERSION"
+mkdir $VERSION
+cd $VERSION
+
+# get the distro
+echo "Getting distro $VERSION"
+wget -erobots=off -nv -l 1 --accept=jar,zip,md5,sha1,asc -r
--no-check-certificate -nd -nH
https://repository.apache.org/content/groups/staging/org/apache/struts/struts2-assembly/$VERSION
+
+# rename files
+echo "Renaming files"
+for f in *2-assembly*.zip*
+do
+ mv $f `echo $f | sed s/2-assembly//g`
+done
+
+# remove unneeded files
+echo "Removing uneeded files"
+for f in struts2-assembly-*.pom*
+do
+ rm $f
+done
+
+# remove uneeded hashes
+echo "Removing uneeded files"
+rm *.md5
+rm *.sha1
+
+# generates sha signatures
+echo "Generating SHA signatures"
+for f in *.zip
+do
+ shasum -a 256 $f > $f.sha256
+ shasum -a 512 $f > $f.sha512
+done
+
+cd ..
+
+# checking out repo
+echo "Publishing artifacts for test"
+svn --no-auth-cache co --depth empty
https://dist.apache.org/repos/dist/dev/struts/ struts-dev
+mv $VERSION struts-dev/
+cd struts-dev
+svn add --force ./
+svn --no-auth-cache commit -m "Updates test release $VERSION"
+
+cd ..
+rm -r struts-dev
+
+echo "Done!"
+```
+
+After this step artifacts are available for test here
[https://dist.apache.org/repos/dist/dev/struts/](https://dist.apache.org/repos/dist/dev/struts/)
+
+## Announce availability
+
+Send a short e-mail to `dev@struts.a.o` informing about the new packages and
to give people enough time to test
+the distribution (actual bits). Wait around a week before posting Vote. If no
show-stoppers reported, start a vote thread
+for build quality designation.
+
+## Push changes
+
+Do not forget to push your local changes to the Apache repo
+
+```
+git push
+```
+
+## Vote on it
+
+Post a release/quality vote to the dev list (and **only** the dev list). The
example mail is on [Sample announcements](sample-announcements)
+page. If the vote result is for an ASF release (i.e. not test build), update
site, announce. If the vote result is for GA,
+push to central.
+
+## Copy files
+
+After the vote, if the distribution is being mirrored (there was a favourable
release vote) move all the artefacts from
+`dev` folder into `release` folder:
+
+```
+svn mv https://dist.apache.org/repos/dist/dev/struts/$VERSION/
https://dist.apache.org/repos/dist/release/struts/
+```
+
+## Promote release
+
+Log in again to [Nexus](http://repository.apache.org/) and **release** the
repository, it will be automatically
+replicated across Maven Repositories. See [Releasing a Maven-based
project](http://maven.apache.org/developers/release/apache-release.html)
+for further details.
+
+## Clean up old releases
+
+Remove the old files from under
[https://dist.apache.org/repos/dist/release/struts/](https://dist.apache.org/repos/dist/release/struts/)
+to synchronise only the latest version with peers. All the files from
[https://dist.apache.org/repos/dist/release/struts/](https://dist.apache.org/repos/dist/release/struts/)
+are always mirrored to
[http://archive.apache.org/dist/struts/](http://archive.apache.org/dist/struts/).
You can use the below command:
+
+```
+svn del https://dist.apache.org/repos/dist/release/struts/2.3.x/
+```
+
+where `x` is the previous version to remove (or one more previous to keep
current and one version back).
+
+## Wait for rsync
+
+Wait 2-4 hours before proceeding.
+
+## Update site
+
+Make sure you have linked your Apache and Github account in Apache GitBox
(Dual Master Git allowing you to directly
+push to GitHub), see
[https://gitbox.apache.org/setup/](https://gitbox.apache.org/setup/)
+
+Please follow [the guideline](../updating-website) how to update the website,
below are additional steps that should be performed:
+
+- If a new DTD was defined, add it to `source/dtds`
+- Update current version and release date in `struts-site/_config.yml`
+- Update page source files
+ - `struts-site/source/announce.md` (if applicable, refer also to
corresponding security bulletin)
+ - `struts-site/source/downloads.html` (Prior Releases section)
+ - `struts-site/source/index.html` (some parts will updated automatically
with values defined in `_config.yml`)
+- You can generate the website locally with Docker Jekyll image
+ - you must have Docker installed and running
+ - if you are doing this the first time, download the official Struts image
to build the site from
+
[https://hub.docker.com/r/theapachestruts/struts-site-jekyll/](https://hub.docker.com/r/theapachestruts/struts-site-jekyll/)
+ - now you can use one of the bash scripts already provided in the
`struts-site`:
+ - `docker-run.sh` - used with Bash
+ - `docker-run.fish` - to use with Fish Shell (via `fish docker-run.fish`)
+ - now you can check the generated site at http://localhost:4000
+
+Please remember about updating JavaDocs using a dedicated Jenkins job as
described in [the guideline](../updating-website).
+
+## Post announcements
+
+We leave this as the last step, once the artifacts have had time to sync up on
the mirrors. Target it to:
+
+ - user@struts.a.o
+ - announcements@struts.a.o
+ - announce@a.o
+
+samples are available at [Sample announcements](sample-announcements) page.
diff --git a/source/contributors/building-struts-annotations.md
b/source/contributors/building-struts-annotations.md
new file mode 100644
index 0000000..50da0e7
--- /dev/null
+++ b/source/contributors/building-struts-annotations.md
@@ -0,0 +1,46 @@
+---
+layout: default
+title: Building Struts Master
+parent:
+ title: Creating and Signing a Distribution
+ url: creating-and-signing-a-distribution
+---
+
+# Building Struts Annotations
+{:.no_toc}
+
+* Will be replaced with the ToC, excluding a header
+{:toc}
+
+## Obtain a fresh check out of struts annotations
+
+```
+git clons https://gitbox.apache.org/repos/asf/struts-annotations.git
+```
+
+or you can just fetch & pull the latest changes
+
+## Prepare release
+
+```
+mvn release:prepare
+```
+
+Use the following pattern for the tag name: `STRUTS_ANNOTATIONS_[VERSION]`
+
+## Perform release
+
+```
+mvn release:perform
+```
+
+Log in to [Nexus](http://repository.apache.org/) and **close** the staging
repository.
+
+## Send a VOTE email
+
+A sample template is at [Sample announcements](sample-announcements) page (and
DO wait for the 72 hours period)
+
+## Promote release
+
+If the Vote passed log in again to [Nexus](http://repository.apache.org/) and
**promote** the repository - it will be
+automatically synced with Maven Central Repository.
diff --git a/source/contributors/building-struts-master.md
b/source/contributors/building-struts-master.md
new file mode 100644
index 0000000..fcf4548
--- /dev/null
+++ b/source/contributors/building-struts-master.md
@@ -0,0 +1,112 @@
+---
+layout: default
+title: Building Struts Master
+parent:
+ title: Creating and Signing a Distribution
+ url: creating-and-signing-a-distribution
+---
+
+# Building Struts Master
+{:.no_toc}
+
+* Will be replaced with the ToC, excluding a header
+{:toc}
+
+## Building Steps (Struts)
+
+### Obtain a fresh checkout
+
+```
+git clone https://gitbox.apache.org/repos/asf/struts-master.git
+```
+
+### Change site target
+
+Apply needed changes, in most cases it will be upgrade to the latest Apache
Parent POM, eg. from 9 to 10,
+commit the change.
+
+### Prepare release
+
+Tag the release by using the "release:prepare" goal of Maven:
+
+```
+mvn release:prepare -DautoVersionSubmodules=true
+```
+
+For a [dry
run](http://maven.apache.org/plugins/maven-release-plugin/usage.html), add
`-DdryRun=true`. If you do a dry run,
+use `mvn release:clean` to clean up after you have looked at the output.
+
+When prompted for the SCM tag name, follow this pattern:
`STRUTS_MASTER_[PATCH_VERSION]`
+
+If for some reason, the release plugin might fail to tag the release, if it
fails, run:
+
+```
+mvn release:prepare -Dresume
+```
+
+This step will ([more
information](http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html)):
+
+- Check that there are no uncommitted changes in the sources
+- Check that there are no SNAPSHOT dependencies
+- Change the version in the poms from x-SNAPSHOT to a new version (you will be
prompted for the versions to use)
+- Transform the SCM information in the POM to include the final destination of
the tag
+- Run the project tests against the modified POMs to confirm everything is in
working order
+- Commit the modified POMs
+- Tag the code in the SCM with a version name (this will be prompted for)
+- Bump the version in the POMs to a new value y-SNAPSHOT (these values will
also be prompted for)
+- Commit the modified POMs
+
+### Perform the release
+
+```
+mvn release:perform
+```
+
+This step will ([more
information](http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html)):
+
+- Checkout from an SCM URL with optional tag
+- Run the predefined Maven goals to release the project (by default, deploy
site-deploy)
+
+After this step the artifacts will be hosted by
[Nexus](http://repository.apache.org/)
+
+If you need to run perform again, (or in a different box), do:
+
+```
+git co tags/$VERSION
+mvn deploy site-deploy --no-plugin-updates -DperformRelease=true
+```
+
+Next, log in to [Nexus](http://repository.apache.org/) and **close** staging
repository.
+
+### Announce availability
+
+Send a short e-mail to `dev@struts.a.o` informing about the new packages and
to give people enough time to test
+the distribution (actual bits). Wait around a week before posting Vote. If no
show-stoppers reported, start a vote
+thread for build quality designation.
+
+The new build is available from staging repository:
`https://repository.apache.org/content/groups/staging/org/apache/struts/struts-master/[PATCH_VERSION]/`
+
+### Vote on it
+
+Post a release/quality vote to the dev list (and **only** the dev list). The
example mail is on [Sample Announcements](sample-announcements) page.
+
+If the vote result is for an ASF release (i.e. not test build), update site,
announce. If the vote result is for GA, push to central.
+
+### Promote release
+
+Log in again to [Nexus](http://repository.apache.org/) and **release** the
repository, it will be automatically replicated across Maven Repositories
+
+See [Releasing a Maven-based
project](http://maven.apache.org/developers/release/apache-release.html) for
further details.
+
+### Wait for rsync
+
+Wait 2-6 hours before proceeding.
+
+### Post announcements
+
+We leave this as the last step, once the artifacts have had time to sync up on
the mirrors. Target it to:
+
+- user@struts.a.o
+- announcements@struts.a.o
+
+samples are available at [Sample announcements](sample-announcements) page.
diff --git a/source/contributors/building-the-framework-from-source.md
b/source/contributors/building-the-framework-from-source.md
new file mode 100644
index 0000000..0f1fe95
--- /dev/null
+++ b/source/contributors/building-the-framework-from-source.md
@@ -0,0 +1,70 @@
+---
+layout: default
+title: Building the Framework from Source
+parent:
+ title: Contributors Guide
+ url: index.html
+---
+
+# Building the Framework from Source
+{:.no_toc}
+
+* Will be replaced with the ToC, excluding a header
+{:toc}
+
+## Why Build?
+
+Most developers will never need to build the framework from source. The
distribution package contains everything
+a developer needs to get started and become productive with the framework. For
more on how to go to work with
+the distributed binaries right away, see _Ready, Set, Go\!_ . However, there
are situations when someone will want
+to build the framework from scratch. You may want to try out new tweaks and
patches, or you might want to try writing
+your own tweak or patch.
+
+> If you just want to use the latest development build, perhaps because a
patch you need has been applied, you can
+> also [download a nightly
build](http://ci.apache.org/projects/struts/nightlies/).
+
+## Getting the Sources
+
+The source code for the framework is available as a distribution you can
download directly and from the source code repository.
+
+## Distribution
+
+The distributions of the framework contain all sources, as well as all needed
libraries for building JARs and running.
+Distributions can be downloaded from the [Apache Struts
project](../../downloads)
+
+## Repository (Git)
+
+Use [Git](https://git-scm.com/) to checkout the source code.
+
+```
+> cd Projects\Apache\
+> git clone https://gitbox.apache.org/repos/asf/struts.git
+```
+
+## Building with Maven
+
+The default build environment is Maven. You can either install Maven 3 or use
Maven Wrapper delivered with the source code.
+Change to your framework home directory:
+
+```
+cd Projects\Apache\struts
+```
+
+and run Maven
+
+```
+mvn clean install
+```
+
+or run using Maven Wrapper
+
+```
+./mvnw clean install
+```
+
+That will take care of the basic maven build. There is a bunch more that you
can do. Checkout out [Building with Maven](building-with-maven)
+for more information.
+
+## JDK/JRE Compatibility
+
+The framework requires JDK 1.8 to build.
diff --git a/source/contributors/building-with-maven.md
b/source/contributors/building-with-maven.md
new file mode 100644
index 0000000..7dc408c
--- /dev/null
+++ b/source/contributors/building-with-maven.md
@@ -0,0 +1,189 @@
+---
+layout: default
+title: Building with Maven
+parent:
+ title: Contributors Guide
+ url: index.html
+---
+
+# Building with Maven
+{:.no_toc}
+
+* Will be replaced with the ToC, excluding a header
+{:toc}
+
+[Maven 3.0.0 or later](http://maven.apache.org) is required to build Struts 2
+
+First, let's review some Maven basics. Maven uses the notion of a build
_life-cycle_ to which plugins can attach.
+Plugins are similar to Ant tasks. When a Maven build is invoked, we specify a
point in the life-cycle up to which
+the build _should_ proceed. The _compile_ phase comes before _test_ , and
_test_ comes before _package_ , and _package_
+comes before _install_ . Once we have Maven setup, we can invoke the Struts
build, and specify which phase the build should use.
+
+## Installing
+
+The _install_ phase builds up the project ("package"), and installs any JARs
it needs into your local repository, e.g.:
+
+```
+~/.m2/repository
+```
+
+Once installed, the JARs can be used by any other Maven project you build.
The _install_ phase is the **default** phase
+if none is specified.
+
+To run a basic install, change to the root of the source distribution, and
enter
+
+```
+mvn
+```
+
+That's it! Maven will download any dependencies the build needs; run all unit
tests; package up the JARs; then install th
+e new JARs locally. For your convenience, copies of the JARs can be found in
the _target_ directories of each module.
+For example, after the build, the main JAR can found at
+
+```
+core/target/struts2-core-2.0-SNAPSHOT.jar
+```
+
+> Sometimes, licensing restrictions prevent Maven from downloading all the
JARs that a build might need. For example,
+> JavaMail and Activation, can only be downloaded from Sun. When this happens,
Maven will display a helpful message
+> that explains how to install these JARs manually. After downloading the
required JAR, follow the instructions
+> to install it to the your local repository. Once installed, the JAR is
available to all your Maven builds, not just Struts.
+
+**Initial Build Successful**
+
+```
+[INFO] ------------------------------------------------------------------------
+[INFO] Reactor Summary:
+[INFO]
+[INFO] Struts 2 Bill of Materials ......................... SUCCESS [ 1.188 s]
+[INFO] Struts 2 2.5.24-SNAPSHOT ........................... SUCCESS [ 2.249 s]
+[INFO] Struts 2 Core ...................................... SUCCESS [01:13 min]
+[INFO] Struts Plugins ..................................... SUCCESS [ 0.232 s]
+[INFO] Struts 2 Configuration Browser Plugin .............. SUCCESS [ 1.374 s]
+[INFO] Struts 2 Sitemesh Plugin ........................... SUCCESS [ 1.429 s]
+[INFO] Struts 2 Tiles Plugin .............................. SUCCESS [ 2.303 s]
+[INFO] Struts 2 DWR Plugin ................................ SUCCESS [ 0.905 s]
+[INFO] Struts 2 Spring Plugin ............................. SUCCESS [ 2.232 s]
+[INFO] Struts 2 Convention Plugin ......................... SUCCESS [ 4.540 s]
+[INFO] Struts 2 JUnit Plugin .............................. SUCCESS [ 4.297 s]
+[INFO] Struts 2 JSON Plugin ............................... SUCCESS [ 5.384 s]
+[INFO] Struts 2 Bean Validation Plugin .................... SUCCESS [ 3.345 s]
+[INFO] Struts 2 Webapps ................................... SUCCESS [ 0.391 s]
+[INFO] Struts 2 Showcase Webapp ........................... SUCCESS [ 6.104 s]
+[INFO] Struts 2 REST Plugin ............................... SUCCESS [ 4.058 s]
+[INFO] Struts 2 Rest Showcase Webapp ...................... SUCCESS [ 1.524 s]
+[INFO] Struts 2 CDI Plugin ................................ SUCCESS [ 2.758 s]
+[INFO] Struts 2 Embedded JSP Plugin ....................... SUCCESS [ 8.111 s]
+[INFO] Struts 2 GXP Plugin ................................ SUCCESS [ 1.137 s]
+[INFO] Struts 2 Jasper Reports Plugin ..................... SUCCESS [ 4.392 s]
+[INFO] Struts 2 Java Templates Plugin ..................... SUCCESS [ 2.666 s]
+[INFO] Struts 2 JFreeChart Plugin ......................... SUCCESS [ 3.169 s]
+[INFO] Struts 2 OSGi Plugin ............................... SUCCESS [ 3.209 s]
+[INFO] Struts 2 OVal Plugin ............................... SUCCESS [ 3.113 s]
+[INFO] Struts 2 Pell Multipart Plugin ..................... SUCCESS [ 0.842 s]
+[INFO] Struts 2 Plexus Plugin ............................. SUCCESS [ 1.003 s]
+[INFO] Struts 2 Portlet Plugin ............................ SUCCESS [ 5.210 s]
+[INFO] Struts 2 Portlet Tiles Plugin ...................... SUCCESS [ 0.999 s]
+[INFO] DEPRECATED: Struts 2 Sitegraph Plugin .............. SUCCESS [ 2.634 s]
+[INFO] Struts 2 TestNG Plugin ............................. SUCCESS [ 2.081 s]
+[INFO] Struts OSGi Bundles ................................ SUCCESS [ 0.083 s]
+[INFO] Struts 2 OSGi Admin Bundle ......................... SUCCESS [ 1.237 s]
+[INFO] Struts 2 OSGi Demo Bundle 2.5.24-SNAPSHOT .......... SUCCESS [ 1.157 s]
+[INFO] ------------------------------------------------------------------------
+[INFO] BUILD SUCCESS
+[INFO] ------------------------------------------------------------------------
+[INFO] Total time: 02:39 min
+[INFO] Finished at: 2020-08-14T11:24:15+02:00
+[INFO] ------------------------------------------------------------------------
+```
+
+## Other phases
+
+There are other phases that can be useful when working with Maven. The
_package_ phase will just JAR (or WAR) the modules.
+The _test_ phase will only execute unit-tests. The _compile_ phase will only
build the source-code (but not the test sources).
+And the _clean_ phase will remove all artifacts, typically the entire _target_
directory.
+
+## Maven Tips
+
+A few helpful tips for using Maven are provided:
+
+### Skip exporting pages from Confluence
+
+The whole Struts2 documentation resists on Confluence and during normal build
process is exported with SiteExporter tool
+locally to html files. To perform that, you must have an account on
Confluence. In most cases you don't need to export
+the whole Confluence, so you can skip this, just type command:
+
+```
+mvn clean install -DskipWiki
+```
+
+### Skip creating assemblies
+
+During normal development cycle you don't need to create assembly packages
which consist of all the libraries,
+example apps and docs - you can skip them as well:
+
+```
+mvn clean install -DskipAssembly
+```
+
+### Offline mode
+
+If you are disconnected from the Internet or simply wish to make your build
faster, pass in the **-o** argument
+and Maven won't check for new modules to download.
+
+```
+mvn -o
+```
+
+### OutOfMemoryError
+
+If you get an OutOfMemoryError while running the tests:
+
+```
+// Bash
+export MAVEN_OPTS=-Xmx512m
+
+// Windows
+set MAVEN_OPTS=-Xmx512m
+```
+
+### Skipping test execution
+
+Although this shouldn't ever happen, sometimes tests do fail and you need to
build the framework anyway.
+If there's a problem, you can pass in the skip tests parameter.
+
+```
+mvn -Dmaven.test.skip=true
+```
+
+Of course, if you find tests are failing, please submit a patch to fix them!
+
+### Debugging build failures
+
+Struts 2 depends on the current snapshot artifact of XWork 2. Unfortunately,
if XWork 2 is modified in a significant way,
+the Struts build doesn't check for and retrieve a new version of the XWork
snapshot jar, resulting in compilation or unit test failures.
+
+The solution is to clear out any stale XWork 2 jars in your local Maven
repository, usually by removing the directory
+
+```
+~/.m2/repository
+```
+
+This will force the Struts Maven build to pull down a fresh copy of XWork and
hopefully resolve your problem.
+
+## First time building
+
+In some cases it has been seen that Maven will complain if a module doesn't
exist, even though it is part of the current
+build. Often, the missing module turns up when executing
+
+```
+mvn package
+```
+
+A simple fix for this is to run
+
+```
+mvn install
+```
+
+instead. If you have to do this, it will probably only be a one time thing.
diff --git a/source/contributors/creating-and-signing-a-distribution.md
b/source/contributors/creating-and-signing-a-distribution.md
new file mode 100644
index 0000000..c0cf70f
--- /dev/null
+++ b/source/contributors/creating-and-signing-a-distribution.md
@@ -0,0 +1,37 @@
+---
+layout: default
+title: Creating and Signing a Distribution
+parent:
+ title: Contributors Guide
+ url: index.html
+---
+
+# Creating and Signing a Distribution
+{:.no_toc}
+
+* Will be replaced with the ToC, excluding a header
+{:toc}
+
+## How to prepare a normal release ?
+
+- create a Version Notes page and start adding important changes to it
+- create a filter in JIRA with `Fix Version` pointing to the release version
you want to prepare
+- review JIRA issues and re-organise them, move the `Fix Version` to the next
release or `Future`, mark what should be
+ solved in the release you're working on
+
+## How to prepare a fast track release ?
+
+- keep all the information confidential as possible, communicate throughout
security@struts.a.o group
+- restrict access to all the related pages created in Confluence to
struts-committers group only, they can be made
+ public available after a fix or workaround has been released
+
+## What do you want to build ?
+
+Depends on what you want to achieve, please select topic from the list below:
+
+- [One time steps](one-time-steps) - before you start preparing a distribution
+- [Sample announcements](sample-announcements) - announcements used to
communicate the achievement
+- [Building Struts Master](building-struts-master) - how to release Struts
Master
+- [Building Struts Annotations](building-struts-annotations) - when you want
to prepare a new distribution of Struts Annotations (if something changed)
+- [Building Struts 2 - Normal release](building-normal-release) - the most
common used path
+- [Building Struts 2 - Fast track release](building-fast-track-release) - how
to prepare a fast track release with important security patch
diff --git a/source/contributors/documentation-style-guide.md
b/source/contributors/documentation-style-guide.md
new file mode 100644
index 0000000..f525854
--- /dev/null
+++ b/source/contributors/documentation-style-guide.md
@@ -0,0 +1,214 @@
+---
+layout: default
+title: Documentation Style Guide
+parent:
+ title: Contributors Guide
+ url: index.html
+---
+
+# Documentation Style Guide
+{:.no_toc}
+
+* Will be replaced with the ToC, excluding a header
+{:toc}
+
+It's well-known that a consistent user interface is easier to use. Consistency
helps users focus on the task rather
+than the user interface. Likewise, a consistent documentation style helps
users focus on the information, rather
+than the formatting.
+
+A related goal is to design the documentation so that it is easy to maintain,
so that it tends to remain internally
+consistent with the framework itself.
+
+## Do it now. Do it once. Do it well.
+
+Overall, there are three goals for the documentation system.
+
+- Say it all
+- Say it once
+- Say it well
+
+First, we want the documentation to be both complete and concise. This is job
one! The documentation should also be a quick
+but practical introduction to the framework, so newcomers can get started as
easily as possible. To keep people coming back,
+the documentation should also be a repository of the tips and tricks we use in
our own applications, so that people can find
+it here instead of asking over and over again on the list.
+
+Second, the documentation should be easy to maintain. Ideally, we should cover
the detail of each topic once, and draw
+as much detail from the source code and examples as possible (using the
_snippet macro_).
+
+Third, the documentation should be text-book quality; if not in the first
draft, then in the next. Don't hesitate
+to hack in a new page. Better that we have the page than we don't. (See Job
One!) But, as time allows, we should try
+to make each page the best that it can be. A great many people access the
documentation, and it's worth the effort
+to make the "documentation experience" productive and enjoyable.
+
+## Capitalization of common terms
+
+- Java
+- Javadoc
+- HTML
+- XML
+
+## General Punctuation and Grammar
+
+Good online resources for punctuation, grammar, and text style include
+
+- [Wikipedia Manual of
Style](https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style)
+
+In print, two excellent (and inexpensive!) resources are
+
+- [The Elements of
Style](https://www.amazon.com/exec/obidos/tg/detail/-/020530902X/apachesoftwar-20/)
+- [Associated Press
Stylebook](https://www.amazon.com/exec/obidos/tg/detail/-/0465004881/apachesoftwar-20/)
+
+Also excellent, but more expensive:
+
+- [Chicago Manual of Style](https://www.chicagomanualofstyle.org/)
+
+## Quick Tips
+
+- Use as few words as possible. Instead of "but there are some quirks about
it" try "but there are quirks".
+- If a list of items includes both a term and an explanation, consider using a
table instead of bullets.
+- Avoid using "This" by itself. Instead of "This lets us" try "This strategy
lets us".
+ - Ask yourself: "This what?"
+- References to other wiki pages can be unqualified. For example: "See ."
+
+## Don't be smurfy!
+
+A lot of API members use the term "action". We have
+
+- action extensions on pages,
+- action attributes in forms,
+- action elements in configuration files, and
+- Action Java classes, some of which may implement the
+- Action interface.
+
+Here are some terms that can be used to help clarify which action is which.
+
+- Use "the framework" or "Struts 2" to refer to the codebase as a whole,
including any frameworks we use internally, like OGNL.
+- Use "Action class" or "action handler" to refer to the Java class
incorporated by the action element.
+- Use "action mapping" to refer to the object created by the action element.
+
+## Page Save Comment
+
+Try to include a brief description of a change when saving a page. The
comments are included in the page's history.
+The comments are also included on the daily change report. In a group
environment, it's important to help each other follow along.
+
+## Parent Pages
+
+Use the Parent Page feature to create a hierarchy of pages. The parent pages
are reflected in the "bread crumb" menu.
+If properly used, parent pages can help browsers "visualize" the documentation
as an outline.
+
+The root of the documentation is the "Home" page, which is also the "Welcome"
page. The documentation is ordered into
+three main areas: Tutorials, FAQs, and Guides. Each area has a contents page,
whose parent is Home. Other pages within
+each section can also serve as parents, to help organize the documentation
into a coherent outline.
+
+## Labels
+
+Pages can be cross-indexed with the Label feature. Labels are not be used much
yet, except for internal authoring.
+
+| FIXME | A page that mentions a problem in the distribution that we intend to
fix. Review these pages before tagging a distribution to see if the issue has
been resolved. |
+|-------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| TODO | A page that is incomplete. Try to complete these pages before tagging
a distribution |
+
+## Avoid skipping headers
+
+The headers form an outline for the page. When writing term papers, it is not
a good practice to skip outline levels.
+When writing hypertext, it is not a good practice to skip heading levels
either. Try not to skip from a `h2` to a `h4`.
+
+> If you find yourself writing too many h2 headings in a single page, consider
breaking the page into child pages.
+
+## More on Text Effects
+
+Text effects like **strong**, _emphasis_ , and inserted can be used in the
usual way to denote important parts of a sentence.
+
+`Monospaced` should be used to files, tags, and methods, like `struts.xml`,
`<xmltag />`, and `execute`.
+Class and Interface names may be left in normal face, like Action and
Interceptor.
+
+A panel should be preferred to a block quote. The color fonts should be
avoided or used only with great care.
+Some people have difficulty seeing some colors, and the colors may not be
apparent if the page is printed.
+
+## Text Breaks
+
+Text breaks should not be used to format blocks on the screen. If there is an
issue with the way paragraphs or headings
+are being rendered, we should customize the stylesheet.
+
+## Lists
+
+Unordered lists should be created only with the `-` notation.
+
+Ordered list should be used when numbering the items is important. Otherwise,
prefer unordered lists.
+
+- This is an unordered list in star notation;
+- Items can have sub-items
+ - That can have sub-items
+ - That can have sub-items ...
+ - What is the limit?
+- Mixing ordered and unordered lists is possible:
+ 1. One;
+ 2. Two;
+ 3. Three.
+
+## Images
+
+Avoid using external images for bullets or icons. Prefer the equivalents
provided with Confluence.
+
+Images can be included by URL or annexing the binary to the page. Prefer
annexing when possible, since URLs are subject to change.
+
+Always observe copyright issues. Do not annex images unless it an original or
public domain work, or the author has donated the image to the foundation.
+
+Example:
+
+
+
+## Tables
+
+Prefer lists for single-value entries. Prefer tables for lists with multiple
columns.
+
+Tables are very useful when lists just don't do it. Meaning: don't write a
table when a list suffices. Tables are more
+organized, because you can align the text in columns. Since the markup text
for tables in Confluence is not easy to read,
+complex and big tables can be hard to maintain.
+
+| File | Optional | Location (relative to webapp) | Purpose |
+|------|----------|-------------------------------|---------|
+|`web.xml` | no | /WEB-INF/ | Web deployment descriptor to include all
necessary WebWork components |
+|`struts.xml` | no | /WEB-INF/classes/ | Main configuration, contains
result/view types, action mappings, interceptors, and so forth |
+
+## Advanced Formatting
+
+Try to specify the language for \`\`\` ... \`\`\` blocks.
+
+**HelloWorld.java**
+
+```java
+/** Hello World class. */
+public class HelloWorld {
+ /** Main method. */
+ public static void main(String[] args) {
+ System.out.println("Hello, World!");
+ }
+}
+```
+
+Avoid tabs in code blocks, use two spaces instead. Long lines should be
formatted to fit in a 800x600 resolution screen,
+without resorting to horizontal scrolling.
+
+A typical example of "non-lang" block would be the command line statements to
compile and run the code above.
+
+The terminal notation `$` should be used to represent a system prompt.
+
+**Compiling and Running Hello World**
+
+```
+$ javac HelloWorld.java
+
+$ java HelloWorld
+Hello, World!
+```
+
+## Change Happens
+
+Anyone who has worked with databases knows the value of normalizing the
schema. Ideally, we want to store each fact
+exactly once, and then use query system to retrieve that fact wherever it is
needed. If we store a fact once, we only
+need to update it once, and we avoid inconsistencies in our data set.
+
+To the extent possible, we want to "normalize" our technical documentation.
Like a database, all technical documentation
+is subject to change. When change happens, we want the documentation to be as
easy to update as possible. One way to do
+that is to try and minimize redundancy (without sacrificing ease of use).
diff --git a/source/contributors/editing-the-documentation.md
b/source/contributors/editing-the-documentation.md
new file mode 100644
index 0000000..0120d17
--- /dev/null
+++ b/source/contributors/editing-the-documentation.md
@@ -0,0 +1,51 @@
+---
+layout: default
+title: Editing the Documentation
+parent:
+ title: Contributors Guide
+ url: index.html
+---
+
+# Editing the Documentation
+{:.no_toc}
+
+* Will be replaced with the ToC, excluding a header
+{:toc}
+
+Changes to the documentation can be requested to the [issue
tracker](https://issues.apache.org/struts/secure/Dashboard.jspa),
+or created via Pull Requests to the Github
[repository](https://github.com/apache/struts-site). You can notice a button
+in the upper left corner labeled `Edit on GitHub` which helps you create
changes to the docs.
+
+The Struts 2 Documentation space is bundled with the Struts distribution, and,
eventually, the content may be checked
+into an ASF repository. Accordingly, all volunteers working to this space must
have a CLA on file.
+
+The project also hosts a second Confluence space, the [Struts 2
wiki](http://cwiki.apache.org/S2WIKI/home.html),
+which can be edited by anyone who creates an account.
+
+See also: [How to Help FAQ](../helping).
+
+## Documentation Workflow
+
+Since projects like Struts wear our code "on our sleeve", there's always a
discussion over whether the website should
+represent the latest documentation or the documentation for the "best
available" release. Over the years, we've done it
+one way and the another, and now we do it both ways :-)
+
+- [http://cwiki.apache.org/WW/home.html](http://cwiki.apache.org/WW/home.html)
+
+When we vote a test build to a release (of any flavor: alpha, beta, GA), we
archive the HTML version of the documentation
+for future reference. When a release is designated GA, we update the
appropriate links on the main site to point
+to the archival copy.
+
+Since we bundle the HTML version of the documentation with the release, we
require authors to file a CLA, to ensure that
+we actually have distribution rights.
+
+To cover all the bases, we also maintain a "community wiki", that is not
bundled with the distribution.
+
+-
[http://cwiki.apache.org/S2WIKI/home.html](http://cwiki.apache.org/S2WIKI/home.html)
+
+It's open to anyone who signs up for an account on Confluence. Sometimes, we
do move documentation from the community wiki
+to the documentation wiki, if the author can a CLA.
+
+Sadly, not everyone can file a CLA. Many organizations still use aggressive IP
agreement that assign rights to our every
+stray thought to the company, 24/7. In fact, some organizations grant a
special dispensation for the ASF so that their
+employees can file CLAs.
diff --git a/source/contributors/index.md b/source/contributors/index.md
new file mode 100644
index 0000000..a8c1e75
--- /dev/null
+++ b/source/contributors/index.md
@@ -0,0 +1,36 @@
+---
+layout: default
+title: Contributors Guide
+---
+
+# Contributors Guide
+
+## Source
+
+- [Building the Framework from Source](building-the-framework-from-source)
+ - [Building with Maven](building-with-maven)
+- [Creating and Signing a Distribution](creating-and-signing-a-distribution)
+- [Precise Error Reporting](precise-error-reporting)
+- [Obtaining an IDEA license](obtaining-an-idea-license)
+- [How to Write Doc Comments for the Javadoc
Tool](https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html)
(Oracle)
+
+## Documentation
+
+- [Editing the Documentation](editing-the-documentation)
+- [Documentation Style Guide](editing-the-documentation)
+
+## Licensing and Copyright
+
+- [Third Party Licensing Policy
RFC](http://people.apache.org/~cliffs/3party.html)
+- [ASF Source Header and Copyright Notice
Policy](http://www.apache.org/legal/src-headers.html)
+- [Author Tags](http://tinyurl.com/mw7t6)
+
+## Quick Links
+
+- [How to Help FAQ](../../helping)
+- [Project Charter](../../bylaws)
+- [Volunteers](../../volunteers)
+- [Release Guidelines](../../releases)
+- [Javadocs](http://people.apache.org/~mrdon/action2-api/)
+- [Source code repository](https://svn.apache.org/repos/asf/struts/action2)
+- [Our WebWork
roots](http://today.java.net/pub/a//today/2005/02/25/opensymphony.html)
diff --git a/source/contributors/obtaining-an-idea-license.md
b/source/contributors/obtaining-an-idea-license.md
new file mode 100644
index 0000000..539e661
--- /dev/null
+++ b/source/contributors/obtaining-an-idea-license.md
@@ -0,0 +1,29 @@
+---
+layout: default
+title: Obtaining an IDEA license
+parent:
+ title: Contributors Guide
+ url: index.html
+---
+
+# Obtaining an IDEA license
+{:.no_toc}
+
+* Will be replaced with the ToC, excluding a header
+{:toc}
+
+## How do ASF Committers obtain an IDEA license?
+
+Please read the following blog post about JetBrains support for Apache -
[JetBrains Supports the Apache Software
Foundation](https://blog.jetbrains.com/blog/2019/05/30/jetbrains-supports-the-apache-software-foundation/)
+
+### How do I get a apache.org email account to get the IDEA License?
+
+The Apache Software Foundation is an organization, and not a free web host. An
ASF account is earned by making sustained
+and welcome contributions to a project. For more, see:
+
+-
[http://apache.org/foundation/faq.html#joining](http://apache.org/foundation/faq.html#joining)
+-
[http://apache.org/foundation/how-it-works.html#meritocracy](http://apache.org/foundation/how-it-works.html#meritocracy)
+-
[http://struts.apache.org/helping.html](http://struts.apache.org/helping.html)
+
+The reason JetBrains (among others) give committers licenses is because we
have earned them by helping to create open
+source products, many of which JetBrains uses internally.
diff --git a/source/contributors/one-time-steps.md
b/source/contributors/one-time-steps.md
new file mode 100644
index 0000000..ce06b4c
--- /dev/null
+++ b/source/contributors/one-time-steps.md
@@ -0,0 +1,128 @@
+---
+layout: default
+title: One time steps
+parent:
+ title: Creating and Signing a Distribution
+ url: creating-and-signing-a-distribution
+---
+
+# One time steps
+{:.no_toc}
+
+* Will be replaced with the ToC, excluding a header
+{:toc}
+
+## Keys and configuration
+
+### Create and install a SSH key
+
+> See [OpenSSH Public Key
Authentication](http://sial.org/howto/openssh/publickey-auth/)
+
+If you get hung up during release:perform because Maven can't verify the
authenticity of a host, then there could be
+one of two different problems. The first problem, which is an easy fix, is to
go to the command line and use SSH
+to log in to that host. You should receive a prompt to add the host to your
known_hosts file. If you add the host
+to your `known_hosts` file from the command line SSH, then you should be able
to try `release:perform` again
+and have more success. There is a chance though that this won't fix maven.
+
+Maven doesn't appear to understand hashed `known_hosts` files. There is some
information here - [known_hosts file
Hashing](http://itso.iu.edu/Hashing_the_OpenSSH_known__hosts_File).
+
+If your `known_hosts` file is hashed, you can solve this one of a few
different ways. If you perform a `deploy:deploy`
+instead of `release:perform`, then maven will leave a prompt open for you to
type `yes` and have maven add the host
+(in a way that Jsch, the library which provides Maven Wagon with the SSH/SCP
functionality, understands)
+to your `known_hosts` file. Another option is to remove your `known_hosts`
file, update your SSH configuration so that
+it does not hash the hostname in `known_hosts` and try to log in from the
command line.
+
+```
+mkdir ~/.ssh
+chmod 700 ~/.ssh
+ssh-keygen -q -f ~/.ssh/id_rsa -t rsa
+#Enter a passphrase
+chmod go-rwx ~/.ssh/*
+
+#copy the public key to people.apache.org
+scp ~/.ssh/id_rsa.pub people.apache.org:/home/$USERNAME
+
+# next, setup the public key on server
+ssh people.apache.org
+mkdir ~/.ssh
+chmod 700 ~/.ssh
+cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
+chmod 600 ~/.ssh/authorized_keys
+rm ~/id_rsa.pub
+```
+
+### Create a PGP key
+
+```
+svn co https://svn.apache.org/repos/asf/struts/maven/trunk/build
struts-maven-build
+cd struts-maven-build
+(gpg --fingerprint --list-sigs <your name> && gpg --armor --export <your
name>) >> KEYS
+scp KEYS people.apache.org:/www/www.apache.org/dist/struts
+svn commit KEYS -m "Add public key"
+```
+
+### Update Maven settings for our servers
+
+Create a `settings.xml` under `~/.m2` and follow below instructions:
+- create profile - [Releasing a
Maven-based](http://maven.apache.org/developers/release/apache-release.html\#Prerequisites)
+- enable Apache servers [Committer
Settings](http://maven.apache.org/developers/committer-settings.html)
+
+```xml
+<settings xmlns="http://maven.apache.org/POM/4.0.0";
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd";>
+ <servers>
+ <!-- To publish a snapshot of some part of Maven -->
+ <server>
+ <id>apache.snapshots.https</id>
+ <username> <!-- YOUR APACHE LDAP USERNAME --> </username>
+ <password> <!-- YOUR APACHE LDAP PASSWORD --> </password>
+ </server>
+ <!-- To stage a release of some part of Maven -->
+ <server>
+ <id>apache.releases.https</id>
+ <username> <!-- YOUR APACHE LDAP USERNAME --> </username>
+ <password> <!-- YOUR APACHE LDAP PASSWORD --> </password>
+ </server>
+ </servers>
+ <profiles>
+ <profile>
+ <id>apache-release</id>
+ <properties>
+ <gpg.passphrase> <!-- YOUR KEY PASSPHRASE --> </gpg.passphrase>
+ </properties>
+ </profile>
+ </profiles>
+</settings>
+```
+
+### Increase Memory Settings for Maven
+
+To complete a full build and all the tests, it may be necessary to increase
the amount of memory available to Maven.
+The simplest thing is to set an environment variable.
+
+```
+MAVEN_OPTS=-Xmx512m
+```
+
+or even
+
+```
+MAVEN_OPTS=-Xmx1024m
+```
+
+## Resources
+
+- Apache Struts [Release
Guidelines](http://struts.apache.org/releases.html\#Releases)
+- [Struts Maintenance Guide for Maven
](http://wiki.apache.org/struts/StrutsMaintenanceMaven)
+- [Signing Releases](http://apache.org/dev/release-signing.html)
+- [Wendy's notes on Release
Signing](http://wiki.wsmoak.net/cgi-bin/wiki.pl?ReleaseSigning)
+- Apache [Mirroring Guidelines](http://apache.org/dev/mirrors.html)
+
+## Retagging
+
+If a tagged build needs to be retagged, be sure to delete the old tag first.
+
+```
+git push --delete origin STRUTS_#_#_#
+```
diff --git a/source/contributors/precise-error-reporting.md
b/source/contributors/precise-error-reporting.md
new file mode 100644
index 0000000..f505cc1
--- /dev/null
+++ b/source/contributors/precise-error-reporting.md
@@ -0,0 +1,31 @@
+---
+layout: default
+title: Precise Error Reporting
+parent:
+ title: Contributors Guide
+ url: index.html
+---
+
+# Precise Error Reporting
+{:.no_toc}
+
+* Will be replaced with the ToC, excluding a header
+{:toc}
+
+With the multiple levels of configuration, constant overrides, and bean
selection, it can be confusing as to how
+the framework is configured and how it got there. To assist debugging and
provide the ability to continue to provide
+more line-precise error reporting, the configuration loader remembers the
location of not only XML elements,
+but also Java Properties file properties.
+
+How it works is instead of storing configuration properties in a plain
`java.util.Properties` object, we have a special
+`LocatableProperties` class. This class leverages the location classes to
store location information for the whole
+properties file but also individual properties. We use this to gather
configuration properties during configuration loading.
+This will allow us to display at any given point the location of each property
setting. This capability should be very
+useful when trying to determine what XML or Properties file overwrote what and
when.
+
+Interestingly, in addition to remembering the URI and line number of
Properties properties, the parser we "borrowed"
+from Commons Configuration even gathers preceding comments, which are also
stored in the Location object. This means
+we can leverage the Properties comment-based documentation that we have in the
o.a.s.default.properties file
+or the user's struts.properties file to further provide useful information in
error reports.
+
+There are some very interesting possibilities here to increase the
transparency of the framework in error and debugging conditions.
diff --git a/source/contributors/sample-announcements.md
b/source/contributors/sample-announcements.md
new file mode 100644
index 0000000..8c8511a
--- /dev/null
+++ b/source/contributors/sample-announcements.md
@@ -0,0 +1,196 @@
+---
+layout: default
+title: Sample announcements
+parent:
+ title: Creating and Signing a Distribution
+ url: creating-and-signing-a-distribution
+---
+
+# Sample announcements
+{:.no_toc}
+
+* Will be replaced with the ToC, excluding a header
+{:toc}
+
+## Sample Struts Annotations Release/Quality Vote
+
+```
+Subject: [VOTE] Struts Annotations 1.0.x Vote
+The Struts Annotations 1.0.x test build is now available as a Maven
+artifact. It is a dependency of Struts 2.x.y.
+
+If you have had a chance to review the test build, please respond with
+a vote on its quality:
+
+[ ] Leave at test build
+[ ] Alpha
+[ ] Beta
+[ ] General Availability (GA)
+
+Everyone who has tested the build is invited to vote. Votes by PMC members are
considered binding. A vote passes
+if there are at least three binding +1s and more +1s than -1s.
+
+The vote will remain open for at least 72 hours, longer upon request.
+```
+
+## Sample Test Build Announcement
+
+> Test builds are only announced to the dev list. Announcements to the user
list can only be made pursuant to a release
+> vote with the consent of the PMC.
+
+```
+The test build of Struts 2.0.3 is available.
+
+No determination as to the quality ('alpha,' 'beta,' or 'GA') of Struts 2.0.3
has been made, and at this time it is
+simply a "test build". We welcome any comments you may have, and will take
all feedback into account if a quality vote
+is called for this build.
+
+Release notes:
+* [https://cwiki.apache.org/confluence/display/WW/Version+Notes+#.#.#]
+
+Distribution:
+* [https://dist.apache.org/repos/dist/dev/struts/#.#.#/]
+
+Maven 2 staging repository:
+* [https://repository.apache.org/content/groups/staging/]
+
+We appreciate the time and effort everyone has put toward contributing code
and documentation, posting to the mailing
+lists, and logging issues.
+```
+
+## Sample Release/Quality Vote
+
+```
+Subject: [VOTE] Struts #.#.# Vote
+The Struts #.#.# test build is now available.
+
+Release notes:
+* [https://cwiki.apache.org/confluence/display/WW/Version+Notes+#.#.#]
+
+Distribution:
+* [https://dist.apache.org/repos/dist/dev/struts/#.#.#/]
+
+Maven 2 staging repository:
+* [https://repository.apache.org/content/groups/staging/]
+
+Once you have had a chance to review the test build, please respond with a
vote on its quality:
+
+[ ] Leave at test build
+[ ] Alpha
+[ ] Beta
+[ ] General Availability (GA)
+
+Everyone who has tested the build is invited to vote. Votes by PMC members are
considered binding. A vote passes if
+there are at least three binding +1s and more +1s than -1s.
+
+The vote will remain open for at least 72 hours, longer upon request. A vote
can be amended at any time to upgrade
+or downgrade the quality of the release based on future experience. If an
initial vote designates the build as "Beta",
+the release will be submitted for mirroring and announced to the user list.
Once released as a public beta, subsequent
+quality votes on a build may be held on the user list.
+
+As always, the act of voting carries certain obligations. A binding vote not
only states an opinion, but means that
+the voter is agreeing to help do the work
+```
+
+## Sample Release Announcement
+
+```
+Subject: [ANN] Struts #.#.# [GA | Beta] release available
+
+The Apache Struts group is pleased to announce that Struts #.#.# is available
as a "[Beta | General Availability]"
+release. [[The Beta designation indicates that we believe the distribution
needs wider testing before being upgraded
+to a "General Availability" release. Your input is essential.] The GA
designation is our highest quality grade.]
+
+Apache Struts 2 is an elegant, extensible framework for creating
enterprise-ready Java web applications. The framework
+is designed to streamline the full development cycle, from building, to
deploying, to maintaining applications over time.
+
+[This release includes one important security fix:]
+
+All developers are strongly advised to update existing Struts 2 applications
to Struts #.#.#.
+
+Struts #.#.# is available in a full distribution, or as separate library,
source, example and documentation distributions,
+from the releases page.
+* http://struts.apache.org/download.cgi#struts###
+
+The release is also available from the central Maven repository under Group ID
"org.apache.struts".
+
+The #.#.x series of the Apache Struts framework has a minimum requirement of
the following specification versions:
+* Java Servlet 2.4 and JavaServer Pages (JSP) 2.0
+* Java 2 Standard Platform Edition (J2SE) 7
+
+The release notes are available online at:
+* https://cwiki.apache.org/confluence/display/WW/Version+Notes+#.#.#
+
+Should any issues arise with your use of any version of the Struts framework,
please post your comments to the user list,
+and, if appropriate, file a tracking ticket.appropriate, file a tracking
ticket:
+* https://issues.apache.org/jira/browse/WW
+
+- The Apache Struts group.
+```
+
+## Fast-Tracking an Important Security Release
+
+> When a serious security issue arises, we should try to create a #.#.#.#
branch from the last GA release, and apply
+> to that branch only the security patch.
+
+- If the patch first applies to some other dependency, implore the other group
to do the same, to avoid side-effects
+ from other changes.
+- If the release manager would like to "fast track" a vote, so as to make a
security fix available quickly, the preferred
+ procedure is to
+ - Include the term "fast-track" in the subject, as in `[VOTE] Struts 2.0.9.1
quality (fast track)`
+ - In the vote message, specify voting terms like:
+
+```
+The Struts #.#.#.# test build is now available.
+
+(optional (in case of the presence of security bulletin)
+It includes the latest security patches which fix two possible vulnerabilities:
+* ...
+* ...
+
+For details and the rationale behind these changes, please consult the
+corresponding security bulletins:
+* https://cwiki.apache.org/confluence/display/WW/S2-XXX
+* https://cwiki.apache.org/confluence/display/WW/S2-XXX
+
+Please note that currently these bulletins and the release notes are
+only visible to logged-in users with the struts-committer role. This is
+a needed requirement to control disclosure until the actual release is
+announced.
+(/optional)
+
+Release notes:
+* [https://cwiki.apache.org/confluence/display/WW/Version+Notes+#.#.#.#]
+
+Distribution:
+* [https://dist.apache.org/repos/dist/dev/struts/#.#.#.#/]
+
+Maven 2 staging repository:
+* [https://repository.apache.org/content/groups/staging/]
+
+Once you have had a chance to review the test build, please respond with a
vote on its quality:
+
+[ ] Leave at test build
+[ ] Alpha
+[ ] Beta
+[ ] General Availability (GA)
+
+Everyone who has tested the build is invited to vote. Votes by PMC members are
considered binding. A vote passes
+if there are at least three binding +1s and more +1s than -1s.
+
+This is a "fast-track" release vote. If we have a positive vote after 24 hours
(at least three binding +1s and more +1s
+than -1s), the release may be submitted for mirroring and announced to the
usual channels.
+
+The website download link will include the mirroring timestamp parameter [1],
which limits the selection of mirrors
+to those that have been refreshed since the indicated time and date. (After 24
hours, we *must* remove the timestamp
+parameter from the website link, to avoid unnecessary server load.) In the
case of a fast-track release, the email
+announcement will not link directly to <download.cgi>, but to
<downloads.html>, so that we can control use of the timestamp
+parameter.
+
+[1]
<[http://apache.org/dev/mirrors.html#use|http://apache.org/dev/mirrors.html#use]>
+
+- The Apache Struts group.
+```
+
+Please be sure to update [Security
Bulletins](https://cwiki.apache.org/confluence/display/WW/Security+Bulletins)
accordingly
+as described above.
diff --git a/source/core-developers/index.md b/source/core-developers/index.md
index 6a8c396..fdd2b0c 100644
--- a/source/core-developers/index.md
+++ b/source/core-developers/index.md
@@ -1,6 +1,6 @@
---
layout: default
-title: Core Developers Guide (WIP)
+title: Core Developers Guide
---
# Core Developers Guide
diff --git a/source/updating-website.md b/source/updating-website.md
index d782c79..dc707b9 100644
--- a/source/updating-website.md
+++ b/source/updating-website.md
@@ -25,7 +25,7 @@ We are using Jekyll and mix of Markdown pages with raw Html
pages, where Markdow
The whole build of the website is orchestrated by
[.asf.yaml](http://s.apache.org/asfyaml), please refer to the docs
for more details. The main build of the website is performed by [a buildbot
job](https://ci2.apache.org/#/builders/7),
the staging site is build and deployed by
-[a Jenkins
job](https://builds.apache.org/view/S-Z/view/Struts/job/Struts-staged-site/) -
buildbot doesn't support staging site deployment yet.
+[a Jenkins
job](https://ci-builds.apache.org/job/Struts/job/Struts-staged-site/) -
buildbot doesn't support staging site deployment yet.
## Applying a change
@@ -36,8 +36,8 @@ You can then review your changes before applying them to the
`master` branch.
## Deploying JavaDocs
-There is a dedicated [Jenkins
job](https://builds.apache.org/view/S-Z/view/Struts/job/Struts-site-javadocs/)
which is
+There is a dedicated [Jenkins
job](https://ci-builds.apache.org/job/Struts/job/Struts-site-javadocs/) which is
used to update the JavaDocs based on the latest release. If you have a proper
privileges you can start the job
-and provide a Git tag of the latest release, eg. `STRUTS_2_5_22`. Based on the
tag Jenkins will generate a proper
+and provide a Git tag of the latest release, eg. `STRUTS_2_5_22`. Based on the
tag, Jenkins will generate a proper
JavaDocs and deploy them directly into the website. You can verify them by
using this
[link](https://struts.staged.apache.org/maven/struts2-core/apidocs/index.html).
\ No newline at end of file
