You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by sl...@apache.org on 2023/02/18 20:40:03 UTC
[maven-site] branch master updated (d7db85d3 -> 656d36f2)
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
from d7db85d3 (doc) added snippet types
new f3f37282 Revert "(doc) added snippet types"
new 763c0ed3 Revert "(doc) lint markdown files"
new b0eb56dd Revert "[MNGSITE-509] Fix linking to anchors"
new 55d05632 Revert "[MNGSITE-509] Fix linking in introduction-to-the-lifecycle.md"
new 917e15fd Revert "Refresh - Guide to Developing Java Plugins"
new 591a1fd2 Revert "many plugins released"
new 7d348a3e Revert "reformt"
new be357c6d Revert "fix JIRA link, reformt"
new 7bafdd42 Revert "Maven Reporting Impl 4.0.0-M4 released"
new 03e99ad1 Revert "use directory, not folder"
new 9c5f1ff1 Revert "surefire 3.0.0-M9"
new 10d6f9d9 Revert "[MNGSITE-507] [DOXIA-692] Improve conversion results - part2"
new c61f169d Revert "[MNGSITE-507] [DOXIA-692] Improve conversion results"
new 656d36f2 Revert "[MNGSITE-507] Converted .apt documents to Markdown"
The 14 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
content/apt/archives/maven-2.x/index.apt | 48 +
.../maven-2.x/maven-2.1-architectural-goals.apt} | 75 +-
content/apt/developers/committer-environment.apt | 54 +
content/apt/developers/committer-settings.apt | 81 ++
content/apt/developers/compatibility-plan.apt | 77 ++
content/apt/developers/conventions/code.apt | 246 ++++
content/apt/developers/conventions/git.apt | 228 ++++
content/apt/developers/dependency-policies.apt | 78 ++
content/apt/developers/index.apt | 115 ++
content/apt/developers/release/index.apt | 48 +
.../release/maven-project-release-procedure.apt | 328 ++++++
.../apt/developers/release/parent-pom-release.apt | 101 ++
.../developers/release/pmc-gpg-keys.apt} | 132 ++-
content/apt/developers/retirement-plan-plugins.apt | 166 +++
.../deploy-component-reference-documentation.apt | 165 +++
.../developers/website/deploy-maven-website.apt | 117 ++
content/apt/developers/website/index.apt | 74 ++
.../website/website-overview.apt} | 24 +-
.../developers/website/website-overview.odg | Bin
.../apt/developers/welcome-to-new-committers.apt | 70 ++
.../release-notes.apt.vm => examples/index.apt} | 19 +-
.../examples/injecting-properties-via-settings.apt | 84 ++
.../guides/development/guide-building-maven.apt | 92 ++
.../guides/development/guide-committer-school.apt | 157 +++
.../development/guide-documentation-style.apt | 136 +++
content/apt/guides/development/guide-helping.apt | 106 ++
.../guides/development/guide-maven-development.apt | 197 ++++
.../development/guide-plugin-documentation.apt | 410 +++++++
.../guide-testing-development-plugins.apt | 141 +++
.../guides/development/guide-testing-releases.apt | 153 +++
content/apt/guides/getting-started/index.apt | 1241 ++++++++++++++++++++
.../getting-started/maven-in-five-minutes.apt | 294 +++++
.../getting-started/windows-prerequisites.apt | 66 ++
.../introduction/introduction-to-archetypes.apt | 102 ++
.../introduction-to-dependency-mechanism.apt | 876 ++++++++++++++
...ction-to-optional-and-excludes-dependencies.apt | 320 +++++
.../introduction-to-plugin-prefix-mapping.apt | 167 +++
.../introduction/introduction-to-plugins.apt | 87 ++
.../introduction/introduction-to-profiles.apt | 816 +++++++++++++
.../introduction/introduction-to-repositories.apt | 167 +++
.../introduction/introduction-to-the-lifecycle.apt | 483 ++++++++
.../introduction/introduction-to-the-pom.apt | 577 +++++++++
...troduction-to-the-standard-directory-layout.apt | 86 ++
.../apt/guides/mini/guide-3rd-party-jars-local.apt | 59 +
.../guides/mini/guide-3rd-party-jars-remote.apt | 87 ++
.../guides/mini/guide-archive-configuration.apt | 71 ++
.../guides/mini/guide-assemblies.apt} | 104 +-
.../guides/mini/guide-attached-tests.apt} | 66 +-
.../{index.apt.vm => guide-bash-m2-completion.apt} | 17 +-
.../guide-building-for-different-environments.apt | 161 +++
.../apt/guides/mini/guide-configuring-maven.apt | 171 +++
.../apt/guides/mini/guide-configuring-plugins.apt | 752 ++++++++++++
.../apt/guides/mini/guide-creating-archetypes.apt | 242 ++++
.../guides/mini/guide-default-execution-ids.apt | 218 ++++
.../mini/guide-deployment-security-settings.apt | 66 ++
content/apt/guides/mini/guide-encryption.apt | 258 ++++
.../apt/guides/mini/guide-generating-sources.apt | 77 ++
content/apt/guides/mini/guide-http-settings.apt | 528 +++++++++
.../guide-large-scale-centralized-deployments.apt | 243 ++++
.../mini/{index.apt.vm => guide-manifest.apt} | 24 +-
.../apt/guides/mini/guide-maven-classloading.apt | 154 +++
content/apt/guides/mini/guide-mirror-settings.apt | 178 +++
content/apt/guides/mini/guide-multiple-modules.apt | 88 ++
.../guides/mini/guide-multiple-repositories.apt | 136 +++
.../apt/guides/mini/guide-naming-conventions.apt | 63 +
.../{index.apt.vm => guide-new-committers.apt} | 23 +-
content/apt/guides/mini/guide-proxies.apt | 69 ++
content/apt/guides/mini/guide-releasing.apt | 311 +++++
content/apt/guides/mini/guide-relocation.apt | 151 +++
content/apt/guides/mini/guide-repository-ssl.apt | 155 +++
.../apt/guides/mini/guide-reproducible-builds.apt | 171 +++
content/apt/guides/mini/guide-site.apt | 348 ++++++
content/apt/guides/mini/guide-snippet-macro.apt | 116 ++
.../guides/mini/guide-using-ant.apt} | 57 +-
content/apt/guides/mini/guide-using-extensions.apt | 110 ++
content/apt/guides/mini/guide-using-modello.apt | 90 ++
.../mini/guide-using-one-source-directory.apt | 194 +++
content/apt/guides/mini/guide-using-toolchains.apt | 179 +++
content/apt/guides/mini/guide-wagon-providers.apt | 95 ++
.../plugin/guide-java-plugin-development.apt | 436 +++++++
.../guide-java-report-plugin-development.apt | 539 +++++++++
content/apt/maven-features.apt | 80 ++
content/apt/plugin-developers/common-bugs.apt | 457 +++++++
.../cookbook/index.apt} | 25 +-
.../cookbook/plexus-plugin-upgrade.apt | 189 +++
content/apt/plugin-developers/index.apt | 79 ++
.../plugin-documenting.apt} | 27 +-
content/apt/plugin-developers/plugin-testing.apt | 163 +++
content/apt/plugins/index.apt | 276 +++++
content/apt/plugins/localization.apt | 193 +++
content/apt/repository/central-index.apt | 64 +
content/apt/repository/central-metadata.apt | 58 +
.../repository/guide-central-repository-upload.apt | 190 +++
content/apt/run-maven/index.apt | 106 ++
content/apt/shared/index.apt | 85 ++
content/apt/skins/index.apt | 89 ++
content/apt/users/getting-help.apt | 111 ++
content/apt/users/index.apt | 53 +
content/markdown/aether.md | 2 +-
content/markdown/archives/maven-2.x/index.md | 36 -
content/markdown/background/history-of-maven.md | 4 +-
content/markdown/background/philosophy-of-maven.md | 2 +-
content/markdown/code-quality-management.md | 10 +-
content/markdown/configure.md | 36 +-
.../markdown/developers/committer-environment.md | 44 -
content/markdown/developers/committer-settings.md | 73 --
content/markdown/developers/compatibility-plan.md | 64 -
content/markdown/developers/conventions/code.md | 227 ----
content/markdown/developers/conventions/git.md | 189 ---
content/markdown/developers/conventions/jira.md | 2 +-
content/markdown/developers/dependency-policies.md | 58 -
content/markdown/developers/index.md | 94 --
content/markdown/developers/release/index.md | 39 -
.../developers/release/maven-core-release.md | 7 +-
.../release/maven-project-release-procedure.md | 279 -----
.../developers/release/parent-pom-release.md | 87 --
.../markdown/developers/retirement-plan-plugins.md | 133 ---
.../component-reference-documentation-helper.md | 2 +-
.../deploy-component-reference-documentation.md | 128 --
.../developers/website/deploy-maven-website.md | 90 --
content/markdown/developers/website/index.md | 52 -
.../developers/website/website-overview.md | 33 -
.../developers/welcome-to-new-committers.md | 51 -
content/markdown/docs/3.2.1/release-notes.md | 7 +
content/markdown/docs/3.2.2/release-notes.md | 10 +-
content/markdown/docs/3.2.3/release-notes.md | 8 +
content/markdown/docs/3.2.5/release-notes.md | 4 +
content/markdown/docs/3.3.1/release-notes.md | 81 +-
content/markdown/docs/3.3.3/release-notes.md | 4 +
content/markdown/docs/3.3.9/release-notes.md | 130 +-
.../markdown/docs/3.5.0-alpha-1/release-notes.md | 203 ++--
.../markdown/docs/3.5.0-beta-1/release-notes.md | 77 +-
content/markdown/docs/3.5.0/release-notes.md | 42 +-
content/markdown/docs/3.5.2/release-notes.md | 41 +-
content/markdown/docs/3.5.3/release-notes.md | 6 +-
content/markdown/docs/3.5.4/release-notes.md | 11 +-
content/markdown/docs/3.6.0/release-notes.md | 46 +-
content/markdown/docs/3.6.1/release-notes.md | 187 +--
content/markdown/docs/3.6.2/release-notes.md | 12 +-
content/markdown/docs/3.6.3/release-notes.md | 16 +-
content/markdown/docs/3.8.1/release-notes.md | 35 +-
content/markdown/docs/3.8.2/release-notes.md | 3 +
content/markdown/docs/3.8.3/release-notes.md | 9 +-
content/markdown/docs/3.8.4/release-notes.md | 8 +-
content/markdown/docs/3.8.5/release-notes.md | 5 +-
content/markdown/docs/3.8.6/release-notes.md | 7 +-
content/markdown/docs/3.8.7/release-notes.md | 9 +-
content/markdown/docs/3.9.0/release-notes.md | 51 +-
.../markdown/docs/4.0.0-alpha-2/release-notes.md | 11 +-
.../markdown/docs/4.0.0-alpha-3/release-notes.md | 9 +-
.../markdown/docs/4.0.0-alpha-4/release-notes.md | 13 +-
content/markdown/docs/history.md.vm | 3 +
content/markdown/examples/index.md | 28 -
.../examples/injecting-properties-via-settings.md | 70 --
content/markdown/faq-unoffical.md | 256 ++--
content/markdown/glossary.md | 26 +-
.../guides/development/guide-building-maven.md | 82 --
.../guides/development/guide-committer-school.md | 133 ---
.../development/guide-documentation-style.md | 107 --
.../markdown/guides/development/guide-helping.md | 83 --
.../guides/development/guide-maven-development.md | 135 ---
.../development/guide-plugin-documentation.md | 394 -------
.../guide-testing-development-plugins.md | 124 --
.../guides/development/guide-testing-releases.md | 131 ---
content/markdown/guides/getting-started/index.md | 1063 -----------------
.../getting-started/maven-in-five-minutes.md | 242 ----
.../getting-started/windows-prerequisites.md | 49 -
.../introduction/introduction-to-archetypes.md | 65 -
.../introduction-to-dependency-mechanism.md | 746 ------------
...uction-to-optional-and-excludes-dependencies.md | 237 ----
.../introduction-to-plugin-prefix-mapping.md | 109 --
.../guides/introduction/introduction-to-plugins.md | 50 -
.../introduction/introduction-to-profiles.md | 661 -----------
.../introduction/introduction-to-repositories.md | 120 --
.../introduction/introduction-to-the-lifecycle.md | 330 ------
.../guides/introduction/introduction-to-the-pom.md | 505 --------
...ntroduction-to-the-standard-directory-layout.md | 55 -
.../guides/mini/guide-3rd-party-jars-local.md | 46 -
.../guides/mini/guide-3rd-party-jars-remote.md | 69 --
.../guides/mini/guide-archive-configuration.md | 60 -
.../guides/mini/guide-bash-m2-completion.md | 26 -
.../guide-building-for-different-environments.md | 133 ---
.../guides/mini/guide-configuring-maven.md | 138 ---
.../guides/mini/guide-configuring-plugins.md | 667 -----------
.../guides/mini/guide-creating-archetypes.md | 197 ----
.../guides/mini/guide-default-execution-ids.md | 165 ---
.../mini/guide-deployment-security-settings.md | 56 -
content/markdown/guides/mini/guide-encryption.md | 222 ----
.../guides/mini/guide-generating-sources.md | 56 -
.../markdown/guides/mini/guide-http-settings.md | 465 --------
.../guide-large-scale-centralized-deployments.md | 197 ----
content/markdown/guides/mini/guide-manifest.md | 34 -
.../guides/mini/guide-maven-classloading.md | 125 --
.../markdown/guides/mini/guide-mirror-settings.md | 138 ---
.../guides/mini/guide-multiple-modules-4.md | 2 +
.../markdown/guides/mini/guide-multiple-modules.md | 79 --
.../guides/mini/guide-multiple-repositories.md | 117 --
.../guides/mini/guide-naming-conventions.md | 41 -
.../markdown/guides/mini/guide-new-committers.md | 31 -
content/markdown/guides/mini/guide-proxies.md | 58 -
content/markdown/guides/mini/guide-releasing.md | 251 ----
content/markdown/guides/mini/guide-relocation.md | 99 --
.../markdown/guides/mini/guide-repository-ssl.md | 119 --
.../guides/mini/guide-reproducible-builds.md | 129 --
content/markdown/guides/mini/guide-site.md | 297 -----
.../markdown/guides/mini/guide-snippet-macro.md | 95 --
.../markdown/guides/mini/guide-using-extensions.md | 90 --
.../markdown/guides/mini/guide-using-modello.md | 303 -----
.../mini/guide-using-one-source-directory.md | 165 ---
.../markdown/guides/mini/guide-using-toolchains.md | 139 ---
.../markdown/guides/mini/guide-wagon-providers.md | 73 --
.../guides/plugin/guide-java-plugin-development.md | 393 -------
.../plugin/guide-java-report-plugin-development.md | 466 --------
content/markdown/ide.md | 6 +-
content/markdown/install.md.vm | 2 +-
content/markdown/issue-management.md | 2 +-
content/markdown/maven-1.x-eol.md | 15 +-
content/markdown/maven-2.x-eol.md | 3 +-
content/markdown/maven-ci-friendly.md | 12 +-
content/markdown/maven-conventions.md | 3 +-
content/markdown/maven-features.md | 51 -
content/markdown/maven-jsr330.md | 24 +-
content/markdown/maven-logging.md | 8 +-
content/markdown/plugin-developers/common-bugs.md | 322 -----
.../markdown/plugin-developers/cookbook/index.md | 29 -
.../cookbook/plexus-plugin-upgrade.md | 159 ---
content/markdown/plugin-developers/index.md | 63 -
.../plugin-developers/plugin-documenting.md | 39 -
.../markdown/plugin-developers/plugin-testing.md | 150 ---
content/markdown/plugins/index.md | 159 ---
content/markdown/plugins/localization.md | 129 --
content/markdown/privacy-policy.md | 11 +-
content/markdown/project-roles.md | 94 +-
content/markdown/reference/maven-classloading.md | 7 +-
content/markdown/repositories/artifacts.md | 44 +-
content/markdown/repositories/index.md | 5 +-
content/markdown/repositories/layout.md | 6 +-
content/markdown/repositories/local.md | 12 +-
content/markdown/repositories/metadata.md | 10 +-
content/markdown/repositories/remote.md | 18 +-
content/markdown/repository-management.md | 15 +-
content/markdown/repository/central-index.md | 47 -
content/markdown/repository/central-metadata.md | 39 -
.../repository/guide-central-repository-upload.md | 142 ---
content/markdown/run-maven/index.md | 86 --
content/markdown/run.md | 1 +
content/markdown/security-plexus-archiver.md | 34 +-
content/markdown/security.md | 32 +-
content/markdown/settings.md | 99 +-
content/markdown/shared/index.md | 52 -
content/markdown/skins/index.md | 65 -
content/markdown/support-and-training.md | 15 +-
content/markdown/testimonials.md | 1 +
content/markdown/users/getting-help.md | 72 --
content/markdown/users/index.md | 43 -
content/markdown/what-is-maven.md | 25 +-
256 files changed, 18799 insertions(+), 15740 deletions(-)
create mode 100644 content/apt/archives/maven-2.x/index.apt
rename content/{markdown/archives/maven-2.x/maven-2.1-architectural-goals.md => apt/archives/maven-2.x/maven-2.1-architectural-goals.apt} (87%)
create mode 100644 content/apt/developers/committer-environment.apt
create mode 100644 content/apt/developers/committer-settings.apt
create mode 100644 content/apt/developers/compatibility-plan.apt
create mode 100644 content/apt/developers/conventions/code.apt
create mode 100644 content/apt/developers/conventions/git.apt
create mode 100644 content/apt/developers/dependency-policies.apt
create mode 100644 content/apt/developers/index.apt
create mode 100644 content/apt/developers/release/index.apt
create mode 100644 content/apt/developers/release/maven-project-release-procedure.apt
create mode 100644 content/apt/developers/release/parent-pom-release.apt
rename content/{markdown/developers/release/pmc-gpg-keys.md => apt/developers/release/pmc-gpg-keys.apt} (51%)
create mode 100644 content/apt/developers/retirement-plan-plugins.apt
create mode 100644 content/apt/developers/website/deploy-component-reference-documentation.apt
create mode 100644 content/apt/developers/website/deploy-maven-website.apt
create mode 100644 content/apt/developers/website/index.apt
copy content/apt/{docs/2.0.1/release-notes.apt.vm => developers/website/website-overview.apt} (72%)
rename content/{markdown => apt}/developers/website/website-overview.odg (100%)
create mode 100644 content/apt/developers/welcome-to-new-committers.apt
copy content/apt/{docs/2.0/release-notes.apt.vm => examples/index.apt} (78%)
create mode 100644 content/apt/examples/injecting-properties-via-settings.apt
create mode 100644 content/apt/guides/development/guide-building-maven.apt
create mode 100644 content/apt/guides/development/guide-committer-school.apt
create mode 100644 content/apt/guides/development/guide-documentation-style.apt
create mode 100644 content/apt/guides/development/guide-helping.apt
create mode 100644 content/apt/guides/development/guide-maven-development.apt
create mode 100644 content/apt/guides/development/guide-plugin-documentation.apt
create mode 100644 content/apt/guides/development/guide-testing-development-plugins.apt
create mode 100644 content/apt/guides/development/guide-testing-releases.apt
create mode 100644 content/apt/guides/getting-started/index.apt
create mode 100644 content/apt/guides/getting-started/maven-in-five-minutes.apt
create mode 100644 content/apt/guides/getting-started/windows-prerequisites.apt
create mode 100644 content/apt/guides/introduction/introduction-to-archetypes.apt
create mode 100644 content/apt/guides/introduction/introduction-to-dependency-mechanism.apt
create mode 100644 content/apt/guides/introduction/introduction-to-optional-and-excludes-dependencies.apt
create mode 100644 content/apt/guides/introduction/introduction-to-plugin-prefix-mapping.apt
create mode 100644 content/apt/guides/introduction/introduction-to-plugins.apt
create mode 100644 content/apt/guides/introduction/introduction-to-profiles.apt
create mode 100644 content/apt/guides/introduction/introduction-to-repositories.apt
create mode 100644 content/apt/guides/introduction/introduction-to-the-lifecycle.apt
create mode 100644 content/apt/guides/introduction/introduction-to-the-pom.apt
create mode 100644 content/apt/guides/introduction/introduction-to-the-standard-directory-layout.apt
create mode 100644 content/apt/guides/mini/guide-3rd-party-jars-local.apt
create mode 100644 content/apt/guides/mini/guide-3rd-party-jars-remote.apt
create mode 100644 content/apt/guides/mini/guide-archive-configuration.apt
rename content/{markdown/guides/mini/guide-assemblies.md => apt/guides/mini/guide-assemblies.apt} (66%)
rename content/{markdown/guides/mini/guide-attached-tests.md => apt/guides/mini/guide-attached-tests.apt} (53%)
copy content/apt/guides/mini/{index.apt.vm => guide-bash-m2-completion.apt} (71%)
create mode 100644 content/apt/guides/mini/guide-building-for-different-environments.apt
create mode 100644 content/apt/guides/mini/guide-configuring-maven.apt
create mode 100644 content/apt/guides/mini/guide-configuring-plugins.apt
create mode 100644 content/apt/guides/mini/guide-creating-archetypes.apt
create mode 100644 content/apt/guides/mini/guide-default-execution-ids.apt
create mode 100644 content/apt/guides/mini/guide-deployment-security-settings.apt
create mode 100644 content/apt/guides/mini/guide-encryption.apt
create mode 100644 content/apt/guides/mini/guide-generating-sources.apt
create mode 100644 content/apt/guides/mini/guide-http-settings.apt
create mode 100644 content/apt/guides/mini/guide-large-scale-centralized-deployments.apt
copy content/apt/guides/mini/{index.apt.vm => guide-manifest.apt} (58%)
create mode 100644 content/apt/guides/mini/guide-maven-classloading.apt
create mode 100644 content/apt/guides/mini/guide-mirror-settings.apt
create mode 100644 content/apt/guides/mini/guide-multiple-modules.apt
create mode 100644 content/apt/guides/mini/guide-multiple-repositories.apt
create mode 100644 content/apt/guides/mini/guide-naming-conventions.apt
copy content/apt/guides/mini/{index.apt.vm => guide-new-committers.apt} (55%)
create mode 100644 content/apt/guides/mini/guide-proxies.apt
create mode 100644 content/apt/guides/mini/guide-releasing.apt
create mode 100644 content/apt/guides/mini/guide-relocation.apt
create mode 100644 content/apt/guides/mini/guide-repository-ssl.apt
create mode 100644 content/apt/guides/mini/guide-reproducible-builds.apt
create mode 100644 content/apt/guides/mini/guide-site.apt
create mode 100644 content/apt/guides/mini/guide-snippet-macro.apt
rename content/{markdown/guides/mini/guide-using-ant.md => apt/guides/mini/guide-using-ant.apt} (61%)
create mode 100644 content/apt/guides/mini/guide-using-extensions.apt
create mode 100644 content/apt/guides/mini/guide-using-modello.apt
create mode 100644 content/apt/guides/mini/guide-using-one-source-directory.apt
create mode 100644 content/apt/guides/mini/guide-using-toolchains.apt
create mode 100644 content/apt/guides/mini/guide-wagon-providers.apt
create mode 100644 content/apt/guides/plugin/guide-java-plugin-development.apt
create mode 100644 content/apt/guides/plugin/guide-java-report-plugin-development.apt
create mode 100644 content/apt/maven-features.apt
create mode 100644 content/apt/plugin-developers/common-bugs.apt
copy content/apt/{docs/2.0.1/release-notes.apt.vm => plugin-developers/cookbook/index.apt} (71%)
create mode 100644 content/apt/plugin-developers/cookbook/plexus-plugin-upgrade.apt
create mode 100644 content/apt/plugin-developers/index.apt
copy content/apt/{docs/2.0.1/release-notes.apt.vm => plugin-developers/plugin-documenting.apt} (57%)
create mode 100644 content/apt/plugin-developers/plugin-testing.apt
create mode 100644 content/apt/plugins/index.apt
create mode 100644 content/apt/plugins/localization.apt
create mode 100644 content/apt/repository/central-index.apt
create mode 100644 content/apt/repository/central-metadata.apt
create mode 100644 content/apt/repository/guide-central-repository-upload.apt
create mode 100644 content/apt/run-maven/index.apt
create mode 100644 content/apt/shared/index.apt
create mode 100644 content/apt/skins/index.apt
create mode 100644 content/apt/users/getting-help.apt
create mode 100644 content/apt/users/index.apt
delete mode 100644 content/markdown/archives/maven-2.x/index.md
delete mode 100644 content/markdown/developers/committer-environment.md
delete mode 100644 content/markdown/developers/committer-settings.md
delete mode 100644 content/markdown/developers/compatibility-plan.md
delete mode 100644 content/markdown/developers/conventions/code.md
delete mode 100644 content/markdown/developers/conventions/git.md
delete mode 100644 content/markdown/developers/dependency-policies.md
delete mode 100644 content/markdown/developers/index.md
delete mode 100644 content/markdown/developers/release/index.md
delete mode 100644 content/markdown/developers/release/maven-project-release-procedure.md
delete mode 100644 content/markdown/developers/release/parent-pom-release.md
delete mode 100644 content/markdown/developers/retirement-plan-plugins.md
delete mode 100644 content/markdown/developers/website/deploy-component-reference-documentation.md
delete mode 100644 content/markdown/developers/website/deploy-maven-website.md
delete mode 100644 content/markdown/developers/website/index.md
delete mode 100644 content/markdown/developers/website/website-overview.md
delete mode 100644 content/markdown/developers/welcome-to-new-committers.md
delete mode 100644 content/markdown/examples/index.md
delete mode 100644 content/markdown/examples/injecting-properties-via-settings.md
delete mode 100644 content/markdown/guides/development/guide-building-maven.md
delete mode 100644 content/markdown/guides/development/guide-committer-school.md
delete mode 100644 content/markdown/guides/development/guide-documentation-style.md
delete mode 100644 content/markdown/guides/development/guide-helping.md
delete mode 100644 content/markdown/guides/development/guide-maven-development.md
delete mode 100644 content/markdown/guides/development/guide-plugin-documentation.md
delete mode 100644 content/markdown/guides/development/guide-testing-development-plugins.md
delete mode 100644 content/markdown/guides/development/guide-testing-releases.md
delete mode 100644 content/markdown/guides/getting-started/index.md
delete mode 100644 content/markdown/guides/getting-started/maven-in-five-minutes.md
delete mode 100644 content/markdown/guides/getting-started/windows-prerequisites.md
delete mode 100644 content/markdown/guides/introduction/introduction-to-archetypes.md
delete mode 100644 content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
delete mode 100644 content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md
delete mode 100644 content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
delete mode 100644 content/markdown/guides/introduction/introduction-to-plugins.md
delete mode 100644 content/markdown/guides/introduction/introduction-to-profiles.md
delete mode 100644 content/markdown/guides/introduction/introduction-to-repositories.md
delete mode 100644 content/markdown/guides/introduction/introduction-to-the-lifecycle.md
delete mode 100644 content/markdown/guides/introduction/introduction-to-the-pom.md
delete mode 100644 content/markdown/guides/introduction/introduction-to-the-standard-directory-layout.md
delete mode 100644 content/markdown/guides/mini/guide-3rd-party-jars-local.md
delete mode 100644 content/markdown/guides/mini/guide-3rd-party-jars-remote.md
delete mode 100644 content/markdown/guides/mini/guide-archive-configuration.md
delete mode 100644 content/markdown/guides/mini/guide-bash-m2-completion.md
delete mode 100644 content/markdown/guides/mini/guide-building-for-different-environments.md
delete mode 100644 content/markdown/guides/mini/guide-configuring-maven.md
delete mode 100644 content/markdown/guides/mini/guide-configuring-plugins.md
delete mode 100644 content/markdown/guides/mini/guide-creating-archetypes.md
delete mode 100644 content/markdown/guides/mini/guide-default-execution-ids.md
delete mode 100644 content/markdown/guides/mini/guide-deployment-security-settings.md
delete mode 100644 content/markdown/guides/mini/guide-encryption.md
delete mode 100644 content/markdown/guides/mini/guide-generating-sources.md
delete mode 100644 content/markdown/guides/mini/guide-http-settings.md
delete mode 100644 content/markdown/guides/mini/guide-large-scale-centralized-deployments.md
delete mode 100644 content/markdown/guides/mini/guide-manifest.md
delete mode 100644 content/markdown/guides/mini/guide-maven-classloading.md
delete mode 100644 content/markdown/guides/mini/guide-mirror-settings.md
delete mode 100644 content/markdown/guides/mini/guide-multiple-modules.md
delete mode 100644 content/markdown/guides/mini/guide-multiple-repositories.md
delete mode 100644 content/markdown/guides/mini/guide-naming-conventions.md
delete mode 100644 content/markdown/guides/mini/guide-new-committers.md
delete mode 100644 content/markdown/guides/mini/guide-proxies.md
delete mode 100644 content/markdown/guides/mini/guide-releasing.md
delete mode 100644 content/markdown/guides/mini/guide-relocation.md
delete mode 100644 content/markdown/guides/mini/guide-repository-ssl.md
delete mode 100644 content/markdown/guides/mini/guide-reproducible-builds.md
delete mode 100644 content/markdown/guides/mini/guide-site.md
delete mode 100644 content/markdown/guides/mini/guide-snippet-macro.md
delete mode 100644 content/markdown/guides/mini/guide-using-extensions.md
delete mode 100644 content/markdown/guides/mini/guide-using-modello.md
delete mode 100644 content/markdown/guides/mini/guide-using-one-source-directory.md
delete mode 100644 content/markdown/guides/mini/guide-using-toolchains.md
delete mode 100644 content/markdown/guides/mini/guide-wagon-providers.md
delete mode 100644 content/markdown/guides/plugin/guide-java-plugin-development.md
delete mode 100644 content/markdown/guides/plugin/guide-java-report-plugin-development.md
delete mode 100644 content/markdown/maven-features.md
delete mode 100644 content/markdown/plugin-developers/common-bugs.md
delete mode 100644 content/markdown/plugin-developers/cookbook/index.md
delete mode 100644 content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
delete mode 100644 content/markdown/plugin-developers/index.md
delete mode 100644 content/markdown/plugin-developers/plugin-documenting.md
delete mode 100644 content/markdown/plugin-developers/plugin-testing.md
delete mode 100644 content/markdown/plugins/index.md
delete mode 100644 content/markdown/plugins/localization.md
delete mode 100644 content/markdown/repository/central-index.md
delete mode 100644 content/markdown/repository/central-metadata.md
delete mode 100644 content/markdown/repository/guide-central-repository-upload.md
delete mode 100644 content/markdown/run-maven/index.md
delete mode 100644 content/markdown/shared/index.md
delete mode 100644 content/markdown/skins/index.md
delete mode 100644 content/markdown/users/getting-help.md
delete mode 100644 content/markdown/users/index.md
[maven-site] 04/14: Revert "[MNGSITE-509] Fix linking in introduction-to-the-lifecycle.md"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit 55d05632f1f0c4c85522f88bf81954fbe1c4ef93
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:31:25 2023 +0100
Revert "[MNGSITE-509] Fix linking in introduction-to-the-lifecycle.md"
This reverts commit 39ed8b5871e5659ffeb563d18e943ab98d48209e.
---
.../guides/introduction/introduction-to-the-lifecycle.md | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/content/markdown/guides/introduction/introduction-to-the-lifecycle.md b/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
index 17bb85b0..5e495e11 100644
--- a/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
+++ b/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
@@ -28,17 +28,19 @@ under the License.
- - [Build Lifecycle Basics](#build-lifecycle-basics)
+ - [Build Lifecycle Basics](Build_Lifecycle_Basics)
+
+ - [Setting Up Your Project to Use the Build Lifecycle](Setting_Up_Your_Project_to_Use_the_Build_Lifecycle)
+
+ - [Packaging](Packaging)
+
+ - [Plugins](Plugins)
- - [Setting Up Your Project to Use the Build Lifecycle](#setting-up-your-project-to-use-the-build-lifecycle)
- - [Packaging](#packaging)
-
- - [Plugins](#plugins)
- [Lifecycle Reference](Lifecycle_Reference)
- - [Built-in Lifecycle Bindings](#built-in-lifecycle-bindings)
+ - [Built-in Lifecycle Bindings](Built-in_Lifecycle_Bindings)
[maven-site] 13/14: Revert "[MNGSITE-507] [DOXIA-692] Improve conversion results"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit c61f169da8c9f947518ebd810975f8af9ea46e23
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:35:07 2023 +0100
Revert "[MNGSITE-507] [DOXIA-692] Improve conversion results"
This reverts commit 45492f24ab507b20750769901c777ea00979c4a5.
---
.../maven-2.x/maven-2.1-architectural-goals.md | 2 +-
content/markdown/developers/compatibility-plan.md | 6 +-
content/markdown/developers/conventions/code.md | 16 ++---
content/markdown/developers/conventions/git.md | 2 +-
content/markdown/developers/dependency-policies.md | 2 +-
content/markdown/developers/index.md | 2 +-
.../release/maven-project-release-procedure.md | 18 +++---
.../markdown/developers/release/pmc-gpg-keys.md | 2 +-
.../markdown/developers/retirement-plan-plugins.md | 6 +-
.../deploy-component-reference-documentation.md | 4 +-
content/markdown/faq-unoffical.md | 2 +-
.../guides/development/guide-committer-school.md | 14 ++---
.../development/guide-documentation-style.md | 4 +-
.../guides/development/guide-maven-development.md | 2 +-
.../development/guide-plugin-documentation.md | 32 +++++-----
.../guide-testing-development-plugins.md | 2 +-
.../guides/development/guide-testing-releases.md | 24 ++++----
content/markdown/guides/getting-started/index.md | 12 ++--
.../introduction-to-dependency-mechanism.md | 4 +-
...uction-to-optional-and-excludes-dependencies.md | 6 +-
.../guides/introduction/introduction-to-plugins.md | 2 +-
.../introduction/introduction-to-profiles.md | 72 +++++++++++-----------
.../introduction/introduction-to-the-lifecycle.md | 10 +--
.../guides/introduction/introduction-to-the-pom.md | 6 +-
.../guides/mini/guide-configuring-maven.md | 10 +--
.../guides/mini/guide-configuring-plugins.md | 64 +++++++++----------
.../guides/mini/guide-creating-archetypes.md | 6 +-
.../guides/mini/guide-default-execution-ids.md | 2 +-
.../markdown/guides/mini/guide-http-settings.md | 18 +++---
.../guide-large-scale-centralized-deployments.md | 8 +--
.../guides/mini/guide-maven-classloading.md | 4 +-
.../markdown/guides/mini/guide-mirror-settings.md | 16 ++---
.../markdown/guides/mini/guide-multiple-modules.md | 2 +-
content/markdown/guides/mini/guide-proxies.md | 2 +-
content/markdown/guides/mini/guide-releasing.md | 2 +-
content/markdown/guides/mini/guide-relocation.md | 4 +-
.../guides/mini/guide-reproducible-builds.md | 6 +-
content/markdown/guides/mini/guide-site.md | 10 +--
.../markdown/guides/mini/guide-using-extensions.md | 2 +-
.../markdown/guides/mini/guide-using-toolchains.md | 4 +-
.../markdown/guides/mini/guide-wagon-providers.md | 10 +--
.../guides/plugin/guide-java-plugin-development.md | 4 +-
.../plugin/guide-java-report-plugin-development.md | 4 +-
content/markdown/maven-jsr330.md | 16 ++---
content/markdown/maven-logging.md | 2 +-
content/markdown/plugin-developers/common-bugs.md | 14 ++---
.../cookbook/plexus-plugin-upgrade.md | 2 +-
.../plugin-developers/plugin-documenting.md | 2 +-
.../markdown/plugin-developers/plugin-testing.md | 4 +-
content/markdown/plugins/index.md | 4 +-
content/markdown/plugins/localization.md | 8 +--
content/markdown/repository/central-index.md | 2 +-
content/markdown/settings.md | 2 +-
53 files changed, 243 insertions(+), 243 deletions(-)
diff --git a/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md b/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md
index 7c73f05e..0f0bba15 100644
--- a/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md
+++ b/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md
@@ -71,7 +71,7 @@ About this specific issue (MNG-3012): The best solution is to only share java.,
There's one more solution to consider; using ASM to rewrite plugins as they're loaded. We could add code modifiers that workaround incompatibilities by detecting usage patterns, like (Xpp3Dom) plugin.getConfiguration(). An example could be to modify the code to wrap Xpp3DomParser.parse( new StringReader( String.valueOf( /plugin.getConfiguration()/ ) ) ) around the call. This is even more of a hack though. Perhaps a mojo that scans for plugin incompatibilities using ASM is more feasible [...]
-So the basic problem we're up against is that there can be core api changes between major versions that pose incompatibilities for plugins written against an older version. The simplest solution would be to let plugins specify the maven versions they work against (which is partly present: `<requires><mavenVersion>2.0.6</mavenVersion></requires>`. If this field supports a versionrange, or we'd default the version interpretation above to mean [2.0.6,2.1), we can detect plugins that won't r [...]
+So the basic problem we're up against is that there can be core api changes between major versions that pose incompatibilities for plugins written against an older version. The simplest solution would be to let plugins specify the maven versions they work against (which is partly present: <requires><mavenVersion>2.0.6</mavenVersion></requires>. If this field supports a versionrange, or we'd default the version interpretation above to mean [2.0.6,2.1), we can detect plugins that won't run [...]
h3. Strategies for ensuring backward compatibility
diff --git a/content/markdown/developers/compatibility-plan.md b/content/markdown/developers/compatibility-plan.md
index 37d42df5..61d372f1 100644
--- a/content/markdown/developers/compatibility-plan.md
+++ b/content/markdown/developers/compatibility-plan.md
@@ -47,11 +47,11 @@ under the License.
- - Until 2012, Maven 2.2.1 + Java 5 prerequisites, with plugins versions in 2.x
+ - Until 2012, Maven 2.2.1 \+ Java 5 prerequisites, with plugins versions in 2.x
- - Since 2012, Maven 3.0 + Java 7 prerequisites, with plugins in 3.x.y
+ - Since 2012, Maven 3.0 \+ Java 7 prerequisites, with plugins in 3.x.y
- - Since June 2020, Maven Plugin API used by plugins >= 3.1.0 + Java 8 prerequisites [Technical details](https://s.apache.org/MVN-PLUGIN-MIGRATION-3.1)
+ - Since June 2020, Maven Plugin API used by plugins \>\= 3.1.0 \+ Java 8 prerequisites [Technical details](https://s.apache.org/MVN-PLUGIN-MIGRATION-3.1)
diff --git a/content/markdown/developers/conventions/code.md b/content/markdown/developers/conventions/code.md
index 0e2a3ec6..729dd2d7 100644
--- a/content/markdown/developers/conventions/code.md
+++ b/content/markdown/developers/conventions/code.md
@@ -27,7 +27,7 @@ under the License.
As the formatting is automatically enforced or even applied with [spotless-maven-plugin](https://github.com/diffplug/spotless/tree/main/plugin-maven) for all projects using [Maven Project Parent POM 38 or newer](/pom/maven/index.html) developers usually don't need to care and the following sections are just for informational purposes.
- Optionally you can still import the code style formatter for your IDE from [shared-resources](https://gitbox.apache.org/repos/asf?p=maven-shared-resources.git;a=tree;f=src/main/resources/config;hb=HEAD)
+ Optionally you can still import the code style formatter for your IDE from [shared-resources](https://gitbox.apache.org/repos/asf?p\=maven-shared-resources.git;a\=tree;f\=src/main/resources/config;hb\=HEAD)
- [Generic Code Style And Convention](Generic_Code_Style_And_Convention)
@@ -134,7 +134,7 @@ under the License.
all imports in each group should be sorted alphabetically.
- To ensure a package import order consistent with the layout described above, download `[maven-eclipse-importorder.txt](https://gitbox.apache.org/repos/asf?p=maven-shared-resources.git;a=blob_plain;f=src/main/resources/config/maven-eclipse-importorder.txt;hb=HEAD)`, select _Window \> Preferences_ and navigate to _Java \> Code Style \> Organize Imports_. Click on _Import..._ and select the downloaded file to change the import order.
+ To ensure a package import order consistent with the layout described above, download `[maven-eclipse-importorder.txt](https://gitbox.apache.org/repos/asf?p\=maven-shared-resources.git;a\=blob_plain;f\=src/main/resources/config/maven-eclipse-importorder.txt;hb\=HEAD)`, select _Window \> Preferences_ and navigate to _Java \> Code Style \> Organize Imports_. Click on _Import..._ and select the downloaded file to change the import order.
@@ -262,11 +262,11 @@ under the License.
- 1 The `<project>` element is always on one line.
+ 1 The \<project/\> element is always on one line.
- 1 The blocks are voluntary separated by a new line to improve the readiness.
+ 1 The blocks are voluntary separated by a new line to improve the readingness.
- 1 The dependencies in `<dependencies>` and `<dependencyManagement>` tags have no specific ordering. Developers are free to choose the ordering, but grouping dependencies by topics (like groupId i.e. `org.apache.maven`) is a good practice.
+ 1 The dependencies in \<dependencies/\> and \<dependencyManagement/\> tags have no specific ordering. Developers are free to choose the ordering, but grouping dependencies by topics (like groupId i.e. `org.apache.maven`) is a good practice.
@@ -277,9 +277,9 @@ under the License.
- - **Metadata**: Always specify metadata in the `<properties>` tag.
+ - **Metadata**: Always specify metadata in the \<properties/\> tag.
- - **Sections**: Always use a new line with indentation for `<section>` tags.
+ - **Sections**: Always use a new line with indentation for \<section/\> tags.
@@ -290,7 +290,7 @@ under the License.
- - **FAQ**: Always use a new line with indentation for `<faq>` tags.
+ - **FAQ**: Always use a new line with indentation for \<faq/\> tags.
<!-- * {APT} Do we need any specific APT style/convention? -->
diff --git a/content/markdown/developers/conventions/git.md b/content/markdown/developers/conventions/git.md
index de40447b..c12e309a 100644
--- a/content/markdown/developers/conventions/git.md
+++ b/content/markdown/developers/conventions/git.md
@@ -33,7 +33,7 @@ under the License.
#### For contributors who are not committers
- Apache git repositories are at _git://git.apache.org_. However, the ASF uses clones on github.com to make it easier for people to contribute changes via pull requests.
+ Apache git repositories are at _ \<\<git://git.apache.org_\>\>. However, the ASF uses clones on github.com to make it easier for people to contribute changes via pull requests.
To contribute to a Maven component that is maintained in git, please follow these steps:
diff --git a/content/markdown/developers/dependency-policies.md b/content/markdown/developers/dependency-policies.md
index 064a45ff..270982d1 100644
--- a/content/markdown/developers/dependency-policies.md
+++ b/content/markdown/developers/dependency-policies.md
@@ -30,7 +30,7 @@ under the License.
This page describes the policies around the use of dependencies by the Apache Maven Developers in the process of developing Apache Maven itself.
- This page does not apply to projects hosted outside of the Apache Maven project. In order to remove all doubt, this page only applies to code which has a Github URL that starts with `https://github.com/apache/maven` or a Gitbox URL starting with `https://gitbox.apache.org/repos/asf?p=maven`
+ This page does not apply to projects hosted outside of the Apache Maven project. In order to remove all doubt, this page only applies to code which has a Github URL that starts with `https://github.com/apache/maven` or a Gitbox URL starting with `https://gitbox.apache.org/repos/asf?p\=maven`
If you have stumbled across this page and you are working on code that does not have a Github URL starting with `https://github.com/apache/maven` then this page does not apply to you.
diff --git a/content/markdown/developers/index.md b/content/markdown/developers/index.md
index 32526fe3..d90d75b7 100644
--- a/content/markdown/developers/index.md
+++ b/content/markdown/developers/index.md
@@ -69,7 +69,7 @@ under the License.
- [Maven Plugins and Components Compatibility Plan](./compatibility-plan.html)
- - [Maven Proposals/Backlog](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567)
+ - [Maven Proposals/Backlog](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId\=5964567)
diff --git a/content/markdown/developers/release/maven-project-release-procedure.md b/content/markdown/developers/release/maven-project-release-procedure.md
index 8709bbc2..0e66306a 100644
--- a/content/markdown/developers/release/maven-project-release-procedure.md
+++ b/content/markdown/developers/release/maven-project-release-procedure.md
@@ -35,11 +35,11 @@ under the License.
- you have a recent Git client installed and on your shell's path.
- - you have JDK 8 installed and on your shell's path to build Maven 3.7.0+. Details about minimum JDK version to build an appropriate version can be found here: [https://maven.apache.org/docs/history.html](/docs/history.html)
+ - you have JDK 8 installed and on your shell's path to build Maven 3.7.0\+. Details about minimum JDK version to build an appropriate version can be found here: [https://maven.apache.org/docs/history.html](/docs/history.html)
- - if you receive an OutOfMemoryError during the build, make sure to have set the environment variable `MAVEN_OPTS=-Xmx512m`
+ - if you receive an OutOfMemoryError during the build, make sure to have set the environment variable `MAVEN_OPTS\=-Xmx512m`
- - you must use Maven 3.3.9+.
+ - you must use Maven 3.3.9\+.
- follow Apache environment configuration steps outlined at: [Publishing Maven Artifacts](https://www.apache.org/dev/publishing-maven-artifacts.html#dev-env).
@@ -133,7 +133,7 @@ Vote open for at least 72 hours.
To get the list of issues left in JIRA, browse to the plugin's or component's JIRA page, and from the _Preset Filters_ on the right, use the link for _Outstanding_ issues.
- The vote is open for at least 72 hours means, that you need to wait at least 72 hours before proceeding. This gives others time to test your release and check that everything is good. If you have received after that not enough +1 votes to reach the quorum, this doesn't mean, the vote failed. It just takes a bit longer.
+ The vote is open for at least 72 hours means, that you need to wait at least 72 hours before proceeding. This gives others time to test your release and check that everything is good. If you have received after that not enough \+1 votes to reach the quorum, this doesn't mean, the vote failed. It just takes a bit longer.
@@ -209,18 +209,18 @@ The vote has been canceled.
- drop your staging repository as described in [Drop a repository](https://www.apache.org/dev/publishing-maven-artifacts.html)
- - create new version for next round `Y.Z+1`
+ - create new version for next round `Y.Z\+1`
- - assign issues from version `Y.Z` also to version `Y.Z+1`
+ - assign issues from version `Y.Z` also to version `Y.Z\+1`
- mark the `Y.Z` version as **archived**
- - report found issues and assign them to version `Y.Z+1`
+ - report found issues and assign them to version `Y.Z\+1`
- fix found issues
- Start the process for version `Y.Z+1` from the beginning.
+ Start the process for version `Y.Z\+1` from the beginning.
@@ -287,7 +287,7 @@ wagon/wagon-2.2-source-release.zip.sha512
1 Update the version tracking in JIRA
- In the relevant project, go to Administration, then Versions. Mark the `Y.Z` version as 'released'. Create version `Y.Z+1`, if that hasn't already been done. You may also archive any deprecated releases (milestones or alphas) at this time.
+ In the relevant project, go to Administration, then Versions. Mark the `Y.Z` version as 'released'. Create version `Y.Z\+1`, if that hasn't already been done. You may also archive any deprecated releases (milestones or alphas) at this time.
diff --git a/content/markdown/developers/release/pmc-gpg-keys.md b/content/markdown/developers/release/pmc-gpg-keys.md
index a235cdf2..4d7d3351 100644
--- a/content/markdown/developers/release/pmc-gpg-keys.md
+++ b/content/markdown/developers/release/pmc-gpg-keys.md
@@ -129,7 +129,7 @@ sig 07DDB702 2006-10-10 Vincent Siveton <vs...@apache.org>
-## mQGiBEUrnAsRBACQDiYGc1IQmkENLO9iznBg8otGPEbzqQozT5tsip5mB30f6Mc/ uuLxJkLdna7Ul3goIXDtCeLJq38gHvruNtVNR6S+juJFkd5sLEH8UJ18PbKuo/9I KGlzjtCYUUDC48czRr0efhqd54NH8ydNdpaZ76NGPPYfpXtk7kKgH/nPiwCgxozK IG2frMuWIvdFafbqdAl7y/sD/1Csf0r9jtHEeXOuyhm8jCGrSwzLbHUGKPUQP37P ajECHoWp6HnvHEEEpgVl+UjfZvrcVhzUoP+3r5HAugqERfkzK8AWc7qjIRjf64kU sjvto31G2KYz17Y8K9y4LkRkUspu8uw903pKnW/QELg4vvPVaEYpVVIdS6+cUreu V0hOA/4tW7T/GpzSbQmjvnIRQ7GVHbQeXsANwrS6NmGYIxafN9P9dfHV+eUieTu6 rvMP9coOhTYyEKZksrXw2MmXx5SzgxsXT0 [...]
+## mQGiBEUrnAsRBACQDiYGc1IQmkENLO9iznBg8otGPEbzqQozT5tsip5mB30f6Mc/ uuLxJkLdna7Ul3goIXDtCeLJq38gHvruNtVNR6S\+juJFkd5sLEH8UJ18PbKuo/9I KGlzjtCYUUDC48czRr0efhqd54NH8ydNdpaZ76NGPPYfpXtk7kKgH/nPiwCgxozK IG2frMuWIvdFafbqdAl7y/sD/1Csf0r9jtHEeXOuyhm8jCGrSwzLbHUGKPUQP37P ajECHoWp6HnvHEEEpgVl\+UjfZvrcVhzUoP\+3r5HAugqERfkzK8AWc7qjIRjf64kU sjvto31G2KYz17Y8K9y4LkRkUspu8uw903pKnW/QELg4vvPVaEYpVVIdS6\+cUreu V0hOA/4tW7T/GpzSbQmjvnIRQ7GVHbQeXsANwrS6NmGYIxafN9P9dfHV\+eUieTu6 rvMP9coOhTYyEKZksrXw2MmXx5Szg [...]
You need to append this result to [https://svn.apache.org/repos/asf/maven/project/KEYS](https://svn.apache.org/repos/asf/maven/project/KEYS).
diff --git a/content/markdown/developers/retirement-plan-plugins.md b/content/markdown/developers/retirement-plan-plugins.md
index 77bbec25..c0cdd1b0 100644
--- a/content/markdown/developers/retirement-plan-plugins.md
+++ b/content/markdown/developers/retirement-plan-plugins.md
@@ -118,13 +118,13 @@ but has moved to the <Organization> <Project> project.
```
- 1 Add " (RETIRED)" at the end of `<project> <name>` in the plugin's `pom.xml`. This will show up on every page of the generated site.
+ 1 Add " (RETIRED)" at the end of `\<project\>`/`\<name\>` in the plugin's `pom.xml`. This will show up on every page of the generated site.
1 Go ahead with [the standard release process](./release/maven-project-release-procedure.html), making sure that you follow the exceptions mentioned above regarding the site deployment.
1 When updating the plugins page, move Maven Foo Plugin to under the "Retired" heading. Remove the SVN and JIRA links and add the date of retirement.
- 1 When updating the version in JIRA, do not add Y.Z+1 and make sure you remove any future versions.
+ 1 When updating the version in JIRA, do not add Y.Z\+1 and make sure you remove any future versions.
@@ -134,7 +134,7 @@ but has moved to the <Organization> <Project> project.
1 Remove the `.Jenkinsfile` from all branches. This will remove the project from https://builds.apache.org/job/maven-box/
- 1 Ask INFRA for archive git repos (gitbox + github)
+ 1 Ask INFRA for archive git repos (gitbox \+ github)
1 Republish documentation, postfix project name with (RETIRED)
diff --git a/content/markdown/developers/website/deploy-component-reference-documentation.md b/content/markdown/developers/website/deploy-component-reference-documentation.md
index 91c20a34..bd735ded 100644
--- a/content/markdown/developers/website/deploy-component-reference-documentation.md
+++ b/content/markdown/developers/website/deploy-component-reference-documentation.md
@@ -27,7 +27,7 @@ under the License.
This document gives step-by-step instructions for deploying Maven components reference documentation inside the Maven [https://maven.apache.org/](/) website.
- See [Maven website introduction](./index.html) for instructions on the whole website publication (main site content + components).
+ See [Maven website introduction](./index.html) for instructions on the whole website publication (main site content \+ components).
@@ -95,7 +95,7 @@ mvn scm-publish:publish-scm
- **Notice**: content is in fact published to [/components/](/components/) directory, and symbolic links declared in `resources/\*\*/components.links` in main site source are used by Ant to create a reference from `/xxx` (= what we want to be user-visible) to `/components/xxx` (what what is checked out).
+ **Notice**: content is in fact published to [/components/](/components/) directory, and symbolic links declared in `resources/\*\*/components.links` in main site source are used by Ant to create a reference from `/xxx` (\= what we want to be user-visible) to `/components/xxx` (what what is checked out).
diff --git a/content/markdown/faq-unoffical.md b/content/markdown/faq-unoffical.md
index b4d3f0bd..2ca5e6a5 100644
--- a/content/markdown/faq-unoffical.md
+++ b/content/markdown/faq-unoffical.md
@@ -1880,7 +1880,7 @@ To store stuff that is not in ibiblio. An example of this is your own stuff.
### Whenever a file is modified in a maven project how is the SNAPSHOT jar updated in the remote repository?
-Using mvn deploy, after inserting proper `<distributionManagement>` section into your POM
+Using mvn deploy, after inserting proper <distributionManagement/> section into your POM
### Is maven 'deploy' goal and actually copying of a dependency or artifact jar to remote repository same?
diff --git a/content/markdown/guides/development/guide-committer-school.md b/content/markdown/guides/development/guide-committer-school.md
index 507f92dd..b7cc4072 100644
--- a/content/markdown/guides/development/guide-committer-school.md
+++ b/content/markdown/guides/development/guide-committer-school.md
@@ -70,19 +70,19 @@ password
- 1 I look at the actual diff, if there is a whole lot of formatting changes irrelevant to the issue being fixed => **Patch is no good, ask on JIRA for a clean patch**
+ 1 I look at the actual diff, if there is a whole lot of formatting changes irrelevant to the issue being fixed \=\> **Patch is no good, ask on JIRA for a clean patch**
- 1 I look at the list of files in the diff, if there are no tests => **Patch is no good, ask on JIRA for test cases**
+ 1 I look at the list of files in the diff, if there are no tests \=\> **Patch is no good, ask on JIRA for test cases**
- 1 I look at the issue and if the issue requires documentation be updated and there is no documentation changes in the patch => **Patch is no good, ask on JIRA for documentation changes in the patch**
+ 1 I look at the issue and if the issue requires documentation be updated and there is no documentation changes in the patch \=\> **Patch is no good, ask on JIRA for documentation changes in the patch**
- 1 I take a clean checkout of the source that the patch applies to and try to apply the patch... if it does not apply clean => **Patch is no good, ask on JIRA for an updated patch**
+ 1 I take a clean checkout of the source that the patch applies to and try to apply the patch... if it does not apply clean \=\> **Patch is no good, ask on JIRA for an updated patch**
- 1 I revert the src/main and run the tests. If the tests all pass, then there are no test cases to catch the bug => **Patch is no good, ask on JIRA for proper tests**
+ 1 I revert the src/main and run the tests. If the tests all pass, then there are no test cases to catch the bug \=\> **Patch is no good, ask on JIRA for proper tests**
- 1 I revert src and run the tests. If any tests fail, then there is something wrong with the existing code => **If I have time I might try and fix the issue, otherwise I just move on**
+ 1 I revert src and run the tests. If any tests fail, then there is something wrong with the existing code \=\> **If I have time I might try and fix the issue, otherwise I just move on**
- 1 I apply the patch a second time and run the tests. If the tests all pass => **Patch is good, I commit the patch and mark the JIRA as resolved**
+ 1 I apply the patch a second time and run the tests. If the tests all pass \=\> **Patch is good, I commit the patch and mark the JIRA as resolved**
So there you have it, my guide to writing good patches... now the next step is getting your patches noticed...
diff --git a/content/markdown/guides/development/guide-documentation-style.md b/content/markdown/guides/development/guide-documentation-style.md
index 8d83b9b6..0b3deb72 100644
--- a/content/markdown/guides/development/guide-documentation-style.md
+++ b/content/markdown/guides/development/guide-documentation-style.md
@@ -69,7 +69,7 @@ under the License.
- [W3C Quality Web Tips](http://www.w3.org/QA/Tips/iso-date)
- - [ISO-8601](http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26780)
+ - [ISO-8601](http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber\=26780)
- [Wikipedia](http://en.wikipedia.org/wiki/ISO_8601)
@@ -109,7 +109,7 @@ under the License.
</project>
```
- As you can see above the `<distributionManagement>` element is indented once (=2 spaces), the `<site>` element is indented twice (=4 spaces), and the `<id>` is indented three times (=6 spaces).
+ As you can see above the `\<distributionManagement\>` element is indented once (\=2 spaces), the `\<site\>` element is indented twice (\=4 spaces), and the `\<id\>` is indented three times (\=6 spaces).
diff --git a/content/markdown/guides/development/guide-maven-development.md b/content/markdown/guides/development/guide-maven-development.md
index 0411186b..a216fe7f 100644
--- a/content/markdown/guides/development/guide-maven-development.md
+++ b/content/markdown/guides/development/guide-maven-development.md
@@ -74,7 +74,7 @@ under the License.
- If this was a new piece of work without a JIRA issue, create a JIRA issue for it now.
- - Name the branch after the issue number; the branch name would start with `<jira-project-id>-<ticket-id>`.
+ - Name the branch after the issue number; the branch name would start with `\<jira-project-id\>-\<ticket-id\>`.
- Push your branch with the commit(s) to your fork.
diff --git a/content/markdown/guides/development/guide-plugin-documentation.md b/content/markdown/guides/development/guide-plugin-documentation.md
index 24d4b3d3..d7706458 100644
--- a/content/markdown/guides/development/guide-plugin-documentation.md
+++ b/content/markdown/guides/development/guide-plugin-documentation.md
@@ -68,15 +68,15 @@ mvn site
- - `<modelVersion>` - POM model version, currently 4.0.0
+ - `\<modelVersion\>` - POM model version, currently 4.0.0
- - `<groupId>` - the package name
+ - `\<groupId\>` - the package name
- - `<artifactId>` - artifact name
+ - `\<artifactId\>` - artifact name
- - `<packaging>` - type of artifact produced by the POM
+ - `\<packaging\>` - type of artifact produced by the POM
- - `<version>` - the plugin version
+ - `\<version\>` - the plugin version
@@ -87,15 +87,15 @@ mvn site
- - `<name>` - plugin's name, _Maven NNN Plugin_ for plugins hosted at the Maven project or _NNN Maven Plugin_ for all others
+ - `\<name\>` - plugin's name, _Maven NNN Plugin_ for plugins hosted at the Maven project or _NNN Maven Plugin_ for all others
- - `<description>` - project description, an overview of what the plugin can do
+ - `\<description\>` - project description, an overview of what the plugin can do
- - `<url>` - the site of the plugin, normally _maven.apache.org_ or _org.mojohaus_
+ - `\<url\>` - the site of the plugin, normally _maven.apache.org_ or _org.mojohaus_
- - `<prerequisites>` - the minimum version of Maven required to use this plugin
+ - `\<prerequisites\>` - the minimum version of Maven required to use this plugin
- - `<issueManagement>` - describes the system used for reporting problems and modification requests
+ - `\<issueManagement\>` - describes the system used for reporting problems and modification requests
```
<project>
@@ -109,9 +109,9 @@ mvn site
```
- - `<inceptionYear>` - year the plugin was first created
+ - `\<inceptionYear\>` - year the plugin was first created
- - `<mailingLists>` - lists where other users or the developers can be contacted for help and discussions
+ - `\<mailingLists\>` - lists where other users or the developers can be contacted for help and discussions
```
<project>
@@ -133,7 +133,7 @@ mvn site
```
- - `<licenses>` - plugin license
+ - `\<licenses\>` - plugin license
```
<project>
@@ -150,7 +150,7 @@ mvn site
```
- - `<scm>` - the source code management configuration - a plugin without this would raise suspicion, might not be OSS
+ - `\<scm\>` - the source code management configuration - a plugin without this would raise suspicion, might not be OSS
```
<project>
@@ -165,7 +165,7 @@ mvn site
```
- - `<organization>` - the organization maintaining the plugin, just in case we need someone to blame
+ - `\<organization\>` - the organization maintaining the plugin, just in case we need someone to blame
```
<project>
@@ -185,7 +185,7 @@ mvn site
### Plugin Configuration Parameters
- The Maven Plugin Plugin is responsible for generating the Plugin Info site and needs to be added to the `<reporting>` section unless it is already inherited from a parent POM:
+ The Maven Plugin Plugin is responsible for generating the Plugin Info site and needs to be added to the `\<reporting\>` section unless it is already inherited from a parent POM:
diff --git a/content/markdown/guides/development/guide-testing-development-plugins.md b/content/markdown/guides/development/guide-testing-development-plugins.md
index e1b5a95e..ffc354e7 100644
--- a/content/markdown/guides/development/guide-testing-development-plugins.md
+++ b/content/markdown/guides/development/guide-testing-development-plugins.md
@@ -93,7 +93,7 @@ under the License.
_Note:_ These last two techniques mean that _every_ plugin will be updated to the latest snapshot version.
- The development version will stop being used if the `<pluginRepository>` element is removed from your POM and the version is set back to the release version. If you are using the command line or an unspecified version, you will also need to remove the version from the local repository.
+ The development version will stop being used if the `\<pluginRepository\>` element is removed from your POM and the version is set back to the release version. If you are using the command line or an unspecified version, you will also need to remove the version from the local repository.
diff --git a/content/markdown/guides/development/guide-testing-releases.md b/content/markdown/guides/development/guide-testing-releases.md
index beba1ccf..1c70c935 100644
--- a/content/markdown/guides/development/guide-testing-releases.md
+++ b/content/markdown/guides/development/guide-testing-releases.md
@@ -32,7 +32,7 @@ under the License.
- add the repository or plugin repository to your POM or settings (see below)
- - ensure you are using the version being released of the artifacts in your project, e.g. by setting the `<version>` in the `<plugin>` tag.
+ - ensure you are using the version being released of the artifacts in your project, e.g. by setting the `\<version\>` in the `\<plugin\>` tag.
- test the release
@@ -69,11 +69,11 @@ under the License.
- - Identifier = `staged-releases`
+ - Identifier \= `staged-releases`
- - Name = Staged Releases
+ - Name \= Staged Releases
- - Directory = `/path/to/repositories/staged-releases`
+ - Directory \= `/path/to/repositories/staged-releases`
- Uncheck 'Scannable'
@@ -82,26 +82,26 @@ under the License.
- - Identifier = `dfabulich.staged.releases`
+ - Identifier \= `dfabulich.staged.releases`
- - Name = dfabulich Staged Releases
+ - Name \= dfabulich Staged Releases
- - URL = `http://people.apache.org/\~dfabulich/staging-repo/`
+ - URL \= `http://people.apache.org/\~dfabulich/staging-repo/`
Finally, add a proxy connector to connect the two repositories:
- - Managed repository = `staged-releases`
+ - Managed repository \= `staged-releases`
- - Remote repository = `dfabulich.staged`
+ - Remote repository \= `dfabulich.staged`
- - Release policy = `once`
+ - Release policy \= `once`
- - Snapshot policy = `never`
+ - Snapshot policy \= `never`
- - White list = `org/apache/maven/\*\*`
+ - White list \= `org/apache/maven/\*\*`
You can then utilise this repository from your POM or settings in the same way, but with the alternate URL of `http://localhost:8080/archiva/repository/staged-releases/`.
diff --git a/content/markdown/guides/getting-started/index.md b/content/markdown/guides/getting-started/index.md
index 8e215169..53e1ef09 100644
--- a/content/markdown/guides/getting-started/index.md
+++ b/content/markdown/guides/getting-started/index.md
@@ -177,7 +177,7 @@ mvn -B archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -Darch
- **groupId** This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example `org.apache.maven.plugins` is the designated groupId for all Maven plugins.
- - **artifactId** This element indicates the unique base name of the primary artifact being generated by this project. The primary artifact for a project is typically a JAR file. Secondary artifacts like source bundles also use the artifactId as part of their final name. A typical artifact produced by Maven would have the form `<artifactId>-<version>.<extension>` (for example, `myapp-1.0.jar`).
+ - **artifactId** This element indicates the unique base name of the primary artifact being generated by this project. The primary artifact for a project is typically a JAR file. Secondary artifacts like source bundles also use the artifactId as part of their final name. A typical artifact produced by Maven would have the form \<artifactId\>-\<version\>.\<extension\> (for example, `myapp-1.0.jar`).
- **version** This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the `SNAPSHOT` designator in a version, which indicates that a project is in a state of development. We will discuss the use of [snapshots](./index.html#What_is_a_SNAPSHOT_version) and how they work further on in this guide.
@@ -493,7 +493,7 @@ mvn clean
In other words, a SNAPSHOT version is the 'development' version before the final 'release' version. The SNAPSHOT is "older" than its release.
- During the [release](../../plugins/maven-release-plugin/) process, a version of **x.y-SNAPSHOT** changes to **x.y**. The release process also increments the development version to **x.(y+1)-SNAPSHOT**. For example, version **1.0-SNAPSHOT** is released as version **1.0**, and the new development version is version **1.1-SNAPSHOT**.
+ During the [release](../../plugins/maven-release-plugin/) process, a version of **x.y-SNAPSHOT** changes to **x.y**. The release process also increments the development version to **x.(y\+1)-SNAPSHOT**. For example, version **1.0-SNAPSHOT** is released as version **1.0**, and the new development version is version **1.1-SNAPSHOT**.
@@ -643,7 +643,7 @@ InputStream is = getClass().getResourceAsStream( "/test.properties" );
### How do I filter resource files?
- Sometimes a resource file will need to contain a value that can only be supplied at build time. To accomplish this in Maven, put a reference to the property that will contain the value into your resource file using the syntax `${<property name>}`. The property can be one of the values defined in your pom.xml, a value defined in the user's settings.xml, a property defined in an external properties file, or a system property.
+ Sometimes a resource file will need to contain a value that can only be supplied at build time. To accomplish this in Maven, put a reference to the property that will contain the value into your resource file using the syntax `$\{\<property name\>\}`. The property can be one of the values defined in your pom.xml, a value defined in the user's settings.xml, a property defined in an external properties file, or a system property.
To have Maven filter resources when copying, simply set `filtering` to true for the resource directory in your `pom.xml`:
@@ -1121,7 +1121,7 @@ mvn archetype:generate \
</project>
```
- Note the `<packaging>` element - this tells Maven to build as a WAR. Change into the webapp project's directory and try:
+ Note the `\<packaging\>` element - this tells Maven to build as a WAR. Change into the webapp project's directory and try:
@@ -1194,7 +1194,7 @@ mvn package
</dependencies>
```
- Finally, add the following `<parent>` element to both of the other `pom.xml` files in the subdirectories:
+ Finally, add the following `\<parent\>` element to both of the other `pom.xml` files in the subdirectories:
@@ -1243,7 +1243,7 @@ $ jar tvf my-webapp/target/my-webapp-1.0-SNAPSHOT.war
Next, we tell the WAR that it requires the `my-app` JAR. This does a few things: it makes it available on the classpath to any code in the WAR (none in this case), it makes sure the JAR is always built before the WAR, and it indicates to the WAR plugin to include the JAR in its library directory.
- You may have noticed that `junit-4.11.jar` was a dependency, but didn't end up in the WAR. The reason for this is the `<scope>test</scope>` element - it is only required for testing, and so is not included in the web application as the compile time dependency `my-app` is.
+ You may have noticed that `junit-4.11.jar` was a dependency, but didn't end up in the WAR. The reason for this is the `\<scope\>test\</scope\>` element - it is only required for testing, and so is not included in the web application as the compile time dependency `my-app` is.
The final step was to include a parent definition. This ensures that the POM can always be located even if the project is distributed separately from its parent by looking it up in the repository.
diff --git a/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md b/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
index c7b2b476..e860b944 100644
--- a/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
+++ b/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
@@ -145,7 +145,7 @@ This scope indicates that the dependency is not required for normal use of the a
This scope is similar to `provided` except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
- **import**\
-This scope is only supported on a dependency of type `pom` in the `<dependencyManagement>` section. It indicates the dependency is to be replaced with the effective list of dependencies in the specified POM's `<dependencyManagement>` section. Since they are replaced, dependencies with a scope of `import` do not actually participate in limiting the transitivity of a dependency.
+This scope is only supported on a dependency of type `pom` in the `\<dependencyManagement\>` section. It indicates the dependency is to be replaced with the effective list of dependencies in the specified POM's `\<dependencyManagement\>` section. Since they are replaced, dependencies with a scope of `import` do not actually participate in limiting the transitivity of a dependency.
Each of the scopes (except for `import`) affects transitive dependencies in different ways, as is demonstrated in the table below. If a dependency is set to the scope in the left column, a transitive dependency of that dependency with the scope across the top row results in a dependency in the main project with the scope listed at the intersection. If no scope is listed, it means the dependency is omitted.
@@ -322,7 +322,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
```
- **NOTE:** In two of these dependency references, we had to specify the `<type>` element. This is because the minimal set of information for matching a dependency reference against a dependencyManagement section is actually **\{groupId, artifactId, type, classifier\}**. In many cases, these dependencies will refer to jar artifacts with no classifier. This allows us to shorthand the identity set to **\{groupId, artifactId\}**, since the default for the type field is `jar`, and the default [...]
+ **NOTE:** In two of these dependency references, we had to specify the \<type/\> element. This is because the minimal set of information for matching a dependency reference against a dependencyManagement section is actually **\{groupId, artifactId, type, classifier\}**. In many cases, these dependencies will refer to jar artifacts with no classifier. This allows us to shorthand the identity set to **\{groupId, artifactId\}**, since the default for the type field is `jar`, and the defaul [...]
A second, and very important use of the dependency management section is to control the versions of artifacts used in transitive dependencies. As an example consider these projects:
diff --git a/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md b/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md
index 88e29c2f..0545c7e6 100644
--- a/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md
+++ b/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md
@@ -45,7 +45,7 @@ under the License.
#### How do I use the optional tag?
- A dependency is declared optional by setting the `<optional>` element to true in its dependency declaration:
+ A dependency is declared optional by setting the `\<optional\>` element to true in its dependency declaration:
@@ -109,7 +109,7 @@ Project-X -> Project-A
#### How to use dependency exclusions
- Add an `<exclusions>` element in the `<dependency>` element by which the problematic jar is included.
+ Add an `\<exclusions\>` element in the `\<dependency\>` element by which the problematic jar is included.
@@ -159,7 +159,7 @@ Project-A
B, C, D, E, F
```
- Suppose you don't want project D and its dependencies to be added to Project A's classpath because some of Project-D's dependencies are missing from the repository, and you don't need the functionality in Project-B that depends on Project-D anyway. Project-B's developers could have marked the dependency on Project-D `<optional>true</optional>`:
+ Suppose you don't want project D and its dependencies to be added to Project A's classpath because some of Project-D's dependencies are missing from the repository, and you don't need the functionality in Project-B that depends on Project-D anyway. Project-B's developers could have marked the dependency on Project-D `\<optional\>true\</optional\>`:
diff --git a/content/markdown/guides/introduction/introduction-to-plugins.md b/content/markdown/guides/introduction/introduction-to-plugins.md
index 8fee0356..1486fe82 100644
--- a/content/markdown/guides/introduction/introduction-to-plugins.md
+++ b/content/markdown/guides/introduction/introduction-to-plugins.md
@@ -46,7 +46,7 @@ under the License.
A Mojo is really just a **goal** in Maven, and plug-ins consist of any number of goals (Mojos). Mojos can be defined as annotated Java classes or Beanshell script. A Mojo specifies metadata about a goal: a goal name, which phase of the lifecycle it fits into, and the parameters it is expecting.
- MOJO is a play on POJO (Plain-old-Java-object), substituting "Maven" for "Plain". Mojo is also an interesting word (see [definition](http://www.answers.com/mojo&r=67)). From [Wikipedia](http://www.wikipedia.org), a "mojo" is defined as: "...a small bag worn by a person under the clothes (also known as a mojo hand). Such bags were thought to have supernatural powers, such as protecting from evil, bringing good luck, etc."
+ MOJO is a play on POJO (Plain-old-Java-object), substituting "Maven" for "Plain". Mojo is also an interesting word (see [definition](http://www.answers.com/mojo&r\=67)). From [Wikipedia](http://www.wikipedia.org), a "mojo" is defined as: "...a small bag worn by a person under the clothes (also known as a mojo hand). Such bags were thought to have supernatural powers, such as protecting from evil, bringing good luck, etc."
diff --git a/content/markdown/guides/introduction/introduction-to-profiles.md b/content/markdown/guides/introduction/introduction-to-profiles.md
index 5239e22f..4ab06a40 100644
--- a/content/markdown/guides/introduction/introduction-to-profiles.md
+++ b/content/markdown/guides/introduction/introduction-to-profiles.md
@@ -57,7 +57,7 @@ under the License.
- [Profiles in POMs](Profiles_in_POMs)
- - [POM elements outside `<profiles>`](POM_elements_outside_.3Cprofiles.3E)
+ - [POM elements outside \<profiles\>](POM_elements_outside_.3Cprofiles.3E)
@@ -109,7 +109,7 @@ under the License.
- Profile descriptor
- - a descriptor located in [project basedir `(profiles.xml)`](/ref/2.2.1/maven-profile/profiles.html) (no longer supported in Maven 3.0 and above; see [ Maven 3 compatibility notes](https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-profiles.xml))
+ - a descriptor located in [project basedir `(profiles.xml)`](/ref/2.2.1/maven-profile/profiles.html) (no longer supported in Maven 3.0 and above; see [ Maven 3 compatibility notes](https://cwiki.apache.org/confluence/display/MAVEN/Maven\+3.x\+Compatibility\+Notes#Maven3.xCompatibilityNotes-profiles.xml))
@@ -145,7 +145,7 @@ under the License.
Profiles can be explicitly specified using the `-P` command line flag.
- This flag is followed by a comma-delimited list of profile IDs to use. The profile(s) specified in the option are activated in addition to any profiles which are activated by their activation configuration or the `<activeProfiles>` section in `settings.xml`. From Maven 4 onward, Maven will refuse to activate or deactivate a profile that cannot be resolved. To prevent this, prefix the profile identifier with an `?`, marking it as optional:
+ This flag is followed by a comma-delimited list of profile IDs to use. The profile(s) specified in the option are activated in addition to any profiles which are activated by their activation configuration or the `\<activeProfiles\>` section in `settings.xml`. From Maven 4 onward, Maven will refuse to activate or deactivate a profile that cannot be resolved. To prevent this, prefix the profile identifier with an `?`, marking it as optional:
@@ -153,7 +153,7 @@ under the License.
mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
```
- Profiles can be activated in the Maven settings, via the `<activeProfiles>` section. This section takes a list of `<activeProfile>` elements, each containing a profile-id inside.
+ Profiles can be activated in the Maven settings, via the `\<activeProfiles\>` section. This section takes a list of `\<activeProfile\>` elements, each containing a profile-id inside.
@@ -167,14 +167,14 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
</settings>
```
- Profiles listed in the `<activeProfiles>` tag would be activated by default every time a project use it.
+ Profiles listed in the `\<activeProfiles\>` tag would be activated by default every time a project use it.
##### Implicit profile activation
- Profiles can be automatically triggered based on the detected state of the build environment. These triggers are specified via an `<activation>` section in the profile itself. Currently, this detection is limited to JDK version matching, operating system matching or the presence/the value of a system property. Here are some examples.
+ Profiles can be automatically triggered based on the detected state of the build environment. These triggers are specified via an `\<activation\>` section in the profile itself. Currently, this detection is limited to JDK version matching, operating system matching or the presence/the value of a system property. Here are some examples.
###### JDK
@@ -373,7 +373,7 @@ mvn groupId:artifactId:goal -Denvironment=test
</profiles>
```
- As of Maven 2.0.9, the tags `<exists>` and `<missing>` could be interpolated. Supported variables are system properties like `${user.home}` and environment variables like `${env.HOME}`. Please note that properties and values defined in the POM itself are not available for interpolation here, e.g. the above example activator cannot use `${project.build.directory}` but needs to hard-code the path `target`.
+ As of Maven 2.0.9, the tags `\<exists\>` and `\<missing\>` could be interpolated. Supported variables are system properties like `$\{user.home\}` and environment variables like `$\{env.HOME\}`. Please note that properties and values defined in the POM itself are not available for interpolation here, e.g. the above example activator cannot use `$\{project.build.directory\}` but needs to hard-code the path `target`.
Profiles can also be active by default using a configuration like the following:
@@ -434,10 +434,10 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
#### Profiles in external files
- Profiles specified in external files (i.e in `settings.xml` or `profiles.xml`) are not portable in the strictest sense. Anything that seems to stand a high chance of changing the result of the build is restricted to the inline profiles in the POM. Things like repository lists could simply be a proprietary repository of approved artifacts, and won't change the outcome of the build. Therefore, you will only be able to modify the `<repositories>` and `<pluginRepositories>` sections, plus a [...]
+ Profiles specified in external files (i.e in `settings.xml` or `profiles.xml`) are not portable in the strictest sense. Anything that seems to stand a high chance of changing the result of the build is restricted to the inline profiles in the POM. Things like repository lists could simply be a proprietary repository of approved artifacts, and won't change the outcome of the build. Therefore, you will only be able to modify the `\<repositories\>` and `\<pluginRepositories\>` sections, pl [...]
- The `<properties>` section allows you to specify free-form key-value pairs which will be included in the interpolation process for the POM. This allows you to specify a plugin configuration in the form of `${profile.provided.path}`.
+ The `\<properties\>` section allows you to specify free-form key-value pairs which will be included in the interpolation process for the POM. This allows you to specify a plugin configuration in the form of `$\{profile.provided.path\}`.
@@ -451,49 +451,49 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
- - `<repositories>`
+ - `\<repositories\>`
- - `<pluginRepositories>`
+ - `\<pluginRepositories\>`
- - `<dependencies>`
+ - `\<dependencies\>`
- - `<plugins>`
+ - `\<plugins\>`
- - `<properties>` (not actually available in the main POM, but used behind the scenes)
+ - `\<properties\>` (not actually available in the main POM, but used behind the scenes)
- - `<modules>`
+ - `\<modules\>`
- - `<reports>`
+ - `\<reports\>`
- - `<reporting>`
+ - `\<reporting\>`
- - `<dependencyManagement>`
+ - `\<dependencyManagement\>`
- - `<distributionManagement>`
+ - `\<distributionManagement\>`
- - a subset of the `<build>` element, which consists of:
+ - a subset of the `\<build\>` element, which consists of:
- - `<defaultGoal>`
+ - `\<defaultGoal\>`
- - `<resources>`
+ - `\<resources\>`
- - `<testResources>`
+ - `\<testResources\>`
- - `<directory>`
+ - `\<directory\>`
- - `<finalName>`
+ - `\<finalName\>`
- - `<filters>`
+ - `\<filters\>`
- - `<pluginManagement>`
+ - `\<pluginManagement\>`
- - `<plugins>`
+ - `\<plugins\>`
-#### POM elements outside `<profiles>`
+#### POM elements outside \<profiles\>
We don't allow modification of some POM elements outside of POM-profiles because these runtime modifications will not be distributed when the POM is deployed to the repository system, making that person's build of that project completely unique from others. While you can do this to some extent with the options given for external profiles, the danger is limited. Another reason is that this POM info is sometimes being reused from the parent POM.
@@ -621,10 +621,10 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
When you build the **integration-test** lifecycle phase, your integration tests pass, since the path you've provided allows the test plugin to install and test this web application.
- _However_, when your colleague attempts to build to **integration-test**, his build fails spectacularly, complaining that it cannot resolve the plugin configuration parameter `<appserverHome>`, or worse, that the value of that parameter - literally `${appserver.home}` - is invalid (if it warns you at all).
+ _However_, when your colleague attempts to build to **integration-test**, his build fails spectacularly, complaining that it cannot resolve the plugin configuration parameter `\<appserverHome\>`, or worse, that the value of that parameter - literally `$\{appserver.home\}` - is invalid (if it warns you at all).
- Congratulations, your project is now non-portable. Inlining this profile in your `pom.xml` can help alleviate this, with the obvious drawback that each project hierarchy (allowing for the effects of inheritance) now have to specify this information. Since Maven provides good support for project inheritance, it's possible to stick this sort of configuration in the `<pluginManagement>` section of a team-level POM or similar, and simply inherit the paths.
+ Congratulations, your project is now non-portable. Inlining this profile in your `pom.xml` can help alleviate this, with the obvious drawback that each project hierarchy (allowing for the effects of inheritance) now have to specify this information. Since Maven provides good support for project inheritance, it's possible to stick this sort of configuration in the `\<pluginManagement\>` section of a team-level POM or similar, and simply inherit the paths.
Another, less attractive answer might be standardization of development environments. However, this will tend to compromise the productivity gain that Maven is capable of providing.
@@ -696,7 +696,7 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
</project>
```
- This profile looks quite similar to the one from the last example, with a few important exceptions: it's plainly geared toward a development environment, a new profile named `appserverConfig-dev-2` is added and it has an activation section that will trigger its inclusion when the system properties contain "env=dev" for a profile named `appserverConfig-dev` and "env=dev-2" for a profile named `appserverConfig-dev-2`. So, executing:
+ This profile looks quite similar to the one from the last example, with a few important exceptions: it's plainly geared toward a development environment, a new profile named `appserverConfig-dev-2` is added and it has an activation section that will trigger its inclusion when the system properties contain "env\=dev" for a profile named `appserverConfig-dev` and "env\=dev-2" for a profile named `appserverConfig-dev-2`. So, executing:
@@ -720,7 +720,7 @@ mvn -Denv=dev integration-test
mvn -Denv=production integration-test
```
- will not do a successful build. Why? Because, the resulting non-interpolated literal value of `$\{appserver.home\}` will not be a valid path for deploying and testing your web application. We haven't considered the case for the production environment when writing our profiles. The "production" environment (env=production), along with "test" and possibly even "local" constitute a natural set of target environments for which we may want to build the integration-test lifecycle phase. The i [...]
+ will not do a successful build. Why? Because, the resulting non-interpolated literal value of `$\{appserver.home\}` will not be a valid path for deploying and testing your web application. We haven't considered the case for the production environment when writing our profiles. The "production" environment (env\=production), along with "test" and possibly even "local" constitute a natural set of target environments for which we may want to build the integration-test lifecycle phase. The [...]
As a quick aside, it's possible for user-specific profiles to act in a similar way. This means that profiles for handling different environments which are keyed to the user can act up when the team adds a new developer. While I suppose this _could_ act as useful training for the newbie, it just wouldn't be nice to throw them to the wolves in this way. Again, be sure to think of the _whole_ set of profiles.
@@ -750,7 +750,7 @@ mvn -Denv=production integration-test
mvn help:active-profiles -Denv=dev
```
- The result will be a bulleted list of the id of the profile with an activation property of "env=dev" together with the source where it was declared. See sample below.
+ The result will be a bulleted list of the id of the profile with an activation property of "env\=dev" together with the source where it was declared. See sample below.
@@ -811,7 +811,7 @@ The following profiles are active:
This will print the effective POM for this build configuration out to the console. Take note that profiles in the `settings.xml` takes higher priority than profiles in the POM. So the profile that has been applied here is `appserverConfig` not `appserverConfig-dev`.
- If you want to redirect the output from the plugin to a file called `effective-pom.xml`, use the command-line option `-Doutput=effective-pom.xml`.
+ If you want to redirect the output from the plugin to a file called `effective-pom.xml`, use the command-line option `-Doutput\=effective-pom.xml`.
@@ -829,7 +829,7 @@ The following profiles are active:
mvn -Denv=test <phase>
```
- The right command-line option can be had by simply substituting "=" for "-" in the profile id.
+ The right command-line option can be had by simply substituting "\=" for "-" in the profile id.
diff --git a/content/markdown/guides/introduction/introduction-to-the-lifecycle.md b/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
index 5e495e11..5985c608 100644
--- a/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
+++ b/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
@@ -179,7 +179,7 @@ mvn clean dependency:copy-dependencies package
#### Packaging
- The first, and most common way, is to set the packaging for your project via the equally named POM element `<packaging>`. Some of the valid packaging values are `jar`, `war`, `ear` and `pom`. If no packaging value has been specified, it will default to `jar`.
+ The first, and most common way, is to set the packaging for your project via the equally named POM element `\<packaging\>`. Some of the valid packaging values are `jar`, `war`, `ear` and `pom`. If no packaging value has been specified, it will default to `jar`.
Each packaging contains a list of goals to bind to a particular phase. For example, the `jar` packaging will bind the following goals to build phases of the default lifecycle.
@@ -199,7 +199,7 @@ mvn clean dependency:copy-dependencies package
This is an almost [standard set of bindings](/ref/current/maven-core/default-bindings.html); however, some packagings handle them differently. For example, a project that is purely metadata (packaging value is `pom`) only binds goals to the `install` and `deploy` phases (for a complete list of goal-to-build-phase bindings of some of the packaging types, refer to the [Lifecycle Reference](Lifecycle_Reference)).
- Note that for some packaging types to be available, you may also need to include a particular plugin in the `<build>` section of your POM and specify `<extensions>true</extensions>` for that plugin. One example of a plugin that requires this is the Plexus plugin, which provides a `plexus-application` and `plexus-service` packaging.
+ Note that for some packaging types to be available, you may also need to include a particular plugin in the `\<build\>` section of your POM and specify `\<extensions\>true\</extensions\>` for that plugin. One example of a plugin that requires this is the Plexus plugin, which provides a `plexus-application` and `plexus-service` packaging.
_[\[top\]](./introduction-to-the-lifecycle.html)._
@@ -215,10 +215,10 @@ mvn clean dependency:copy-dependencies package
As you will see in the later sections, plugins can contain information that indicates which lifecycle phase to bind a goal to. Note that adding the plugin on its own is not enough information - you must also specify the goals you want to run as part of your build.
- The goals that are configured will be added to the goals already bound to the lifecycle from the packaging selected. If more than one goal is bound to a particular phase, the order used is that those from the packaging are executed first, followed by those configured in the POM. Note that you can use the `<executions>` element to gain more control over the order of particular goals.
+ The goals that are configured will be added to the goals already bound to the lifecycle from the packaging selected. If more than one goal is bound to a particular phase, the order used is that those from the packaging are executed first, followed by those configured in the POM. Note that you can use the `\<executions\>` element to gain more control over the order of particular goals.
- For example, the Modello plugin binds by default its goal `modello:java` to the `generate-sources` phase (Note: The `modello:java` goal generates Java source codes). So to use the Modello plugin and have it generate sources from a model and incorporate that into the build, you would add the following to your POM in the `<plugins>` section of `<build>`:
+ For example, the Modello plugin binds by default its goal `modello:java` to the `generate-sources` phase (Note: The `modello:java` goal generates Java source codes). So to use the Modello plugin and have it generate sources from a model and incorporate that into the build, you would add the following to your POM in the `\<plugins\>` section of `\<build\>`:
@@ -243,7 +243,7 @@ mvn clean dependency:copy-dependencies package
</plugin>
```
- You might be wondering why that `<executions>` element is there. That is so that you can run the same goal multiple times with different configuration if needed. Separate executions can also be given an ID so that during inheritance or the application of profiles you can control whether goal configuration is merged or turned into an additional execution.
+ You might be wondering why that `\<executions\>` element is there. That is so that you can run the same goal multiple times with different configuration if needed. Separate executions can also be given an ID so that during inheritance or the application of profiles you can control whether goal configuration is merged or turned into an additional execution.
When multiple executions are given that match a particular phase, they are executed in the order specified in the POM, with inherited executions running first.
diff --git a/content/markdown/guides/introduction/introduction-to-the-pom.md b/content/markdown/guides/introduction/introduction-to-the-pom.md
index 6ec1cf88..b0d7e81c 100644
--- a/content/markdown/guides/introduction/introduction-to-the-pom.md
+++ b/content/markdown/guides/introduction/introduction-to-the-pom.md
@@ -120,7 +120,7 @@ under the License.
</project>
```
- A POM requires that its groupId, artifactId, and version be configured. These three values form the project's fully qualified artifact name. This is in the form of `<groupId>:<artifactId>:<version>`. As for the example above, its fully qualified artifact name is "com.mycompany.app:my-app:1".
+ A POM requires that its groupId, artifactId, and version be configured. These three values form the project's fully qualified artifact name. This is in the form of \<groupId\>:\<artifactId\>:\<version\>. As for the example above, its fully qualified artifact name is "com.mycompany.app:my-app:1".
Also, as mentioned in the [first section](What_is_a_POM), if the configuration details are not specified, Maven will use their defaults. One of these default values is the packaging type. Every Maven project has a packaging type. If it is not specified in the POM, then the default value "jar" would be used.
@@ -271,7 +271,7 @@ under the License.
##### The Solution
- To address this directory structure (or any other directory structure), we would have to add the `<relativePath>` element to our parent section.
+ To address this directory structure (or any other directory structure), we would have to add the `\<relativePath\>` element to our parent section.
@@ -382,7 +382,7 @@ under the License.
</project>
```
- In the revised com.mycompany.app:my-app:1, the packaging section and the modules sections were added. For the packaging, its value was set to "pom", and for the modules section, we have the element `<module>my-module</module>`. The value of `<module>` is the relative path from the com.mycompany.app:my-app:1 to com.mycompany.app:my-module:1's POM (_by practice, we use the module's artifactId as the module directory's name_).
+ In the revised com.mycompany.app:my-app:1, the packaging section and the modules sections were added. For the packaging, its value was set to "pom", and for the modules section, we have the element `\<module\>my-module\</module\>`. The value of `\<module\>` is the relative path from the com.mycompany.app:my-app:1 to com.mycompany.app:my-module:1's POM (_by practice, we use the module's artifactId as the module directory's name_).
Now, whenever a Maven command processes com.mycompany.app:my-app:1, that same Maven command would be ran against com.mycompany.app:my-module:1 as well. Furthermore, some commands (goals specifically) handle project aggregation differently.
diff --git a/content/markdown/guides/mini/guide-configuring-maven.md b/content/markdown/guides/mini/guide-configuring-maven.md
index d390f9e2..e457d858 100644
--- a/content/markdown/guides/mini/guide-configuring-maven.md
+++ b/content/markdown/guides/mini/guide-configuring-maven.md
@@ -38,7 +38,7 @@ under the License.
The separation is quite clear - the project defines information that applies to the project, no matter who is building it, while the others both define settings for the current environment.
- **Note:** the installation and user configuration cannot be used to add shared project information - for example, setting `<organization>` or `<distributionManagement>` company-wide.
+ **Note:** the installation and user configuration cannot be used to add shared project information - for example, setting `\<organization\>` or `\<distributionManagement\>` company-wide.
For this, you should have your projects inherit from a company-wide parent `pom.xml`.
@@ -80,7 +80,7 @@ under the License.
### Configuring Parallel Artifact Resolution
- By default, Maven 2.1.0+ will download up to 5 artifacts (from different groups) at once. To change the size of the thread pool, start Maven using `-Dmaven.artifact.threads`. For example, to only download single artifacts at a time:
+ By default, Maven 2.1.0\+ will download up to 5 artifacts (from different groups) at once. To change the size of the thread pool, start Maven using `-Dmaven.artifact.threads`. For example, to only download single artifacts at a time:
@@ -100,7 +100,7 @@ export MAVEN_OPTS=-Dmaven.artifact.threads=3
### Security and Deployment Settings
- Repositories to deploy to are defined in a project in the `<distributionManagement>` section. However, you cannot put your username, password, or other security settings in that project. For that reason, you should add a server definition to your own settings with an `id` that matches that of the deployment repository in the project.
+ Repositories to deploy to are defined in a project in the `\<distributionManagement\>` section. However, you cannot put your username, password, or other security settings in that project. For that reason, you should add a server definition to your own settings with an `id` that matches that of the deployment repository in the project.
In addition, some repositories may require authorization to download from, so the corresponding settings can be specified in a `server` element in the same way.
@@ -176,14 +176,14 @@ export MAVEN_OPTS=-Dmaven.artifact.threads=3
#### Security
- As of Maven 2.1.0+, you can encrypt passwords in your settings file, however you must first configure a master password. For more information on both server passwords and the master password, see the [Guide to Password Encryption](./guide-encryption.html).
+ As of Maven 2.1.0\+, you can encrypt passwords in your settings file, however you must first configure a master password. For more information on both server passwords and the master password, see the [Guide to Password Encryption](./guide-encryption.html).
#### Toolchains
- As of Maven 2.0.9+, you can build a project using a specific version of JDK independent from the one Maven is running with. For more information, see the [Guide to Using Toolchains](./guide-using-toolchains.html).
+ As of Maven 2.0.9\+, you can build a project using a specific version of JDK independent from the one Maven is running with. For more information, see the [Guide to Using Toolchains](./guide-using-toolchains.html).
diff --git a/content/markdown/guides/mini/guide-configuring-plugins.md b/content/markdown/guides/mini/guide-configuring-plugins.md
index e4725dba..e3d2ec46 100644
--- a/content/markdown/guides/mini/guide-configuring-plugins.md
+++ b/content/markdown/guides/mini/guide-configuring-plugins.md
@@ -53,21 +53,21 @@ under the License.
- [Configuring Build Plugins](Configuring_Build_Plugins)
- - [Using the `<executions>` Tag](Using_the_.3Cexecutions.3E_Tag)
+ - [Using the \<executions\> Tag](Using_the_.3Cexecutions.3E_Tag)
- - [Using the `<dependencies>` Tag](Using_the_.3Cdependencies.3E_Tag)
+ - [Using the \<dependencies\> Tag](Using_the_.3Cdependencies.3E_Tag)
- - [Using the `<inherited>` Tag In Build Plugins](Using_the_.3Cinherited.3E_Tag_In_Build_Plugins)
+ - [Using the \<inherited\> Tag In Build Plugins](Using_the_.3Cinherited.3E_Tag_In_Build_Plugins)
- [Configuring Reporting Plugins](Configuring_Reporting_Plugins)
- - [Using the `<reporting>` Tag VS `<build>` Tag](Using_the_.3Creporting.3E_Tag_VS_.3Cbuild.3E_Tag)
+ - [Using the \<reporting\> Tag VS \<build\> Tag](Using_the_.3Creporting.3E_Tag_VS_.3Cbuild.3E_Tag)
- - [Using the `<reportSets>` Tag](Using_the_.3CreportSets.3E_Tag)
+ - [Using the \<reportSets\> Tag](Using_the_.3CreportSets.3E_Tag)
- - [Using the `<inherited>` Tag In Reporting Plugins](Using_the_.3Cinherited.3E_Tag_In_Reporting_Plugins)
+ - [Using the \<inherited\> Tag In Reporting Plugins](Using_the_.3Cinherited.3E_Tag_In_Reporting_Plugins)
@@ -79,22 +79,22 @@ under the License.
- - **Build plugins** are executed during the build and configured in the `<build>` element.
+ - **Build plugins** are executed during the build and configured in the `\<build/\>` element.
- - **Reporting plugins** are executed during the site generation and configured in the `<reporting>` element.
+ - **Reporting plugins** are executed during the site generation and configured in the `\<reporting/\>` element.
All plugins should have minimal required [information](/ref/current/maven-model/maven.html#class_plugin): `groupId`, `artifactId` and `version`.
- **Important Note**: Always define the version of each plugin used to guarantee build reproducibility. A good practice is to specify each build plugin's version in a `<build><pluginManagement><build>` element. Often the `<pluginManagement>` element is found in the parent POM. For reporting plugins, specify each version in the `<reporting><plugins><reporting>` element (and in the `<build><pluginManagement><build>` element too).
+ **Important Note**: Always define the version of each plugin used to guarantee build reproducibility. A good practice is to specify each build plugin's version in a `\<build\>\<pluginManagement/\>\</build\>` element. Often the \<pluginManagement/\> element is found in the parent POM. For reporting plugins, specify each version in the `\<reporting\>\<plugins/\>\</reporting\>` element (and in the `\<build\>\<pluginManagement/\>\</build\>` element too).
### Generic Configuration
- Maven plugins (build and reporting) are configured by specifying a `<configuration>` element where the child elements of the `<configuration>` element are mapped to fields, or setters, inside your Mojo. (Remember that a plug-in consists of one or more Mojos where a Mojo maps to a goal.) Say, for example, you have a Mojo that performs a query against a particular URL, with a specified timeout and list of options. The Mojo might look like the following:
+ Maven plugins (build and reporting) are configured by specifying a `\<configuration\>` element where the child elements of the `\<configuration\>` element are mapped to fields, or setters, inside your Mojo. (Remember that a plug-in consists of one or more Mojos where a Mojo maps to a goal.) Say, for example, you have a Mojo that performs a query against a particular URL, with a specified timeout and list of options. The Mojo might look like the following:
@@ -151,7 +151,7 @@ public class MyQueryMojo
The elements in the configuration match the names of the fields in the Mojo. The mapping is straight forward. The `url` element maps to the `url` field, the `timeout` element maps to the `timeout` field, and the `options` element maps to the `options` field. The mapping mechanism can deal with arrays by inspecting the type of the field and determining if a suitable mapping is possible.
- For Mojos that are intended to be executed directly from the CLI, their parameters usually provide a means to be configured via system properties instead of a `<configuration>` section in the POM. The plugin documentation for those parameters will list an _expression_ that denotes the system properties for the configuration. In the Mojo above, the parameter `url` is associated with the expression `${query.url}`, meaning its value can be specified by the system property `query.url` as sh [...]
+ For Mojos that are intended to be executed directly from the CLI, their parameters usually provide a means to be configured via system properties instead of a `\<configuration\>` section in the POM. The plugin documentation for those parameters will list an _expression_ that denotes the system properties for the configuration. In the Mojo above, the parameter `url` is associated with the expression `$\{query.url\}`, meaning its value can be specified by the system property `query.url` a [...]
@@ -186,7 +186,7 @@ mvn javadoc:help -Ddetail -Dgoal=javadoc
##### Mapping Value Objects
- Mapping value types, like Boolean or Integer, is very simple. The `<configuration>` element might look like the following:
+ Mapping value types, like Boolean or Integer, is very simple. The `\<configuration\>` element might look like the following:
@@ -232,7 +232,7 @@ mvn javadoc:help -Ddetail -Dgoal=javadoc
##### Mapping Complex Objects
- Mapping complex types is also fairly straight forward. Let's look at a simple example where we are trying to map a configuration for Person object. The `<configuration>` element might look like the following:
+ Mapping complex types is also fairly straight forward. Let's look at a simple example where we are trying to map a configuration for Person object. The `\<configuration/\>` element might look like the following:
@@ -449,13 +449,13 @@ public class MyAnimalMojo
### Configuring Build Plugins
- The following is only to configure Build plugins in the `<build>` element.
+ The following is only to configure Build plugins in the `\<build\>` element.
-#### Using the `<executions>` Tag
+#### Using the `\<executions\>` Tag
- You can also configure a mojo using the `<executions>` tag. This is most commonly used for mojos that are intended to participate in some phases of the [build lifecycle](../introduction/introduction-to-the-lifecycle.html). Using `MyQueryMojo` as an example, you may have something that will look like:
+ You can also configure a mojo using the `\<executions\>` tag. This is most commonly used for mojos that are intended to participate in some phases of the [build lifecycle](../introduction/introduction-to-the-lifecycle.html). Using `MyQueryMojo` as an example, you may have something that will look like:
@@ -507,7 +507,7 @@ public class MyAnimalMojo
</project>
```
- The first execution with id "execution1" binds this configuration to the test phase. The second execution does not have a `<phase>` tag, how do you think will this execution behave? Well, goals can have a default phase binding as discussed further below. If the goal has a default phase binding then it will execute in that phase. But if the goal is not bound to any lifecycle phase then it simply won't be executed during the build lifecycle.
+ The first execution with id "execution1" binds this configuration to the test phase. The second execution does not have a `\<phase\>` tag, how do you think will this execution behave? Well, goals can have a default phase binding as discussed further below. If the goal has a default phase binding then it will execute in that phase. But if the goal is not bound to any lifecycle phase then it simply won't be executed during the build lifecycle.
Note that while execution id's have to be unique among all executions of a single plugin within a POM, they don't have to be unique across an inheritance hierarchy of POMs. Executions of the same id from different POMs are merged. The same applies to executions that are defined by profiles.
@@ -583,7 +583,7 @@ public class MyBoundQueryMojo
}
```
- From the above mojo example, `MyBoundQueryMojo` is by default bound to the package phase (see the `@phase` notation). But if we want to execute this mojo during the install phase and not with package we can rebind this mojo into a new lifecycle phase using the `<phase>` tag under `<execution>`.
+ From the above mojo example, `MyBoundQueryMojo` is by default bound to the package phase (see the `@phase` notation). But if we want to execute this mojo during the install phase and not with package we can rebind this mojo into a new lifecycle phase using the `\<phase\>` tag under `\<execution\>`.
@@ -623,7 +623,7 @@ public class MyBoundQueryMojo
Now, `MyBoundQueryMojo` default phase which is package has been overridden by install phase.
- **Note:** Configurations inside the `<executions>` element used to differ from those that are outside `<executions>` in that they could not be used from a direct command line invocation because they were only applied when the lifecycle phase they were bound to was invoked. So you had to move a configuration section outside of the executions section to apply it globally to all invocations of the plugin. Since Maven 3.3.1 this is not the case anymore as you can specify on the command line [...]
+ **Note:** Configurations inside the `\<executions\>` element used to differ from those that are outside `\<executions\>` in that they could not be used from a direct command line invocation because they were only applied when the lifecycle phase they were bound to was invoked. So you had to move a configuration section outside of the executions section to apply it globally to all invocations of the plugin. Since Maven 3.3.1 this is not the case anymore as you can specify on the command [...]
@@ -632,13 +632,13 @@ mvn myquery:query@execution1
```
-#### Using the `<dependencies>` Tag
+#### Using the `\<dependencies\>` Tag
You could configure the dependencies of the Build plugins, commonly to use a more recent dependency version.
- For instance, the Maven Antrun Plugin version 1.2 uses Ant version 1.6.5, if you want to use the latest Ant version when running this plugin, you need to add `<dependencies>` element like the following:
+ For instance, the Maven Antrun Plugin version 1.2 uses Ant version 1.6.5, if you want to use the latest Ant version when running this plugin, you need to add `\<dependencies\>` element like the following:
@@ -672,10 +672,10 @@ mvn myquery:query@execution1
```
-#### Using the `<inherited>` Tag In Build Plugins
+#### Using the `\<inherited\>` Tag In Build Plugins
- By default, plugin configuration should be propagated to child POMs, so to break the inheritance, you could use the `<inherited>` tag:
+ By default, plugin configuration should be propagated to child POMs, so to break the inheritance, you could use the `\<inherited\>` tag:
@@ -702,26 +702,26 @@ mvn myquery:query@execution1
### Configuring Reporting Plugins
- The following is only to configure Reporting plugins in the `<reporting>` element.
+ The following is only to configure Reporting plugins in the `\<reporting\>` element.
-#### Using the `<reporting>` Tag VS `<build>` Tag
+#### Using the `\<reporting\>` Tag VS `\<build\>` Tag
- Configuring a reporting plugin in the `<reporting>` or `<build>` elements in the pom does not exactly have the same results.
+ Configuring a reporting plugin in the `\<reporting\>` or `\<build\>` elements in the pom does not exactly have the same results.
- [`mvn site`] Since maven-site-plugin 3.4, it uses the parameters defined in the `<configuration>` element of each reporting Plugin specified in the `<reporting>` element, in addition to the parameters defined in the `<configuration>` element of each plugin specified in `<build>` (parameters from `<build>` section were previously ignored).
+ [`mvn site`] Since maven-site-plugin 3.4, it uses the parameters defined in the `\<configuration\>` element of each reporting Plugin specified in the `\<reporting\>` element, in addition to the parameters defined in the `\<configuration\>` element of each plugin specified in `\<build\>` (parameters from `\<build\>` section were previously ignored).
- [`mvn aplugin:areportgoal`] It **ignores** the parameters defined in the `<configuration>` element of each reporting Plugin specified in the `<reporting>` element; only parameters defined in the `<configuration>` element of each plugin specified in `<build>` are used.
+ [`mvn aplugin:areportgoal`] It **ignores** the parameters defined in the `\<configuration\>` element of each reporting Plugin specified in the `\<reporting\>` element; only parameters defined in the `\<configuration\>` element of each plugin specified in `\<build\>` are used.
-#### Using the `<reportSets>` Tag
+#### Using the `\<reportSets\>` Tag
- You can configure a reporting plugin using the `<reportSets>` tag. This is most commonly used to generate reports selectively when running `mvn site`. The following will generate only the project team report.
+ You can configure a reporting plugin using the `\<reportSets\>` tag. This is most commonly used to generate reports selectively when running `mvn site`. The following will generate only the project team report.
@@ -767,10 +767,10 @@ mvn myquery:query@execution1
-#### Using the `<inherited>` Tag In Reporting Plugins
+#### Using the `\<inherited\>` Tag In Reporting Plugins
- Similar to the build plugins, to break the inheritance, you can use the `<inherited>` tag:
+ Similar to the build plugins, to break the inheritance, you can use the `\<inherited\>` tag:
diff --git a/content/markdown/guides/mini/guide-creating-archetypes.md b/content/markdown/guides/mini/guide-creating-archetypes.md
index 9bd1233f..db36c862 100644
--- a/content/markdown/guides/mini/guide-creating-archetypes.md
+++ b/content/markdown/guides/mini/guide-creating-archetypes.md
@@ -110,11 +110,11 @@ under the License.
- - `<requiredProperties>` : List of required properties to generate a project from this archetype
+ - `\<requiredProperties\>` : List of required properties to generate a project from this archetype
- - `<fileSets>` : File sets definition
+ - `\<fileSets\>` : File sets definition
- - `<modules>` : Modules definition
+ - `\<modules\>` : Modules definition
At this point one can only specify individual files to be created but not empty directories.
diff --git a/content/markdown/guides/mini/guide-default-execution-ids.md b/content/markdown/guides/mini/guide-default-execution-ids.md
index b354cc3d..f209957c 100644
--- a/content/markdown/guides/mini/guide-default-execution-ids.md
+++ b/content/markdown/guides/mini/guide-default-execution-ids.md
@@ -44,7 +44,7 @@ under the License.
### Default `executionId`s for Implied Executions
- When you consider the fact that the aforementioned configuration use cases are for mojos that are not explicitly mentioned in the POM, it's reasonable to refer to them as implied executions. But if they're implied, how can Maven allow users to provide configuration for them? The solution we've implemented is rather simple and low-tech, but should be more than adequate to handle even advanced use cases. Starting in Maven 2.2.0, each mojo invoked directly from the command line will have a [...]
+ When you consider the fact that the aforementioned configuration use cases are for mojos that are not explicitly mentioned in the POM, it's reasonable to refer to them as implied executions. But if they're implied, how can Maven allow users to provide configuration for them? The solution we've implemented is rather simple and low-tech, but should be more than adequate to handle even advanced use cases. Starting in Maven 2.2.0, each mojo invoked directly from the command line will have a [...]
#### Example: Command-line variant invocation of the assembly plugin
diff --git a/content/markdown/guides/mini/guide-http-settings.md b/content/markdown/guides/mini/guide-http-settings.md
index b786b1b9..7f078965 100644
--- a/content/markdown/guides/mini/guide-http-settings.md
+++ b/content/markdown/guides/mini/guide-http-settings.md
@@ -210,7 +210,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
Without this setting, PUT requests that require authentication transfer their entire payload to the server before that server issues an authentication challenge. In order to complete the PUT request, the client must then re-send the payload with the proper credentials specified in the HTTP headers. This results in twice the bandwidth usage, and twice the time to transfer each artifact.
- Another option to avoid this double transfer is what's known as preemptive authentication, which involves sending the authentication headers along with the original PUT request. However, there are a few potential issues with this approach. For one thing, in the event you have an unused `<server>` entry that specifies an invalid username/password combination, some servers may respond with a `401 Unauthorized` even if the server doesn't actually require any authentication for the request. [...]
+ Another option to avoid this double transfer is what's known as preemptive authentication, which involves sending the authentication headers along with the original PUT request. However, there are a few potential issues with this approach. For one thing, in the event you have an unused `\<server\>` entry that specifies an invalid username/password combination, some servers may respond with a `401 Unauthorized` even if the server doesn't actually require any authentication for the reques [...]
We'll discuss preemptive authentication in another example, below.
@@ -264,7 +264,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
</settings>
```
- For clarity, the other two sections are `<get>` for GET requests, and `<head>` for HEAD requests. I know that's going to be hard to remember...
+ For clarity, the other two sections are `\<get\>` for GET requests, and `\<head\>` for HEAD requests. I know that's going to be hard to remember...
@@ -334,15 +334,15 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
- 1 **booleans:** `%b,<value>`
+ 1 **booleans:** `%b,\<value\>`
- 1 **integer:** `%i,<value>`
+ 1 **integer:** `%i,\<value\>`
- 1 **long:** `%l,<value>` (yes, that's an 'L', not a '1')
+ 1 **long:** `%l,\<value\>` (yes, that's an 'L', not a '1')
- 1 **double:** `%d,<value>`
+ 1 **double:** `%d,\<value\>`
- 1 **collection of strings:** `%c,<value1>,<value2>,<value3>,...`, which could also be specified as:
+ 1 **collection of strings:** `%c,\<value1\>,\<value2\>,\<value3\>,...`, which could also be specified as:
```
%c,
@@ -412,7 +412,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
##### Example: Lifting auth scope restriction for external authentication systems
- Maven Wagon by default limits supplied credentials to the host:port combination scope, ignoring any other target servers. When the target server delegates authentication to an external system, you need to deliberately lift that scope limitation. Configure your server element to pass authentication to all target servers which challenge the client. +---+ _settings_ _servers_ _server_ _id_my-server_/id_ _configuration_ _basicAuthScope_ _host_ANY_/host_ _port_ANY_/port_ _!-- or even 443 to [...]
+ Maven Wagon by default limits supplied credentials to the host:port combination scope, ignoring any other target servers. When the target server delegates authentication to an external system, you need to deliberately lift that scope limitation. Configure your server element to pass authentication to all target servers which challenge the client. \+---\+ _settings_ _servers_ _server_ _id_my-server_/id_ _configuration_ _basicAuthScope_ _host_ANY_/host_ _port_ANY_/port_ _!-- or even 443 t [...]
@@ -526,7 +526,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
</settings>
```
- If all you need is a per-server timeout configuration, you still have the option to use the old `<timeout>` parameter. If you need to separate timeout preferences according to HTTP method, you can use one more like that specified directly above.
+ If all you need is a per-server timeout configuration, you still have the option to use the old `\<timeout\>` parameter. If you need to separate timeout preferences according to HTTP method, you can use one more like that specified directly above.
diff --git a/content/markdown/guides/mini/guide-large-scale-centralized-deployments.md b/content/markdown/guides/mini/guide-large-scale-centralized-deployments.md
index 235d162c..2ef58003 100644
--- a/content/markdown/guides/mini/guide-large-scale-centralized-deployments.md
+++ b/content/markdown/guides/mini/guide-large-scale-centralized-deployments.md
@@ -68,7 +68,7 @@ under the License.
- a hosted repository for snapshots
- - a hosted repository that can contain both releases and snapshots (Only needed if some projects are still using Maven Deploy Plugin < 2.8. See [Managing Uploads to the Repository Manager](Managing_Uploads_to_the_Repository_Manager) for more info.)
+ - a hosted repository that can contain both releases and snapshots (Only needed if some projects are still using Maven Deploy Plugin \< 2.8. See [Managing Uploads to the Repository Manager](Managing_Uploads_to_the_Repository_Manager) for more info.)
Separate hosted repositories are generally used for releases and snapshots due to the need for different artifact retention policies.
@@ -120,13 +120,13 @@ under the License.
All proprietary artifacts produced by Maven projects in the organization should be uploaded to the repository manager's hosted repositories.
- The [Maven Deploy Plugin](../../plugins/maven-deploy-plugin) can be instructed to upload artifacts to the repository manager's repositories by defining the `alt\*DeploymentRepository` properties in the Maven `settings.xml` file. When these properties are defined, the Maven Deploy Plugin's [deploy](../../plugins/maven-deploy-plugin/deploy-mojo.html) goal uses them instead of the `<distributionManagement>` section of `pom.xml` files to determine where to upload artifacts.
+ The [Maven Deploy Plugin](../../plugins/maven-deploy-plugin) can be instructed to upload artifacts to the repository manager's repositories by defining the `alt\*DeploymentRepository` properties in the Maven `settings.xml` file. When these properties are defined, the Maven Deploy Plugin's [deploy](../../plugins/maven-deploy-plugin/deploy-mojo.html) goal uses them instead of the `\<distributionManagement\>` section of `pom.xml` files to determine where to upload artifacts.
- Defining the upload destination of artifacts in `settings.xml` files rather than in the `<distributionManagement>` section of `pom.xml` files allows the destinations to be centrally managed, which simplifies maintenance if the destinations need to change. In other words, rather than changing a huge number of `pom.xml` files, you just need to change [relatively few](Settings_File_Locations) `settings.xml` files if/when the distribution locations need to change.
+ Defining the upload destination of artifacts in `settings.xml` files rather than in the `\<distributionManagement\>` section of `pom.xml` files allows the destinations to be centrally managed, which simplifies maintenance if the destinations need to change. In other words, rather than changing a huge number of `pom.xml` files, you just need to change [relatively few](Settings_File_Locations) `settings.xml` files if/when the distribution locations need to change.
- The ability to specify separate alternate deployment repositories for releases and snapshots via the `altReleaseDeploymentRepository` and `altSnapshotDeploymentRepository` properties, respectively, was added in Maven Deploy Plugin 2.8. To get the most out of the approach defined in this document, all projects should use Maven Deploy Plugin >=2.8. If some projects are still using an older version of Maven Deploy Plugin (>=2.3 and <2.8), then specify a single alternate deployment reposito [...]
+ The ability to specify separate alternate deployment repositories for releases and snapshots via the `altReleaseDeploymentRepository` and `altSnapshotDeploymentRepository` properties, respectively, was added in Maven Deploy Plugin 2.8. To get the most out of the approach defined in this document, all projects should use Maven Deploy Plugin \>\=2.8. If some projects are still using an older version of Maven Deploy Plugin (\>\=2.3 and \<2.8), then specify a single alternate deployment rep [...]
Typically, only continuous integration servers are allowed to upload artifacts to the repository manager. Therefore, these settings should only be specified in `settings.xml` files on continuous integration servers, and should not be in `settings.xml` files on developer machines. Alternatively, if you want developers to be able to upload artifacts to the repository manager, then include these properties in the `settings.xml` files used by developers.
diff --git a/content/markdown/guides/mini/guide-maven-classloading.md b/content/markdown/guides/mini/guide-maven-classloading.md
index f2d14366..3f4045d7 100644
--- a/content/markdown/guides/mini/guide-maven-classloading.md
+++ b/content/markdown/guides/mini/guide-maven-classloading.md
@@ -105,7 +105,7 @@ under the License.
<img src="../../buildExtensionClassRealm.svg" />Build Extension Class Realm
- For every plugin which is marked with `<extensions>true</extensions>` or a build extension listed in the according section of the POM, there is a dedicated classloader. Those are isolated. That is, one build extension does not have access to other build extensions. It imports everything from the API classloader. All JSR 330 or Plexus components declared in the underlying JAR are registered as components in the global Plexus container while creating the classloader. In addition all compo [...]
+ For every plugin which is marked with `\<extensions\>true\</extensions\>` or a build extension listed in the according section of the POM, there is a dedicated classloader. Those are isolated. That is, one build extension does not have access to other build extensions. It imports everything from the API classloader. All JSR 330 or Plexus components declared in the underlying JAR are registered as components in the global Plexus container while creating the classloader. In addition all c [...]
@@ -123,7 +123,7 @@ under the License.
Each plugin (which is not marked as build extension) has its own classloader that imports the Project classloader.
- Plugins marked with `<extensions>true</extensions>` leverage the Build Extension classloader instead of the Plugin classloader.
+ Plugins marked with `\<extensions\>true\</extensions\>` leverage the Build Extension classloader instead of the Plugin classloader.
Users can add dependencies to this classloader by adding dependencies to a plugin in the `[plugins/plugin](/ref/current/maven-model/maven.html#class_plugin)` section of their project `pom.xml`. Here is a sample of adding `ant-nodeps` to the plugin classloader of the Antrun Plugin and hereby enabling the use of additional/optional Ant tasks:
diff --git a/content/markdown/guides/mini/guide-mirror-settings.md b/content/markdown/guides/mini/guide-mirror-settings.md
index 3fc4d46d..1def66a2 100644
--- a/content/markdown/guides/mini/guide-mirror-settings.md
+++ b/content/markdown/guides/mini/guide-mirror-settings.md
@@ -56,7 +56,7 @@ under the License.
</settings>
```
- Note that there can be at most one mirror for a given repository. In other words, you cannot map a single repository to a group of mirrors that all define the same `<mirrorOf>` value. Maven will not aggregate the mirrors but simply picks the first match. If you want to provide a combined view of several repositories, use a [repository manager](../../repository-management.html) instead.
+ Note that there can be at most one mirror for a given repository. In other words, you cannot map a single repository to a group of mirrors that all define the same `\<mirrorOf\>` value. Maven will not aggregate the mirrors but simply picks the first match. If you want to provide a combined view of several repositories, use a [repository manager](../../repository-management.html) instead.
The settings descriptor documentation can be found on the [Maven Local Settings Model Website](../../maven-settings/settings.html).
@@ -78,7 +78,7 @@ under the License.
To achieve this, set `mirrorOf` to `\*`.
- **Note:** This feature is only available in Maven 2.0.5+.
+ **Note:** This feature is only available in Maven 2.0.5\+.
@@ -119,26 +119,26 @@ under the License.
- an exclamation mark may be used in conjunction with one of the above wildcards to exclude a repository id
- Be careful not to include extra whitespace around identifiers or wildcards in comma separated lists. For example, a mirror with `<mirrorOf`> set to `!repo1, *` will not mirror anything while `!repo1,*` will mirror everything but `repo1`.
+ Be careful not to include extra whitespace around identifiers or wildcards in comma separated lists. For example, a mirror with `\<mirrorOf`\> set to `!repo1, \*` will not mirror anything while `!repo1,\*` will mirror everything but `repo1`.
The position of wildcards within a comma separated list of repository identifiers is not important as the wildcards defer to further processing and explicit includes or excludes stop the processing, overruling any wildcard match.
- When you use the advanced syntax and configure multiple mirrors, the declaration order matters. When Maven looks for a mirror of some repository, it first checks for a mirror whose `<mirrorOf>` exactly matches the repository identifier. If no direct match is found, Maven picks the first mirror declaration that matches according to the rules above (if any). Hence, you may influence match order by changing the order of the definitions in the `settings.xml`
+ When you use the advanced syntax and configure multiple mirrors, the declaration order matters. When Maven looks for a mirror of some repository, it first checks for a mirror whose `\<mirrorOf\>` exactly matches the repository identifier. If no direct match is found, Maven picks the first mirror declaration that matches according to the rules above (if any). Hence, you may influence match order by changing the order of the definitions in the `settings.xml`
Examples:
- - `*` = everything
+ - `\*` \= everything
- - `external:*` = everything not on the localhost and not file based.
+ - `external:\*` \= everything not on the localhost and not file based.
- - `repo,repo1` = repo or repo1
+ - `repo,repo1` \= repo or repo1
- - `*,!repo1` = everything except repo1
+ - `\*,!repo1` \= everything except repo1
diff --git a/content/markdown/guides/mini/guide-multiple-modules.md b/content/markdown/guides/mini/guide-multiple-modules.md
index 8beff0a0..e42ef598 100644
--- a/content/markdown/guides/mini/guide-multiple-modules.md
+++ b/content/markdown/guides/mini/guide-multiple-modules.md
@@ -61,7 +61,7 @@ under the License.
- a build extension declaration on another module in the build
- - the order declared in the `<modules>` element (if no other rule applies)
+ - the order declared in the `\<modules\>` element (if no other rule applies)
Note that only "instantiated" references are used - `dependencyManagement` and `pluginManagement` elements do not cause a change to the reactor sort order.
diff --git a/content/markdown/guides/mini/guide-proxies.md b/content/markdown/guides/mini/guide-proxies.md
index 016915ce..ccd2f1e4 100644
--- a/content/markdown/guides/mini/guide-proxies.md
+++ b/content/markdown/guides/mini/guide-proxies.md
@@ -53,7 +53,7 @@ under the License.
```
- Please note that currently NTLM proxies are not supported as they have not been tested. You may be able to use the relevant system properties on JDK 1.4+ to make this work.
+ Please note that currently NTLM proxies are not supported as they have not been tested. You may be able to use the relevant system properties on JDK 1.4\+ to make this work.
### Resources
diff --git a/content/markdown/guides/mini/guide-releasing.md b/content/markdown/guides/mini/guide-releasing.md
index 61f7593e..7997c9c4 100644
--- a/content/markdown/guides/mini/guide-releasing.md
+++ b/content/markdown/guides/mini/guide-releasing.md
@@ -309,7 +309,7 @@ checkpoint.check-in-development-version=OK
#### I get a "The authenticity of host '_host_' can't be established." error and the build hangs
- This is because your `\~user/.ssh/known_hosts` file doesn't have the host listed. You'd normally get a prompt to add the host to the known host list but Maven doesn't propagate that prompt. The solution is to add the host the `known_hosts` file before executing Maven. On Windows, this can be done by installing an OpenSSH client (for example [SSHWindows](http://sshwindows.sourceforge.net/download/)), running `ssh <host>` and accepting to add the host.
+ This is because your `\~user/.ssh/known_hosts` file doesn't have the host listed. You'd normally get a prompt to add the host to the known host list but Maven doesn't propagate that prompt. The solution is to add the host the `known_hosts` file before executing Maven. On Windows, this can be done by installing an OpenSSH client (for example [SSHWindows](http://sshwindows.sourceforge.net/download/)), running `ssh \<host`\> and accepting to add the host.
diff --git a/content/markdown/guides/mini/guide-relocation.md b/content/markdown/guides/mini/guide-relocation.md
index 949f3bf2..e92bf55a 100644
--- a/content/markdown/guides/mini/guide-relocation.md
+++ b/content/markdown/guides/mini/guide-relocation.md
@@ -109,7 +109,7 @@ under the License.
1 has published its releases until 1.6.5 to Maven 1-compliant `ant:ant` coordinates (see [repository content](https://repo.maven.apache.org/maven2/ant/ant/)),
- 1 starting with 1.7.0, moved to reverse-DNS compliant Maven 2+ `org.apache.ant:ant` coordinates, (see [repository content](https://repo.maven.apache.org/maven2/org/apache/ant/ant/)),
+ 1 starting with 1.7.0, moved to reverse-DNS compliant Maven 2\+ `org.apache.ant:ant` coordinates, (see [repository content](https://repo.maven.apache.org/maven2/org/apache/ant/ant/)),
1 published one `ant:ant:1.7.0` relocation POM in old groupId to advertise about the move (see [repository content](https://repo.maven.apache.org/maven2/ant/ant/1.7.0/)).
@@ -124,7 +124,7 @@ under the License.
1 has published its releases until 3.0-alpha-3 to Maven 1-compliant `poi:poi` coordinates (see [repository content](https://repo.maven.apache.org/maven2/poi/poi/)),
- 1 starting with 3.0-FINAL, moved to reverse-DNS compliant Maven 2+ `org.apache.poi:poi` coordinates, (see [repository content](https://repo.maven.apache.org/maven2/org/apache/poi/poi/)),
+ 1 starting with 3.0-FINAL, moved to reverse-DNS compliant Maven 2\+ `org.apache.poi:poi` coordinates, (see [repository content](https://repo.maven.apache.org/maven2/org/apache/poi/poi/)),
1 published `poi:poi:3.0-FINAL` relocation POM **with jars** in old groupId to advertise about the move (see [repository content](https://repo.maven.apache.org/maven2/poi/poi/3.0-FINAL/)).
diff --git a/content/markdown/guides/mini/guide-reproducible-builds.md b/content/markdown/guides/mini/guide-reproducible-builds.md
index 5dfb89b0..3d96e5bf 100644
--- a/content/markdown/guides/mini/guide-reproducible-builds.md
+++ b/content/markdown/guides/mini/guide-reproducible-builds.md
@@ -47,7 +47,7 @@ mvn artifact:check-buildplan
```
- 1 Enable Reproducible Builds mode for plugins, by adding [`project.build.outputTimestamp` property](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318#Reproducible/VerifiableBuilds-OutputArchiveEntriesTimestamp) to the project's `pom.xml`:
+ 1 Enable Reproducible Builds mode for plugins, by adding [`project.build.outputTimestamp` property](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId\=74682318#Reproducible/VerifiableBuilds-OutputArchiveEntriesTimestamp) to the project's `pom.xml`:
```
<properties>
@@ -113,7 +113,7 @@ mvn clean verify artifact:compare
- Generally depend on the **major version of the JDK** used to compile. (Even with source/target defined, each major JDK version changes the generated bytecode)
- For detailed explanations, see [Maven "Reproducible/Verifiable Builds" Wiki page](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318).
+ For detailed explanations, see [Maven "Reproducible/Verifiable Builds" Wiki page](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId\=74682318).
@@ -170,7 +170,7 @@ mvn clean verify artifact:compare
|MojoHaus [properties-maven-plugin](https://www.mojohaus.org/properties-maven-plugin/)|1.1.0||
- For more details, see [Maven "Reproducible/Verifiable Builds" Wiki page](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318#Reproducible/VerifiableBuilds-Whataretheissuestosolve?)
+ For more details, see [Maven "Reproducible/Verifiable Builds" Wiki page](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId\=74682318#Reproducible/VerifiableBuilds-Whataretheissuestosolve?)
diff --git a/content/markdown/guides/mini/guide-site.md b/content/markdown/guides/mini/guide-site.md
index 7a8df717..a168471e 100644
--- a/content/markdown/guides/mini/guide-site.md
+++ b/content/markdown/guides/mini/guide-site.md
@@ -130,9 +130,9 @@ mvn site
```
- - the `<id>` element identifies the repository, so that you can attach credentials to it in your `settings.xml` file using the [ `<servers>` element](../../settings.html#Servers) as you would for any other repository,
+ - the `\<id\>` element identifies the repository, so that you can attach credentials to it in your `settings.xml` file using the [ `\<servers\>` element](../../settings.html#Servers) as you would for any other repository,
- - the `<url>` gives the location to deploy to. Currently, only SSH is supported by default, as above which copies to the host `www.mycompany.com` in the path `/www/docs/project/`, but you can [add more protocols as required](/plugins/maven-site-plugin/examples/adding-deploy-protocol.html). If subprojects inherit the site URL from a parent POM, they will automatically get their `<artifactId>` appended to form their effective deployment location.
+ - the `\<url\>` gives the location to deploy to. Currently, only SSH is supported by default, as above which copies to the host `www.mycompany.com` in the path `/www/docs/project/`, but you can [add more protocols as required](/plugins/maven-site-plugin/examples/adding-deploy-protocol.html). If subprojects inherit the site URL from a parent POM, they will automatically get their `\<artifactId\>` appended to form their effective deployment location.
Once distribution location is configured, deploying the site is done by using the `site-deploy` phase of the site lifecycle.
@@ -222,7 +222,7 @@ mvn site-deploy
```
<!-- TODO: deserves more explanation. -->
- **Note:** The `<menu ref="reports">` element above. When building the site, this is replaced by a menu with links to all the reports that you have configured.
+ **Note:** The `\<menu ref\="reports"/\>` element above. When building the site, this is replaced by a menu with links to all the reports that you have configured.
More information about the site descriptor is available at the [dedicated page of Maven Site Plugin](/plugins/maven-site-plugin/examples/sitedescriptor.html).
@@ -282,7 +282,7 @@ mvn site-deploy
To find out more please refer to the [Project Info Reports Plugin](../../plugins/maven-project-info-reports-plugin/).
- To add these reports to your site, you must add the Project Info Reports plugin to a special `<reporting>` section in the POM. The following example shows how to configure the standard project information reports that display information from the POM in a friendly format:
+ To add these reports to your site, you must add the Project Info Reports plugin to a special `\<reporting\>` section in the POM. The following example shows how to configure the standard project information reports that display information from the POM in a friendly format:
@@ -302,7 +302,7 @@ mvn site-deploy
</project>
```
- If you have included the appropriate `<menu ref="reports">` tag in your `site.xml` descriptor, then when you regenerate the site those items will appear in the menu.
+ If you have included the appropriate `\<menu ref\="reports"/\>` tag in your `site.xml` descriptor, then when you regenerate the site those items will appear in the menu.
Many other plugins provide reporting goals: look for "R" (Reporting) value in the "Type" column of the [ list of plugins](/plugins/). When plugins are both Build and Reporting plugins, defining explicitely the version in the reporting section is usually not necessary since reporting will use the version from `build/plugins` or `build/pluginManagement`. Since Maven Site Plugin 3.4, reporting plugin also get configuration from `build/pluginManagement`.
diff --git a/content/markdown/guides/mini/guide-using-extensions.md b/content/markdown/guides/mini/guide-using-extensions.md
index 0493b852..d5e15b36 100644
--- a/content/markdown/guides/mini/guide-using-extensions.md
+++ b/content/markdown/guides/mini/guide-using-extensions.md
@@ -44,7 +44,7 @@ under the License.
- Registered via extension jar in `$\{maven.home\}/lib/ext`
- - Registered via CLI argument `mvn -Dmaven.ext.class.path=extension.jar`
+ - Registered via CLI argument `mvn -Dmaven.ext.class.path\=extension.jar`
- Registered via [`.mvn/extensions.xml` file](../../configure.html#mvn-extensions-xml-file)
diff --git a/content/markdown/guides/mini/guide-using-toolchains.md b/content/markdown/guides/mini/guide-using-toolchains.md
index 66b6034f..5912a84c 100644
--- a/content/markdown/guides/mini/guide-using-toolchains.md
+++ b/content/markdown/guides/mini/guide-using-toolchains.md
@@ -108,10 +108,10 @@ under the License.
</plugins>
```
- As you can see in the example above, a JDK toolchain with `<version>` "1.5" and `<vendor>` "sun" is to be used. Now how does the plugin know where this JDK is installed? This is where the `toolchains.xml` file comes in.
+ As you can see in the example above, a JDK toolchain with `\<version\>` "1.5" and `\<vendor\>` "sun" is to be used. Now how does the plugin know where this JDK is installed? This is where the `toolchains.xml` file comes in.
- The `toolchains.xml` file (see below) is the configuration file where you set the installation paths of your toolchains. This file should be put in your `${user.home}/.m2` directory. When the `maven-toolchains-plugin` executes, it looks for the `toolchains.xml` file, reads it and looks for a toolchain matching the toolchains requirements configured in the plugin. In our example, that would be a JDK toolchain with `<version>` "1.5" and `<vendor>` "sun". Once a match is found, the plugin [...]
+ The `toolchains.xml` file (see below) is the configuration file where you set the installation paths of your toolchains. This file should be put in your `$\{user.home\}/.m2` directory. When the `maven-toolchains-plugin` executes, it looks for the `toolchains.xml` file, reads it and looks for a toolchain matching the toolchains requirements configured in the plugin. In our example, that would be a JDK toolchain with `\<version\>` "1.5" and `\<vendor\>` "sun". Once a match is found, the p [...]
Starting with [Maven 3.3.1](/docs/3.3.1/release-notes.html) you can put the `toolchains.xml` file wherever you like by using the `--global-toolchains file` option but it is recommended to locate it into `$\{user.home\}/.m2/`.
diff --git a/content/markdown/guides/mini/guide-wagon-providers.md b/content/markdown/guides/mini/guide-wagon-providers.md
index 5954fc63..4b582416 100644
--- a/content/markdown/guides/mini/guide-wagon-providers.md
+++ b/content/markdown/guides/mini/guide-wagon-providers.md
@@ -29,16 +29,16 @@ under the License.
Maven 2.2.0 attempted to amend this problem by switching over to a Wagon implementation that's based on Apache HttpClient. Unfortunately, it soon became apparent that HttpClient doesn't support NTLM (at least, version 2), which effectively means users behind NTLMv2 proxies cannot use Maven 2.2.0.
- To hopefully resolve this once and for all, Maven 2.2.1 will contain support for specifying which Wagon provider you want to use for a given protocol during the build. The provider name will then be appended to the protocol using the format `<protocol>-<provider>` to form the component role-hint for the Wagon.
+ To hopefully resolve this once and for all, Maven 2.2.1 will contain support for specifying which Wagon provider you want to use for a given protocol during the build. The provider name will then be appended to the protocol using the format `\<protocol\>-\<provider\>` to form the component role-hint for the Wagon.
- As of Maven 2.2.1, there are two ways to specify which Wagon provider should be used: via the command line, or in the `<server>` configuration section of the `settings.xml`.
+ As of Maven 2.2.1, there are two ways to specify which Wagon provider should be used: via the command line, or in the `\<server\>` configuration section of the `settings.xml`.
### Command-Line Configuration
- To specify the Wagon provider from the command line, simply use the `-Dmaven.wagon.provider.<protocol>=<provider-name>` command-line option, like the following:
+ To specify the Wagon provider from the command line, simply use the `-Dmaven.wagon.provider.\<protocol\>\=\<provider-name\>` command-line option, like the following:
@@ -53,7 +53,7 @@ mvn -Dmaven.wagon.provider.http=httpclient clean install
### `settings.xml` Configuration
- To specify which Wagon provider to use for a particular server, modify your `settings.xml` file to add the `<wagonProvider>` configuration to your `<server>` entry, like the following:
+ To specify which Wagon provider to use for a particular server, modify your `settings.xml` file to add the `\<wagonProvider\>` configuration to your `\<server\>` entry, like the following:
@@ -74,7 +74,7 @@ mvn -Dmaven.wagon.provider.http=httpclient clean install
### Available Wagon Providers
- Maven 2.2.1 provides two providers for HTTP/HTTPS Wagons: `lightweight` and `httpclient`. If you add a new HTTP Wagon implementation via build extension, you'll need to make sure the extension binds its Wagon components to role-hints of the form `<protocol>-<provider>` in order to allow users to specify your alternative Wagon provider. For instance, the HttpClient HTTP Wagon component definition looks like this:
+ Maven 2.2.1 provides two providers for HTTP/HTTPS Wagons: `lightweight` and `httpclient`. If you add a new HTTP Wagon implementation via build extension, you'll need to make sure the extension binds its Wagon components to role-hints of the form `\<protocol\>-\<provider\>` in order to allow users to specify your alternative Wagon provider. For instance, the HttpClient HTTP Wagon component definition looks like this:
diff --git a/content/markdown/guides/plugin/guide-java-plugin-development.md b/content/markdown/guides/plugin/guide-java-plugin-development.md
index e818f88f..d5550dd1 100644
--- a/content/markdown/guides/plugin/guide-java-plugin-development.md
+++ b/content/markdown/guides/plugin/guide-java-plugin-development.md
@@ -69,10 +69,10 @@ under the License.
### Important Notice: [Plugin Naming Convention and Apache Maven Trademark](../mini/guide-naming-conventions.html)
- You will typically name your plugin `<yourplugin>-maven-plugin`.
+ You will typically name your plugin `\<yourplugin\>-maven-plugin`.
- Calling it `maven-<yourplugin>-plugin` (note "Maven" is at the beginning of the plugin name) is **strongly discouraged** since it's a **reserved naming pattern for official Apache Maven plugins maintained by the Apache Maven team** with groupId `org.apache.maven.plugins`. Using this naming pattern is an infringement of the Apache Maven Trademark.
+ Calling it `maven-\<yourplugin\>-plugin` (note "Maven" is at the beginning of the plugin name) is **strongly discouraged** since it's a **reserved naming pattern for official Apache Maven plugins maintained by the Apache Maven team** with groupId `org.apache.maven.plugins`. Using this naming pattern is an infringement of the Apache Maven Trademark.
diff --git a/content/markdown/guides/plugin/guide-java-report-plugin-development.md b/content/markdown/guides/plugin/guide-java-report-plugin-development.md
index 41eae439..9da83e57 100644
--- a/content/markdown/guides/plugin/guide-java-report-plugin-development.md
+++ b/content/markdown/guides/plugin/guide-java-report-plugin-development.md
@@ -39,7 +39,7 @@ under the License.
- 1 A regular Maven project usually invokes _reporting goals_ of a plugin by declaring such plugin in the [`<reporting>`](/plugins/maven-site-plugin/examples/configuring-reports.html) section of its `pom.xml` as in the example below:
+ 1 A regular Maven project usually invokes _reporting goals_ of a plugin by declaring such plugin in the [`\<reporting\>`](/plugins/maven-site-plugin/examples/configuring-reports.html) section of its `pom.xml` as in the example below:
```
<project>
@@ -398,7 +398,7 @@ simple:simple
#### Invoking the Simple Plugin
- To invoke the _report Mojo_ of our plugin in another Maven project, we just need to declare the plugin in the [`<reporting>`](/plugins/maven-site-plugin/examples/configuring-reports.html) section of its `pom.xml` as in the example below:
+ To invoke the _report Mojo_ of our plugin in another Maven project, we just need to declare the plugin in the [`\<reporting\>`](/plugins/maven-site-plugin/examples/configuring-reports.html) section of its `pom.xml` as in the example below:
diff --git a/content/markdown/maven-jsr330.md b/content/markdown/maven-jsr330.md
index 0ce05fbc..402f12d1 100644
--- a/content/markdown/maven-jsr330.md
+++ b/content/markdown/maven-jsr330.md
@@ -25,10 +25,10 @@ uses - since 3.0-beta-3 - is named [Sisu][sisu] and is based on [Guice 3.x][guic
If you are using [Plexus annotations and APIs][plexus-container] currently,
there is no rush to switch and no big bang conversions are necessary: Plexus, JSR-330 and Guice APIs all happily
-co-exist within Maven's core and you can choose to use JSR-330 when you wish. There are hundreds of components
+co-exist within Maven\'s core and you can choose to use JSR-330 when you wish. There are hundreds of components
written using the Plexus APIs.
-If you want to use JSR-330, you must understand that your code won't be compatible with Maven 3.0.x
+If you want to use JSR-330, you must understand that your code won\'t be compatible with Maven 3.0.x
but only with Maven 3.1.0 and later. Even though JSR-330 has been available in core since Maven 3.0-beta-3, it was made available to plugins and
extensions only in Maven 3.1.0 (see [MNG-5343][MNG-5343] for more details).
@@ -58,7 +58,7 @@ org.apache.maven.lifecycle.profiler.internal.DefaultSessionProfileRenderer
org.apache.maven.lifecycle.profiler.internal.DefaultTimer
```
-Enumerating the implementations means that no classpath scanning is required in runtime to find them, which keeps Maven's
+Enumerating the implementations means that no classpath scanning is required in runtime to find them, which keeps Maven\'s
startup time fast. Note that our container is configured by default to only use the index. While this keeps things fast,
if you use JSR-330 components in dependencies that do not contain an index, those implementations will currently
not be discovered. This is a compromise that is reasonable given Maven is a command-line tool where startup speed
@@ -66,11 +66,11 @@ is important.
## How to use JSR-330 in extensions
-Let's take a look at an example extension. We'll take a look at the POM, and a little bit of the implementation
-so you can get an idea of how JSR-330 extensions work. Really, it's just a simple JSR-330 component.
+Let\'s take a look at an example extension. We\'ll take a look at the POM, and a little bit of the implementation
+so you can get an idea of how JSR-330 extensions work. Really, it\'s just a simple JSR-330 component.
If you want to look at the full implementation, you can find it [here][tesla-profiler] on Github.
-Ok, so let's take a look at the POM:
+Ok, so let\'s take a look at the POM:
```xml
<?xml version="1.0"?>
@@ -220,7 +220,7 @@ public class LifecycleProfiler extends AbstractEventSpy {
## How to use JSR-330 in plugins
-Let's take a look at an example plugin. The POM is setup in a similar way to an extension, but we add a dependency
+Let\'s take a look at an example plugin. The POM is setup in a similar way to an extension, but we add a dependency
to `maven-plugin-api` and `maven-plugin-annotations` to extend the `AbstractMojo` and use the Java 5 plugin
annotations in our example.
@@ -310,7 +310,7 @@ annotations in our example.
</project>
```
-Now let's take a look at the plugin code. You'll notice that we're using constructor injection
+Now let\'s take a look at the plugin code. You\'ll notice that we\'re using constructor injection
which makes testing a lot easier. If you want to test your `Jsr330Component`, you do not need the container
to instantiate the `Mojo`. In this simple case, you can actually test this plugin without using the plugin
testing harness because you can instantiate the `Jsr330Component` and `Jsr330Mojo` directly and wire
diff --git a/content/markdown/maven-logging.md b/content/markdown/maven-logging.md
index c218f8ac..918fab4d 100644
--- a/content/markdown/maven-logging.md
+++ b/content/markdown/maven-logging.md
@@ -22,7 +22,7 @@ to stdout.
We have reached the decision that [SLF4J][1] is the best option for a logging API:
SLF4J has reached a certain level of ubiquity and while SLF4J may not be perfect,
-it's the de facto standard and it's pointless to try and remake another one.
+it\'s the de facto standard and it\'s pointless to try and remake another one.
There are many implementations to choose from, including [Logback][4] and [Log4j2][3].
All the hard work has been done. All the bridges and funnels for other systems function well,
which allows others to use whatever logging implementation they like in their components,
diff --git a/content/markdown/plugin-developers/common-bugs.md b/content/markdown/plugin-developers/common-bugs.md
index 95d21d2c..92acb1b3 100644
--- a/content/markdown/plugin-developers/common-bugs.md
+++ b/content/markdown/plugin-developers/common-bugs.md
@@ -77,9 +77,9 @@ Reader reader = new FileReader( javaFile );
- - [Source File Encoding](https://cwiki.apache.org/confluence/display/MAVEN/POM+Element+for+Source+File+Encoding)
+ - [Source File Encoding](https://cwiki.apache.org/confluence/display/MAVEN/POM\+Element\+for\+Source\+File\+Encoding)
- - [Report Output Encoding](http://cwiki.apache.org/confluence/display/MAVENOLD/Reporting+Encoding+Configuration)
+ - [Report Output Encoding](http://cwiki.apache.org/confluence/display/MAVENOLD/Reporting\+Encoding\+Configuration)
Finally note that XML files require special handling because they are equipped with an encoding declaration in the XML prolog. Reading or writing XML files with an encoding that does not match their XML prolog's `encoding` attribute is a bad idea:
@@ -138,10 +138,10 @@ URL url = new URL( "file:/C:/Program%20Files/Java/bin/java.exe" );
File path = new File( url.getPath() );
```
- To decode a URL, people sometimes also choose `[java.net.URLDecoder](http://java.sun.com/javase/6/docs/api/java/net/URLDecoder.html)`. The pitfall with this class is that is actually performs HTML form decoding which is yet another encoding and not the same as the URL encoding (compare the last paragraph in class javadoc about `[java.net.URL](http://java.sun.com/javase/6/docs/api/java/net/URL.html)`). For instance, a `URLDecoder` will erroneously convert the character "+" into a space a [...]
+ To decode a URL, people sometimes also choose `[java.net.URLDecoder](http://java.sun.com/javase/6/docs/api/java/net/URLDecoder.html)`. The pitfall with this class is that is actually performs HTML form decoding which is yet another encoding and not the same as the URL encoding (compare the last paragraph in class javadoc about `[java.net.URL](http://java.sun.com/javase/6/docs/api/java/net/URL.html)`). For instance, a `URLDecoder` will erroneously convert the character "\+" into a space [...]
- In an ideal world, code targetting JRE 1.4+ could easily avoid these problems by using the constructor `[File(URI)](http://java.sun.com/javase/6/docs/api/java/io/File.html#File(java.net.URI))` as suggested by the following snippet:
+ In an ideal world, code targetting JRE 1.4\+ could easily avoid these problems by using the constructor `[File(URI)](http://java.sun.com/javase/6/docs/api/java/io/File.html#File(java.net.URI))` as suggested by the following snippet:
@@ -209,14 +209,14 @@ src/
Now, if a resource bundle is to be looked up for English on a JVM whose default locale happens to be French, the bundle `mymojo-report_fr.properties` will be loaded instead of the intended bundle `mymojo-report.properties`.
- Reporting plugins that suffer from this bug can easily be detected by executing `mvn site -D locales=xy,en` where `xy` denotes any other language code supported by the particular plugin. Specifying `xy` as the first locale will have the Maven Site Plugin change the JVM's default locale to `xy` which in turn causes the lookup for `en` to fail as outlined above unless the plugin has a dedicated resource bundle for English.
+ Reporting plugins that suffer from this bug can easily be detected by executing `mvn site -D locales\=xy,en` where `xy` denotes any other language code supported by the particular plugin. Specifying `xy` as the first locale will have the Maven Site Plugin change the JVM's default locale to `xy` which in turn causes the lookup for `en` to fail as outlined above unless the plugin has a dedicated resource bundle for English.
### Using System Properties
- Maven's command line supports the definition of system properties via arguments of the form `-D key=value`. While these properties are called system properties, plugins should never use `[System.getProperty()](http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperty(java.lang.String))` and related methods to query these properties. For example, the following code snippet will not work reliably when Maven is embedded, say into an IDE or a CI server:
+ Maven's command line supports the definition of system properties via arguments of the form `-D key\=value`. While these properties are called system properties, plugins should never use `[System.getProperty()](http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperty(java.lang.String))` and related methods to query these properties. For example, the following code snippet will not work reliably when Maven is embedded, say into an IDE or a CI server:
@@ -403,7 +403,7 @@ public MyMojo extends AbstractMojo
}
```
- In case of the logger, the above mojo will simply use a default console logger, i.e. the code defect is not immediately noticeable by a `NullPointerException`. This default logger will however use a different message format for its output and also outputs debug messages even if Maven's debug mode was not enabled. For this reason, developers must not try to cache the logger during construction time. The method `getLog()` is fast enough and can simply be called whenever one needs it. +---
+ In case of the logger, the above mojo will simply use a default console logger, i.e. the code defect is not immediately noticeable by a `NullPointerException`. This default logger will however use a different message format for its output and also outputs debug messages even if Maven's debug mode was not enabled. For this reason, developers must not try to cache the logger during construction time. The method `getLog()` is fast enough and can simply be called whenever one needs it. \+---
diff --git a/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md b/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
index 3a0436c3..dd79debb 100644
--- a/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
+++ b/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
@@ -38,7 +38,7 @@ under the License.
1 update sources with [Java Annotations for Plexus](https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/).
- **Notice**: if you're targeting components for Maven 3.1.0+, using [`@Named`/`@Inject` JSR-330 annotations](/maven-jsr330.html) instead of `@Component`/`@Requirement` Plexus Java Annotations may be a good next step
+ **Notice**: if you're targeting components for Maven 3.1.0\+, using [`@Named`/`@Inject` JSR-330 annotations](/maven-jsr330.html) instead of `@Component`/`@Requirement` Plexus Java Annotations may be a good next step
diff --git a/content/markdown/plugin-developers/plugin-documenting.md b/content/markdown/plugin-developers/plugin-documenting.md
index 66d56f7d..dcd6dc5c 100644
--- a/content/markdown/plugin-developers/plugin-documenting.md
+++ b/content/markdown/plugin-developers/plugin-documenting.md
@@ -46,6 +46,6 @@ mvn docck:check
- - [Maven Plugin Documentation](http://cwiki.apache.org/confluence/display/MAVENOLD/Maven+Plugin+Documentation)
+ - [Maven Plugin Documentation](http://cwiki.apache.org/confluence/display/MAVENOLD/Maven\+Plugin\+Documentation)
diff --git a/content/markdown/plugin-developers/plugin-testing.md b/content/markdown/plugin-developers/plugin-testing.md
index 6080159c..0dc417e6 100644
--- a/content/markdown/plugin-developers/plugin-testing.md
+++ b/content/markdown/plugin-developers/plugin-testing.md
@@ -121,7 +121,7 @@ public class YourMojoTest
}
```
- For more information, refer to [Maven Plugin Harness Wiki](http://cwiki.apache.org/confluence/display/MAVENOLD/Maven+Plugin+Harness)
+ For more information, refer to [Maven Plugin Harness Wiki](http://cwiki.apache.org/confluence/display/MAVENOLD/Maven\+Plugin\+Harness)
@@ -135,7 +135,7 @@ public class YourMojoTest
maven-verifier tests are run using JUnit or TestNG, and provide a simple class allowing you to launch Maven and assert on its log file and built artifacts. It also provides a ResourceExtractor, which extracts a Maven project from your src/test/resources directory into a temporary working directory where you can do tricky stuff with it. Follow the [Getting Started](/shared/maven-verifier/getting-started.html) guide to learn more about creating maven-verifier tests.
- Maven itself uses maven-verifier to run its core integration tests. For more information, please refer to [Creating a Maven Integration Test](https://cwiki.apache.org/confluence/display/MAVEN/Creating+a+Maven+Integration+Test).
+ Maven itself uses maven-verifier to run its core integration tests. For more information, please refer to [Creating a Maven Integration Test](https://cwiki.apache.org/confluence/display/MAVEN/Creating\+a\+Maven\+Integration\+Test).
**Note**: maven-verifier and maven-verifier-plugin sound similar, but are totally different unrelated pieces of code. maven-verifier-plugin simply verifies the existence/absence of files on the filesystem. You could use it for functional testing, but you may need more features than maven-verifier-plugin provides.
diff --git a/content/markdown/plugins/index.md b/content/markdown/plugins/index.md
index 484bd08b..45e04b5e 100644
--- a/content/markdown/plugins/index.md
+++ b/content/markdown/plugins/index.md
@@ -27,9 +27,9 @@ under the License.
- - **Build plugins** will be executed during the build and they should be configured in the `<build>` element from the POM.
+ - **Build plugins** will be executed during the build and they should be configured in the `\<build/\>` element from the POM.
- - **Reporting plugins** will be executed during the site generation and they should be configured in the `<reporting>` element from the POM. Because the result of a Reporting plugin is part of the generated site, Reporting plugins should be both internationalized and localized. You can read more about the [localization of our plugins](./localization.html) and how you can help.
+ - **Reporting plugins** will be executed during the site generation and they should be configured in the `\<reporting/\>` element from the POM. Because the result of a Reporting plugin is part of the generated site, Reporting plugins should be both internationalized and localized. You can read more about the [localization of our plugins](./localization.html) and how you can help.
### Supported By The Maven Project
diff --git a/content/markdown/plugins/localization.md b/content/markdown/plugins/localization.md
index 51b6d210..fd2b1ddd 100644
--- a/content/markdown/plugins/localization.md
+++ b/content/markdown/plugins/localization.md
@@ -121,16 +121,16 @@ native2ascii checkstyle-report_es.properties checkstyle-report_es-encoded.proper
- [cpdetector](http://cpdetector.sourceforge.net/)
- - [IntelliJ IDEA ShowEncodingPlugin](http://plugins.intellij.net/plugin/?id=24)
+ - [IntelliJ IDEA ShowEncodingPlugin](http://plugins.intellij.net/plugin/?id\=24)
- - [Notepad++](http://notepad-plus.sourceforge.net/)
+ - [Notepad\+\+](http://notepad-plus.sourceforge.net/)
#### Tools to write a file in a given charset
- Any editor like Notepad++, Eclipse, IntelliJ IDEA, ...
+ Any editor like Notepad\+\+, Eclipse, IntelliJ IDEA, ...
@@ -140,7 +140,7 @@ native2ascii checkstyle-report_es.properties checkstyle-report_es-encoded.proper
- Unix `iconv` command
- - Notepad++
+ - Notepad\+\+
diff --git a/content/markdown/repository/central-index.md b/content/markdown/repository/central-index.md
index c4b6dfed..e104e72d 100644
--- a/content/markdown/repository/central-index.md
+++ b/content/markdown/repository/central-index.md
@@ -23,7 +23,7 @@ under the License.
## Central Index
- Central repository provides [an index](https://repo.maven.apache.org/maven2/.index/) that is updated weekly as full (`nexus-maven-repository-index.gz`) and incremental (`nexus-maven-repository-index.<n>.gz` + `nexus-maven-repository-index.properties`).
+ Central repository provides [an index](https://repo.maven.apache.org/maven2/.index/) that is updated weekly as full (`nexus-maven-repository-index.gz`) and incremental (`nexus-maven-repository-index.\<n\>.gz` \+ `nexus-maven-repository-index.properties`).
This index is build using [Maven Indexer](/maven-indexer/): see [LATEST indexer-core documentation](/maven-indexer-archives/maven-indexer-LATEST/indexer-core/) for more details on the fields that are available.
diff --git a/content/markdown/settings.md b/content/markdown/settings.md
index 1ff140e9..7a3dde0b 100644
--- a/content/markdown/settings.md
+++ b/content/markdown/settings.md
@@ -367,7 +367,7 @@ all accessible from the `settings.xml` file:
4. Java System Properties: All properties accessible via
`java.lang.System.getProperties()` are available as POM properties,
such as `${java.home}`.
-5. `x`: Set within a `<properties\>` element or an external files, the
+5. `x`: Set within a \<properties /\> element or an external files, the
value may be used as `${someVar}`.
<!-- -->
[maven-site] 12/14: Revert "[MNGSITE-507] [DOXIA-692] Improve conversion results - part2"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit 10d6f9d9a1985862c407950ff0830afc82aec2eb
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:35:01 2023 +0100
Revert "[MNGSITE-507] [DOXIA-692] Improve conversion results - part2"
This reverts commit df48f659351cff7e71f0e46fabc4617db6ac451f.
---
content/markdown/developers/committer-settings.md | 2 +-
content/markdown/faq-unoffical.md | 22 +++++++++++-----------
.../guide-testing-development-plugins.md | 2 +-
content/markdown/guides/getting-started/index.md | 18 +++++++++---------
.../getting-started/windows-prerequisites.md | 4 ++--
.../introduction-to-dependency-mechanism.md | 2 +-
.../introduction-to-plugin-prefix-mapping.md | 10 +++++-----
.../guides/introduction/introduction-to-plugins.md | 2 +-
.../introduction/introduction-to-profiles.md | 6 +++---
.../guides/introduction/introduction-to-the-pom.md | 2 +-
.../guides/mini/guide-3rd-party-jars-remote.md | 2 +-
content/markdown/guides/mini/guide-assemblies.md | 2 +-
.../markdown/guides/mini/guide-attached-tests.md | 2 +-
.../guides/mini/guide-configuring-maven.md | 4 ++--
.../guides/mini/guide-creating-archetypes.md | 2 +-
content/markdown/guides/mini/guide-encryption.md | 10 +++++-----
.../guides/mini/guide-maven-classloading.md | 8 ++++----
.../markdown/guides/mini/guide-mirror-settings.md | 2 +-
.../guides/mini/guide-multiple-repositories.md | 2 +-
content/markdown/guides/mini/guide-proxies.md | 2 +-
.../guides/mini/guide-reproducible-builds.md | 2 +-
content/markdown/guides/mini/guide-site.md | 2 +-
.../markdown/guides/mini/guide-snippet-macro.md | 2 +-
.../markdown/guides/mini/guide-using-extensions.md | 2 +-
.../markdown/guides/mini/guide-using-toolchains.md | 2 +-
.../guides/plugin/guide-java-plugin-development.md | 6 +++---
content/markdown/plugin-developers/common-bugs.md | 4 ++--
.../cookbook/plexus-plugin-upgrade.md | 2 +-
28 files changed, 64 insertions(+), 64 deletions(-)
diff --git a/content/markdown/developers/committer-settings.md b/content/markdown/developers/committer-settings.md
index d979a678..b5d3ef74 100644
--- a/content/markdown/developers/committer-settings.md
+++ b/content/markdown/developers/committer-settings.md
@@ -24,7 +24,7 @@ under the License.
## Introduction
- This document is intended to set up the Maven committer settings, i.e. the `${user.home}/.m2/settings.xml`.
+ This document is intended to set up the Maven committer settings, i.e. the `$\{user.home\}/.m2/settings.xml`.
### Enable Apache Servers
diff --git a/content/markdown/faq-unoffical.md b/content/markdown/faq-unoffical.md
index 4adb12de..b4d3f0bd 100644
--- a/content/markdown/faq-unoffical.md
+++ b/content/markdown/faq-unoffical.md
@@ -234,7 +234,7 @@ NOTE: I fixed this behavior in Maven's trunk; previously, it had been putting th
So, to recap:
parent:
-```xml
+```
<configuration>
<items>
<item>one</item>
@@ -608,8 +608,8 @@ _Plugins and Lifecycle, Sites & Reporting_
### How do I integrate static (x)html into my Maven site?
You can integrate your static pages in this several steps,
-* Put your static pages in the resources directory, ${basedir}/src/site/resources.
-* Create your site.xml and put it in `${basedir}/src/site`. An example below:
+* Put your static pages in the resources directory, $\{basedir\}/src/site/resources.
+* Create your site.xml and put it in $\{basedir\}/src/site. An example below:
```
<project name="Maven War Plugin">
<bannerLeft>
@@ -935,7 +935,7 @@ _Sites & Reporting, General_
### How do I create a command line parameter (i.e., \-Dname=value ) in my mojo?
-In your mojo, put `expression=${<exp>}` in your parameter field
+In your mojo, put `expression=$\{<exp>\}` in your parameter field
```
/**
@@ -1084,7 +1084,7 @@ To do so, simply add the following fragment to your pom:
Now, to specify a different output directory at runtime simply use the directory property as a mvn command line parameter;
{code}mvn -Ddirectory=tmp package
```
-This will send the build's output files to the ${basedir}/tmp directory.
+This will send the build's output files to the $\{basedir}/tmp directory.
_POM, Command Line_
@@ -1213,7 +1213,7 @@ _Plugins and Lifecycle, IDEs_
### What does aggregator mean in mojo?
-When a Mojo has a `@aggregator` expression, it means that It can only build the parent project of your multi-module-project, the one who has the packaging of pom. It can also give you values for the expression `${reactorProjects}` where reactorProjects are the MavenProject references to the parent pom modules.
+When a Mojo has a `@aggregator` expression, it means that It can only build the parent project of your multi-module-project, the one who has the packaging of pom. It can also give you values for the expression $\{reactorProjects\} where reactorProjects are the MavenProject references to the parent pom modules.
### Why there are no dependency properties in Maven?
@@ -1382,8 +1382,8 @@ Use the `inherited` property. Set it to `false` in the plugin configuration. So
### How can I reference windows or unix environment variables in my POM?
Starting in maven *2.0.1*, you can reference windows and unix environment variables inside your pom.xml or settings.xml using an expression of the form:
-`${env.VARNAME}`
-So, if you wanted to reference your home directory environment variable, you might use: `${env.HOME}`
+`$\{env.VARNAME\}`
+So, if you wanted to reference your home directory environment variable, you might use: `$\{env.HOME\}`
### How do I know which phase a plug-in is associated with?
@@ -1456,7 +1456,7 @@ When specifying a war as dependency, make sure that you have set the `<type>` to
### How can I change the default location of the generated jar when I command "mvn package"?
-By default, the location of the generated jar is in `${project.build.directory}` or in your target directory.
+By default, the location of the generated jar is in $\{project.build.directory\} or in your target directory.
We can change this by configuring the outputDirectory of maven-jar-plugin.
```
<plugin>
@@ -1595,7 +1595,7 @@ Note: You don't have to define the central repo (i.e. ibiblio).
### Is it possible to exclude a package from the generated jar file?
-You can configure maven-compiler-plugin to exclude your unwanted packages or files to be compiled in the first place. But you will not be able to prevent javac to compile those files if they are referenced by other packages within the source tree. To prevent that, you will need to use antrun plugin ( or write your own custom plugin), bind it to compile phase, and remove unwanted classes in `${project.build.directory}/classes`. If possible, just move those pacakges/files to another source [...]
+You can configure maven-compiler-plugin to exclude your unwanted packages or files to be compiled in the first place. But you will not be able to prevent javac to compile those files if they are referenced by other packages within the source tree. To prevent that, you will need to use antrun plugin ( or write your own custom plugin), bind it to compile phase, and remove unwanted classes in $\{project.build.directory\}/classes. If possible, just move those pacakges/files to another source [...]
### How should I point a path for Maven to use a certain version of JDK when I have different versions of JDK installed on my PC and my JAVA_HOME already set?
@@ -1770,7 +1770,7 @@ pom.xml > project scope
```
### What is reactorProjects? executedProject?
-`${reactorProjects}` are the projects that the current mvn command are going to be built. This will include the parent project and all its children while `${executedProject}` is the project where you typed your mvn command.
+$\{reactorProjects} are the projects that the current mvn command are going to be built. This will include the parent project and all its children while $\{executedProject} is the project where you typed your mvn command.
### What is a Snapshot?
diff --git a/content/markdown/guides/development/guide-testing-development-plugins.md b/content/markdown/guides/development/guide-testing-development-plugins.md
index 5dfe52be..e1b5a95e 100644
--- a/content/markdown/guides/development/guide-testing-development-plugins.md
+++ b/content/markdown/guides/development/guide-testing-development-plugins.md
@@ -103,7 +103,7 @@ under the License.
If you are using the goals from the command line on a number of projects, you should include this in your `settings.xml` file instead.
- You need to modify your `${user.home}/.m2/settings.xml` file to include two new profiles and then when you need access to the plugin snapshots use `-Papache`. The profile only needs to be enabled once so that the plugins can be downloaded into you local repository. Once in your local repository Maven can successfully resolve the dependencies and the profile no longer needs to be activated.
+ You need to modify your `$\{user.home\}/.m2/settings.xml` file to include two new profiles and then when you need access to the plugin snapshots use `-Papache`. The profile only needs to be enabled once so that the plugins can be downloaded into you local repository. Once in your local repository Maven can successfully resolve the dependencies and the profile no longer needs to be activated.
diff --git a/content/markdown/guides/getting-started/index.md b/content/markdown/guides/getting-started/index.md
index 443ed0e1..8e215169 100644
--- a/content/markdown/guides/getting-started/index.md
+++ b/content/markdown/guides/getting-started/index.md
@@ -217,7 +217,7 @@ my-app
`-- AppTest.java
```
- As you can see, the project created from the archetype has a POM, a source tree for your application's sources and a source tree for your test sources. This is the standard layout for Maven projects (the application sources reside in `${basedir}/src/main/java` and test sources reside in `${basedir}/src/test/java`, where `${basedir}` represents the directory containing `pom.xml`).
+ As you can see, the project created from the archetype has a POM, a source tree for your application's sources and a source tree for your test sources. This is the standard layout for Maven projects (the application sources reside in `$\{basedir\}/src/main/java` and test sources reside in `$\{basedir\}/src/test/java`, where $\{basedir\} represents the directory containing `pom.xml`).
If you were to create a Maven project by hand this is the directory structure that we recommend using. This is a Maven convention and to learn more about it you can read our [Introduction to the Standard Directory Layout](../introduction/introduction-to-the-standard-directory-layout.html).
@@ -267,7 +267,7 @@ mvn compile
The first time you execute this (or any other) command, Maven will need to download all the plugins and related dependencies it needs to fulfill the command. From a clean installation of Maven, this can take quite a while (in the output above, it took almost 4 minutes). If you execute the command again, Maven will now have what it needs, so it won't need to download anything new and will be able to execute the command much more quickly.
- As you can see from the output, the compiled classes were placed in `${basedir}/target/classes`, which is another standard convention employed by Maven. So, if you're a keen observer, you'll notice that by using the standard conventions, the POM above is very small and you haven't had to tell Maven explicitly where any of your sources are or where the output should go. By following the standard Maven conventions, you can get a lot done with very little effort! Just as a casual compariso [...]
+ As you can see from the output, the compiled classes were placed in `$\{basedir\}/target/classes`, which is another standard convention employed by Maven. So, if you're a keen observer, you'll notice that by using the standard conventions, the POM above is very small and you haven't had to tell Maven explicitly where any of your sources are or where the output should go. By following the standard Maven conventions, you can get a lot done with very little effort! Just as a casual compari [...]
Now, this is simply to compile a single tree of application sources and the Ant script shown is pretty much the same size as the POM shown above. But we'll see how much more we can do with just that simple POM!
@@ -367,10 +367,10 @@ mvn test
mvn package
```
- You can now take a look in the `${basedir}/target` directory and you will see the generated JAR file.
+ You can now take a look in the `$\{basedir\}/target` directory and you will see the generated JAR file.
- Now you'll want to install the artifact you've generated (the JAR file) in your local repository (`${user.home}/.m2/repository` is the default location). For more information on repositories you can refer to our [Introduction to Repositories](../introduction/introduction-to-repositories.html) but let's move on to installing our artifact! To do so execute the following command:
+ Now you'll want to install the artifact you've generated (the JAR file) in your local repository (`$\{user.home\}/.m2/repository` is the default location). For more information on repositories you can refer to our [Introduction to Repositories](../introduction/introduction-to-repositories.html) but let's move on to installing our artifact! To do so execute the following command:
@@ -541,7 +541,7 @@ mvn clean
Another common use case that can be satisfied which requires no changes to the POM that we have above is packaging resources in the JAR file. For this common task, Maven again relies on the [Standard Directory Layout](../introduction/introduction-to-the-standard-directory-layout.html), which means by using standard Maven conventions you can package resources within JARs simply by placing those resources in a standard directory structure.
- You see below in our example we have added the directory `${basedir}/src/main/resources` into which we place any resources we wish to package in our JAR. The simple rule employed by Maven is this: any directories or files placed within the `${basedir}/src/main/resources` directory are packaged in your JAR with the exact same structure starting at the base of the JAR.
+ You see below in our example we have added the directory `$\{basedir\}/src/main/resources` into which we place any resources we wish to package in our JAR. The simple rule employed by Maven is this: any directories or files placed within the `$\{basedir\}/src/main/resources` directory are packaged in your JAR with the exact same structure starting at the base of the JAR.
@@ -585,7 +585,7 @@ my-app
`-- App.class
```
- As you can see, the contents of `${basedir}/src/main/resources` can be found starting at the base of the JAR and our `application.properties` file is there in the `META-INF` directory. You will also notice some other files there like `META-INF/MANIFEST.MF` as well as a `pom.xml` and `pom.properties` file. These come standard with generation of a JAR in Maven. You can create your own manifest if you choose, but Maven will generate one by default if you don't. (You can also modify the ent [...]
+ As you can see, the contents of `$\{basedir\}/src/main/resources` can be found starting at the base of the JAR and our `application.properties` file is there in the `META-INF` directory. You will also notice some other files there like `META-INF/MANIFEST.MF` as well as a `pom.xml` and `pom.properties` file. These come standard with generation of a JAR in Maven. You can create your own manifest if you choose, but Maven will generate one by default if you don't. (You can also modify the e [...]
@@ -597,7 +597,7 @@ groupId=com.mycompany.app
artifactId=my-app
```
- To add resources to the classpath for your unit tests, you follow the same pattern as you do for adding resources to the JAR except the directory you place resources in is `${basedir}/src/test/resources`. At this point you would have a project directory structure that would look like the following:
+ To add resources to the classpath for your unit tests, you follow the same pattern as you do for adding resources to the JAR except the directory you place resources in is $\{basedir\}/src/test/resources. At this point you would have a project directory structure that would look like the following:
@@ -686,7 +686,7 @@ InputStream is = getClass().getResourceAsStream( "/test.properties" );
You'll notice that we had to add the `build`, `resources`, and `resource` elements which weren't there before. In addition, we had to explicitly state that the resources are located in the src/main/resources directory. All of this information was provided as default values previously, but because the default value for `filtering` is false, we had to add this to our pom.xml in order to override that default value and set `filtering` to true.
- To reference a property defined in your pom.xml, the property name uses the names of the XML elements that define the value, with "pom" being allowed as an alias for the project (root) element. So `${project.name}` refers to the name of the project, `${project.version}` refers to the version of the project, `${project.build.finalName}` refers to the final name of the file created when the built project is packaged, etc. Note that some elements of the POM have default values, so don't ne [...]
+ To reference a property defined in your pom.xml, the property name uses the names of the XML elements that define the value, with "pom" being allowed as an alias for the project (root) element. So `$\{project.name\}` refers to the name of the project, `$\{project.version\}` refers to the version of the project, `$\{project.build.finalName\}` refers to the final name of the file created when the built project is packaged, etc. Note that some elements of the POM have default values, so do [...]
To continue our example, let's add a couple of properties to the `application.properties` file (which we put in the `src/main/resources` directory) whose values will be supplied when the resource is filtered:
@@ -878,7 +878,7 @@ mvn process-resources "-Dcommand.line.prop=hello again"
For more information about the dependency mechanism as a whole, see [Introduction to Dependency Mechanism](../introduction/introduction-to-dependency-mechanism.html).
- With this information about a dependency, Maven will be able to reference the dependency when it builds the project. Where does Maven reference the dependency from? Maven looks in your local repository (`${user.home}/.m2/repository` is the default location) to find all dependencies. In a [previous section](How_do_I_create_a_JAR_and_install_it_in_my_local_repository), we installed the artifact from our project (my-app-1.0-SNAPSHOT.jar) into the local repository. Once it's installed there [...]
+ With this information about a dependency, Maven will be able to reference the dependency when it builds the project. Where does Maven reference the dependency from? Maven looks in your local repository (`$\{user.home\}/.m2/repository` is the default location) to find all dependencies. In a [previous section](How_do_I_create_a_JAR_and_install_it_in_my_local_repository), we installed the artifact from our project (my-app-1.0-SNAPSHOT.jar) into the local repository. Once it's installed the [...]
diff --git a/content/markdown/guides/getting-started/windows-prerequisites.md b/content/markdown/guides/getting-started/windows-prerequisites.md
index 2f970aea..35e8086a 100644
--- a/content/markdown/guides/getting-started/windows-prerequisites.md
+++ b/content/markdown/guides/getting-started/windows-prerequisites.md
@@ -47,14 +47,14 @@ java -version
### Maven Unpacked
- You need to unpack the Maven distribution. Don't unpack it in the middle of your source code; pick some location and unpack it there. Let's assume that the path is `${maven.home}`.
+ You need to unpack the Maven distribution. Don't unpack it in the middle of your source code; pick some location and unpack it there. Let's assume that the path is `$\{maven.home\}`.
### Maven in PATH
- You run Maven by invoking a command-line tool: `mvn.cmd` from the `bin` directory of the Maven. To do this conveniently, `${maven.home}/bin` must be in your PATH, just like the Java SDK commands. You can add directories to your `PATH` in the control panel; the details vary by Windows version.
+ You run Maven by invoking a command-line tool: `mvn.cmd` from the `bin` directory of the Maven. To do this conveniently, `$\{maven.home\}\\bin` must be in your PATH, just like the Java SDK commands. You can add directories to your `PATH` in the control panel; the details vary by Windows version.
diff --git a/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md b/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
index 459a8d98..c7b2b476 100644
--- a/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
+++ b/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
@@ -322,7 +322,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
```
- **NOTE:** In two of these dependency references, we had to specify the `<type>` element. This is because the minimal set of information for matching a dependency reference against a dependencyManagement section is actually **{groupId, artifactId, type, classifier}**. In many cases, these dependencies will refer to jar artifacts with no classifier. This allows us to shorthand the identity set to **{groupId, artifactId}**, since the default for the type field is `jar`, and the default cla [...]
+ **NOTE:** In two of these dependency references, we had to specify the `<type>` element. This is because the minimal set of information for matching a dependency reference against a dependencyManagement section is actually **\{groupId, artifactId, type, classifier\}**. In many cases, these dependencies will refer to jar artifacts with no classifier. This allows us to shorthand the identity set to **\{groupId, artifactId\}**, since the default for the type field is `jar`, and the default [...]
A second, and very important use of the dependency management section is to control the versions of artifacts used in transitive dependencies. As an example consider these projects:
diff --git a/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md b/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
index da041f44..a531a61a 100644
--- a/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
+++ b/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
@@ -39,9 +39,9 @@ under the License.
- - `maven-${prefix}-plugin` - for official plugins maintained by the Apache Maven team itself (you **must not** use this naming pattern for your plugin, see [this note for more informations](../plugin/guide-java-plugin-development.html#Plugin_Naming_Convention_and_Apache_Maven_Trademark))
+ - `maven-$\{prefix\}-plugin` - for official plugins maintained by the Apache Maven team itself (you **must not** use this naming pattern for your plugin, see [this note for more informations](../plugin/guide-java-plugin-development.html#Plugin_Naming_Convention_and_Apache_Maven_Trademark))
- - `${prefix}-maven-plugin` - for plugins from other sources
+ - `$\{prefix\}-maven-plugin` - for plugins from other sources
If your plugin's artifactId fits this pattern, Maven will automatically map your plugin to the correct prefix in the metadata stored within your plugin's groupId path on the repository. However, if you want to customize the prefix used to reference your plugin, you can specify the prefix directly through a configuration parameter on the `maven-plugin-plugin` in your plugin's POM:
@@ -84,9 +84,9 @@ mvn somePrefix:goal
- 1 Download `maven-metadata.xml` from each remote repository into the local repository, and name it `maven-metadata-${repoId}.xml` within the path of `${groupId}`.
+ 1 Download `maven-metadata.xml` from each remote repository into the local repository, and name it `maven-metadata-$\{repoId\}.xml` within the path of $\{groupId\}.
- 1 Load these metadata files, along with `maven-metadata-local.xml` (if it exists), within the path of `${groupId}`. Merge them.
+ 1 Load these metadata files, along with `maven-metadata-local.xml` (if it exists), within the path of $\{groupId\}. Merge them.
1 Lookup the plugin prefix in the merged metadata. If it's mapped, it should refer to a concrete groupId-artifactId pair. Otherwise, go on to #1 for the next groupId in the user's plugin-groups.
@@ -101,7 +101,7 @@ mvn somePrefix:goal
By default, Maven will search the groupId **org.apache.maven.plugins** for prefix-to-artifactId mappings for the plugins it needs to perform a given build. However, as previously mentioned, the user may have a need for third-party plugins. Since the Maven project is assumed to have control over the default plugin groupId, this means configuring Maven to search other groupId locations for plugin-prefix mappings.
- As it turns out, this is simple. In the Maven settings file (per-user: `${user.home}/.m2/settings.xml`; global: `${maven.home}/conf/settings.xml`), you can provide a custom **pluginGroups** section, listing the plugin groupIds you want to search (each groupId goes in its own **pluginGroup** sub-element). For example, if my project uses a Modello model file, I might have the following in my settings:
+ As it turns out, this is simple. In the Maven settings file (per-user: `$\{user.home\}/.m2/settings.xml`; global: `$\{maven.home\}/conf/settings.xml`), you can provide a custom **pluginGroups** section, listing the plugin groupIds you want to search (each groupId goes in its own **pluginGroup** sub-element). For example, if my project uses a Modello model file, I might have the following in my settings:
diff --git a/content/markdown/guides/introduction/introduction-to-plugins.md b/content/markdown/guides/introduction/introduction-to-plugins.md
index 2b3ef553..8fee0356 100644
--- a/content/markdown/guides/introduction/introduction-to-plugins.md
+++ b/content/markdown/guides/introduction/introduction-to-plugins.md
@@ -36,7 +36,7 @@ under the License.
Plugins are the central feature of Maven that allow for the reuse of common build logic across multiple projects. They do this by executing an "action" (i.e. creating a WAR file or compiling unit tests) in the context of a project's description - the Project Object Model (POM). Plugin behavior can be customized through a set of unique parameters which are exposed by a description of each plugin goal (or Mojo).
- One of the simplest plugins in Maven is the Clean Plugin. The [Maven Clean plugin](../../plugins/maven-clean-plugin/) (maven-clean-plugin) is responsible for removing the target directory of a Maven project. When you run "mvn clean", Maven executes the "clean" goal as defined in the Clean plug-in, and the target directory is removed. The Clean plugin [defines a parameter](../../plugins/maven-clean-plugin/clean-mojo.html) which can be used to customize plugin behavior, this parameter is [...]
+ One of the simplest plugins in Maven is the Clean Plugin. The [Maven Clean plugin](../../plugins/maven-clean-plugin/) (maven-clean-plugin) is responsible for removing the target directory of a Maven project. When you run "mvn clean", Maven executes the "clean" goal as defined in the Clean plug-in, and the target directory is removed. The Clean plugin [defines a parameter](../../plugins/maven-clean-plugin/clean-mojo.html) which can be used to customize plugin behavior, this parameter is [...]
diff --git a/content/markdown/guides/introduction/introduction-to-profiles.md b/content/markdown/guides/introduction/introduction-to-profiles.md
index 920c4327..5239e22f 100644
--- a/content/markdown/guides/introduction/introduction-to-profiles.md
+++ b/content/markdown/guides/introduction/introduction-to-profiles.md
@@ -103,7 +103,7 @@ under the License.
- Global
- - Defined in the [ global Maven-settings](/ref/current/maven-settings/settings.html) `(${maven.home}/conf/settings.xml)`.
+ - Defined in the [ global Maven-settings](/ref/current/maven-settings/settings.html) `($\{maven.home\}/conf/settings.xml)`.
@@ -595,7 +595,7 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
</project>
```
- Now, in your local `${user.home}/.m2/settings.xml`, you have:
+ Now, in your local `$\{user.home\}/.m2/settings.xml`, you have:
@@ -720,7 +720,7 @@ mvn -Denv=dev integration-test
mvn -Denv=production integration-test
```
- will not do a successful build. Why? Because, the resulting non-interpolated literal value of `${appserver.home}` will not be a valid path for deploying and testing your web application. We haven't considered the case for the production environment when writing our profiles. The "production" environment (env=production), along with "test" and possibly even "local" constitute a natural set of target environments for which we may want to build the integration-test lifecycle phase. The inc [...]
+ will not do a successful build. Why? Because, the resulting non-interpolated literal value of `$\{appserver.home\}` will not be a valid path for deploying and testing your web application. We haven't considered the case for the production environment when writing our profiles. The "production" environment (env=production), along with "test" and possibly even "local" constitute a natural set of target environments for which we may want to build the integration-test lifecycle phase. The i [...]
As a quick aside, it's possible for user-specific profiles to act in a similar way. This means that profiles for handling different environments which are keyed to the user can act up when the team adds a new developer. While I suppose this _could_ act as useful training for the newbie, it just wouldn't be nice to throw them to the wolves in this way. Again, be sure to think of the _whole_ set of profiles.
diff --git a/content/markdown/guides/introduction/introduction-to-the-pom.md b/content/markdown/guides/introduction/introduction-to-the-pom.md
index 4554ee0d..6ec1cf88 100644
--- a/content/markdown/guides/introduction/introduction-to-the-pom.md
+++ b/content/markdown/guides/introduction/introduction-to-the-pom.md
@@ -589,7 +589,7 @@ under the License.
##### Project Model Variables
- Any field of the model that is a single value element can be referenced as a variable. For example, `${project.groupId}`, `${project.version}`, `${project.build.sourceDirectory}` and so on. Refer to the POM reference to see a full list of properties.
+ Any field of the model that is a single value element can be referenced as a variable. For example, `$\{project.groupId\}`, `$\{project.version\}`, `$\{project.build.sourceDirectory\}` and so on. Refer to the POM reference to see a full list of properties.
These variables are all referenced by the prefix "`project.`". You may also see references with `pom.` as the prefix, or the prefix omitted entirely - these forms are now deprecated and should not be used.
diff --git a/content/markdown/guides/mini/guide-3rd-party-jars-remote.md b/content/markdown/guides/mini/guide-3rd-party-jars-remote.md
index ee5a77d5..0abd480f 100644
--- a/content/markdown/guides/mini/guide-3rd-party-jars-remote.md
+++ b/content/markdown/guides/mini/guide-3rd-party-jars-remote.md
@@ -30,7 +30,7 @@ under the License.
To deploy a 3rd party JAR use the deploy:deploy-file goal under maven-deploy-plugin.
- First, the wagon-provider(wagon-ftp, wagon-file, etc..) must be placed to your `${maven.home}/lib`.
+ First, the wagon-provider(wagon-ftp, wagon-file, etc..) must be placed to your `$\{maven.home\}/lib`.
Then execute the command:
diff --git a/content/markdown/guides/mini/guide-assemblies.md b/content/markdown/guides/mini/guide-assemblies.md
index edc291f4..efc5a943 100644
--- a/content/markdown/guides/mini/guide-assemblies.md
+++ b/content/markdown/guides/mini/guide-assemblies.md
@@ -66,7 +66,7 @@ under the License.
</project>
```
- You'll notice that the assembly descriptor is located in `${project.basedir}/src/assembly` which is the [standard](../introduction/introduction-to-the-standard-directory-layout.html) location for assembly descriptors.
+ You'll notice that the assembly descriptor is located in `$\{project.basedir\}/src/assembly` which is the [standard](../introduction/introduction-to-the-standard-directory-layout.html) location for assembly descriptors.
### Creating a binary assembly
diff --git a/content/markdown/guides/mini/guide-attached-tests.md b/content/markdown/guides/mini/guide-attached-tests.md
index 20d03c51..3a363676 100644
--- a/content/markdown/guides/mini/guide-attached-tests.md
+++ b/content/markdown/guides/mini/guide-attached-tests.md
@@ -24,7 +24,7 @@ under the License.
## Guide to using attached tests
- You can reuse the tests that you have created for one project in another. For example, suppose `foo-core` contains test code in the `${basedir}/src/test/java`. To package up those compiled tests in a JAR and deploy them for general reuse, configure the `maven-jar-plugin` as follows:
+ You can reuse the tests that you have created for one project in another. For example, suppose `foo-core` contains test code in the `$\{basedir\}/src/test/java`. To package up those compiled tests in a JAR and deploy them for general reuse, configure the `maven-jar-plugin` as follows:
diff --git a/content/markdown/guides/mini/guide-configuring-maven.md b/content/markdown/guides/mini/guide-configuring-maven.md
index ff81ef20..d390f9e2 100644
--- a/content/markdown/guides/mini/guide-configuring-maven.md
+++ b/content/markdown/guides/mini/guide-configuring-maven.md
@@ -45,13 +45,13 @@ under the License.
<!-- TODO: versioning doc that discusses this -->
- You can specify your user configuration in `${user.home}/.m2/settings.xml`. A [full reference](../../maven-settings/settings.html) to the configuration file is available. This section will show how to make some common configurations. Note that the file is not required - defaults will be used if it is not found.
+ You can specify your user configuration in `$\{user.home\}/.m2/settings.xml`. A [full reference](../../maven-settings/settings.html) to the configuration file is available. This section will show how to make some common configurations. Note that the file is not required - defaults will be used if it is not found.
### Configuring your Local Repository
- The location of your local repository can be changed in your user configuration. The default value is `${user.home}/.m2/repository/`.
+ The location of your local repository can be changed in your user configuration. The default value is `$\{user.home\}/.m2/repository/`.
diff --git a/content/markdown/guides/mini/guide-creating-archetypes.md b/content/markdown/guides/mini/guide-creating-archetypes.md
index ef1eb92a..9bd1233f 100644
--- a/content/markdown/guides/mini/guide-creating-archetypes.md
+++ b/content/markdown/guides/mini/guide-creating-archetypes.md
@@ -150,7 +150,7 @@ archetype
### 3. Create the prototype files and the prototype pom.xml
- The next component of the archetype to be created is the prototype `pom.xml`. Any `pom.xml` will do, just don't forget to the set `artifactId` and `groupId` as variables ( `${artifactId}` / `${groupId}` ). Both variables will be initialized from the commandline when calling `archetype:generate`.
+ The next component of the archetype to be created is the prototype `pom.xml`. Any `pom.xml` will do, just don't forget to the set `artifactId` and `groupId` as variables ( `$\{artifactId\}` / `$\{groupId\}` ). Both variables will be initialized from the commandline when calling `archetype:generate`.
An example for a prototype `pom.xml` is:
diff --git a/content/markdown/guides/mini/guide-encryption.md b/content/markdown/guides/mini/guide-encryption.md
index 4dc3e2d2..81a5ee42 100644
--- a/content/markdown/guides/mini/guide-encryption.md
+++ b/content/markdown/guides/mini/guide-encryption.md
@@ -58,7 +58,7 @@ under the License.
- - authorized users have an additional `settings-security.xml` file in their `${user.home}/.m2` folder
+ - authorized users have an additional `settings-security.xml` file in their `$\{user.home\}/.m2` folder
- this file either contains encrypted **master password**, used to encrypt other passwords
@@ -98,7 +98,7 @@ mvn --encrypt-master-password <password>
{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}
```
- Store this password in the `${user.home}/.m2/settings-security.xml`; it should look like
+ Store this password in the `$\{user.home\}/.m2/settings-security.xml`; it should look like
@@ -201,7 +201,7 @@ mvn deploy:deploy-file -Durl=https://maven.corp.com/repo \
in the file `/Volumes/mySecureUsb/secure/settings-security.xml`
- And then I create `${user.home}/.m2/settings-security.xml` with the following content:
+ And then I create `$\{user.home\}/.m2/settings-security.xml` with the following content:
@@ -221,7 +221,7 @@ mvn deploy:deploy-file -Durl=https://maven.corp.com/repo \
#### Escaping curly-brace literals in your password _(Since: Maven 2.2.0)_
- At times, you might find that your password (or the encrypted form of it) contains '{' or '}' as a literal value. If you added such a password as-is to your settings.xml file, you would find that Maven does strange things with it. Specifically, Maven treats all the characters preceding the '{' literal, and all the characters after the '}' literal, as comments. Obviously, this is not the behavior you want. What you really need is a way of **escaping** the curly-brace literals in your password.
+ At times, you might find that your password (or the encrypted form of it) contains '\{' or '\}' as a literal value. If you added such a password as-is to your settings.xml file, you would find that Maven does strange things with it. Specifically, Maven treats all the characters preceding the '\{' literal, and all the characters after the '\}' literal, as comments. Obviously, this is not the behavior you want. What you really need is a way of **escaping** the curly-brace literals in your [...]
You can do this with the widely used '\\' escape character. If your password looks like this:
@@ -237,7 +237,7 @@ jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+{EF1iFQyJQ=
```
-{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+{EF1iFQyJQ=}
+{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+\{EF1iFQyJQ=}
```
diff --git a/content/markdown/guides/mini/guide-maven-classloading.md b/content/markdown/guides/mini/guide-maven-classloading.md
index e4d7cd0a..f2d14366 100644
--- a/content/markdown/guides/mini/guide-maven-classloading.md
+++ b/content/markdown/guides/mini/guide-maven-classloading.md
@@ -49,7 +49,7 @@ under the License.
### Overview
- Maven uses the [Plexus Classworlds](https://codehaus-plexus.github.io/plexus-classworlds/) classloading framework to create the classloader graph. If you look in your `${maven.home}/boot` directory, you will see a single JAR which is the Classworlds JAR we use to boot the classloader graph. The Classworlds JAR is the only element of the Java `CLASSPATH`. The other classloaders are built by Classworlds ("realms" in Classworlds terminology).
+ Maven uses the [Plexus Classworlds](https://codehaus-plexus.github.io/plexus-classworlds/) classloading framework to create the classloader graph. If you look in your `$\{maven.home\}/boot` directory, you will see a single JAR which is the Classworlds JAR we use to boot the classloader graph. The Classworlds JAR is the only element of the Java `CLASSPATH`. The other classloaders are built by Classworlds ("realms" in Classworlds terminology).
Each realm exposes
@@ -84,10 +84,10 @@ under the License.
### Core Classloader
- The second classloader down the graph contains the core requirements of Maven. **It is used by Maven internally but not by plugins**. The core classloader has the libraries in `${maven.home}/lib`. In general these are just Maven libraries. For example instances of `[MavenProject](/ref/current/apidocs/org/apache/maven/project/MavenProject.html)` belong to this classloader.
+ The second classloader down the graph contains the core requirements of Maven. **It is used by Maven internally but not by plugins**. The core classloader has the libraries in `$\{maven.home\}/lib`. In general these are just Maven libraries. For example instances of `[MavenProject](/ref/current/apidocs/org/apache/maven/project/MavenProject.html)` belong to this classloader.
- You can add elements to this classloader by [extensions](/ref/current/maven-model/maven.html#class_extension). These are loaded through the same classloader as `${maven.home}/lib` and hence are available to the Maven core and all plugins for the current project (through the API classloader). More information is available in [Core Extension](./guide-using-extensions.html).
+ You can add elements to this classloader by [extensions](/ref/current/maven-model/maven.html#class_extension). These are loaded through the same classloader as `$\{maven.home\}/lib` and hence are available to the Maven core and all plugins for the current project (through the API classloader). More information is available in [Core Extension](./guide-using-extensions.html).
@@ -146,7 +146,7 @@ under the License.
</plugin>
```
- Plugins can inspect their effective runtime class path via the expressions `${plugin.artifacts}` or `${plugin.artifactMap}` to have a list or map, respectively, of resolved artifacts injected from the `[PluginDescriptor](/ref/current/maven-plugin-api/apidocs/org/apache/maven/plugin/descriptor/PluginDescriptor.html)`.
+ Plugins can inspect their effective runtime class path via the expressions `$\{plugin.artifacts\}` or `$\{plugin.artifactMap\}` to have a list or map, respectively, of resolved artifacts injected from the `[PluginDescriptor](/ref/current/maven-plugin-api/apidocs/org/apache/maven/plugin/descriptor/PluginDescriptor.html)`.
Please note that the plugin classloader does neither contain the [dependencies](/ref/current/maven-model/maven.html#class_dependency) of the current project nor its build output. Instead, plugins can query the project's compile, runtime and test class path from the `[MavenProject](/ref/current/apidocs/org/apache/maven/project/MavenProject.html)` in combination with the mojo annotation `requiresDependencyResolution` from the [Mojo API Specification](/developers/mojo-api-specification.htm [...]
diff --git a/content/markdown/guides/mini/guide-mirror-settings.md b/content/markdown/guides/mini/guide-mirror-settings.md
index c43b83a4..3fc4d46d 100644
--- a/content/markdown/guides/mini/guide-mirror-settings.md
+++ b/content/markdown/guides/mini/guide-mirror-settings.md
@@ -37,7 +37,7 @@ under the License.
- You want to run a [repository manager](../../repository-management.html) to provide a local cache to a mirror and need to use its URL instead
- To configure a mirror of a given repository, you provide it in your settings file (`${user.home}/.m2/settings.xml`), giving the new repository its own `id` and `url`, and specify the `mirrorOf` setting that is the ID of the repository you are using a mirror of. For example, the ID of the main Maven Central repository included by default is `central`, so to use the different mirror instance, you would configure the following:
+ To configure a mirror of a given repository, you provide it in your settings file (`$\{user.home\}/.m2/settings.xml`), giving the new repository its own `id` and `url`, and specify the `mirrorOf` setting that is the ID of the repository you are using a mirror of. For example, the ID of the main Maven Central repository included by default is `central`, so to use the different mirror instance, you would configure the following:
diff --git a/content/markdown/guides/mini/guide-multiple-repositories.md b/content/markdown/guides/mini/guide-multiple-repositories.md
index 13c4d1c9..c4f00b41 100644
--- a/content/markdown/guides/mini/guide-multiple-repositories.md
+++ b/content/markdown/guides/mini/guide-multiple-repositories.md
@@ -51,7 +51,7 @@ under the License.
**NOTE:** You will also get the standard set of repositories as defined in the [Super POM](../introduction/introduction-to-the-pom.html#Super_POM).
- The other way you can specify multiple repositories is by creating a profile in the `${user.home}/.m2/settings.xml` or `${maven.home}/conf/settings.xml` file like the following:
+ The other way you can specify multiple repositories is by creating a profile in the `$\{user.home\}/.m2/settings.xml` or `$\{maven.home\}/conf/settings.xml` file like the following:
diff --git a/content/markdown/guides/mini/guide-proxies.md b/content/markdown/guides/mini/guide-proxies.md
index abd03693..016915ce 100644
--- a/content/markdown/guides/mini/guide-proxies.md
+++ b/content/markdown/guides/mini/guide-proxies.md
@@ -23,7 +23,7 @@ under the License.
## Configuring a proxy
- You can configure a proxy to use for some or all of your HTTP requests with Maven. The username and password are only required if your proxy requires basic authentication (note that later releases may support storing your passwords in a secured keystore - in the mean time, please ensure your settings.xml file (usually `${user.home}/.m2/settings.xml`) is secured with permissions appropriate for your operating system).
+ You can configure a proxy to use for some or all of your HTTP requests with Maven. The username and password are only required if your proxy requires basic authentication (note that later releases may support storing your passwords in a secured keystore - in the mean time, please ensure your settings.xml file (usually $\{user.home\}/.m2/settings.xml) is secured with permissions appropriate for your operating system).
The `nonProxyHosts` setting accepts wild cards, and each host not to proxy is separated by the | character. This matches the JDK configuration equivalent.
diff --git a/content/markdown/guides/mini/guide-reproducible-builds.md b/content/markdown/guides/mini/guide-reproducible-builds.md
index 5500614d..5dfb89b0 100644
--- a/content/markdown/guides/mini/guide-reproducible-builds.md
+++ b/content/markdown/guides/mini/guide-reproducible-builds.md
@@ -135,7 +135,7 @@ mvn clean verify artifact:compare
- if you have a custom release process tooling, you'll need to add the feature to your release tooling. Notice that if you're using `versions-maven-plugin` in custom release scripts, starting with release 2.9.0, [`versions:set` goal updates the property](https://github.com/mojohaus/versions-maven-plugin/issues/453).
- - instead of explicitely writing a timestamp in their `pom.xml`, some people tend to prefer using last Git commit timestamp, like `${git.commit.time}` from [git-commit-id-maven-plugin](https://github.com/git-commit-id/git-commit-id-maven-plugin).
+ - instead of explicitely writing a timestamp in their `pom.xml`, some people tend to prefer using last Git commit timestamp, like `$\{git.commit.time\}` from [git-commit-id-maven-plugin](https://github.com/git-commit-id/git-commit-id-maven-plugin).
diff --git a/content/markdown/guides/mini/guide-site.md b/content/markdown/guides/mini/guide-site.md
index 6216b6bc..7a8df717 100644
--- a/content/markdown/guides/mini/guide-site.md
+++ b/content/markdown/guides/mini/guide-site.md
@@ -49,7 +49,7 @@ under the License.
+- site.xml
```
- You will notice there is now a `${basedir}/src/site` directory within which is contained a `site.xml` site descriptor along with various directories corresponding to the supported document types.
+ You will notice there is now a `$\{basedir\}/src/site` directory within which is contained a `site.xml` site descriptor along with various directories corresponding to the supported document types.
Let's take a look at the examples of the various document types:
diff --git a/content/markdown/guides/mini/guide-snippet-macro.md b/content/markdown/guides/mini/guide-snippet-macro.md
index 17d8297a..bd60f296 100644
--- a/content/markdown/guides/mini/guide-snippet-macro.md
+++ b/content/markdown/guides/mini/guide-snippet-macro.md
@@ -104,7 +104,7 @@ under the License.
%{snippet|id=snip-id|url=file:///path/to/Sample.java}
```
- As of doxia-core version 1.0-alpha-9, a 'file' parameter is also available. If a full path is not specified, the location is assumed to be relative to `${basedir}`.
+ As of doxia-core version 1.0-alpha-9, a 'file' parameter is also available. If a full path is not specified, the location is assumed to be relative to $\{basedir\}.
diff --git a/content/markdown/guides/mini/guide-using-extensions.md b/content/markdown/guides/mini/guide-using-extensions.md
index cacfd532..0493b852 100644
--- a/content/markdown/guides/mini/guide-using-extensions.md
+++ b/content/markdown/guides/mini/guide-using-extensions.md
@@ -42,7 +42,7 @@ under the License.
- - Registered via extension jar in `${maven.home}/lib/ext`
+ - Registered via extension jar in `$\{maven.home\}/lib/ext`
- Registered via CLI argument `mvn -Dmaven.ext.class.path=extension.jar`
diff --git a/content/markdown/guides/mini/guide-using-toolchains.md b/content/markdown/guides/mini/guide-using-toolchains.md
index 828ec636..66b6034f 100644
--- a/content/markdown/guides/mini/guide-using-toolchains.md
+++ b/content/markdown/guides/mini/guide-using-toolchains.md
@@ -114,7 +114,7 @@ under the License.
The `toolchains.xml` file (see below) is the configuration file where you set the installation paths of your toolchains. This file should be put in your `${user.home}/.m2` directory. When the `maven-toolchains-plugin` executes, it looks for the `toolchains.xml` file, reads it and looks for a toolchain matching the toolchains requirements configured in the plugin. In our example, that would be a JDK toolchain with `<version>` "1.5" and `<vendor>` "sun". Once a match is found, the plugin [...]
- Starting with [Maven 3.3.1](/docs/3.3.1/release-notes.html) you can put the `toolchains.xml` file wherever you like by using the `--global-toolchains file` option but it is recommended to locate it into `${user.home}/.m2/`.
+ Starting with [Maven 3.3.1](/docs/3.3.1/release-notes.html) you can put the `toolchains.xml` file wherever you like by using the `--global-toolchains file` option but it is recommended to locate it into `$\{user.home\}/.m2/`.
diff --git a/content/markdown/guides/plugin/guide-java-plugin-development.md b/content/markdown/guides/plugin/guide-java-plugin-development.md
index 725cbd36..e818f88f 100644
--- a/content/markdown/guides/plugin/guide-java-plugin-development.md
+++ b/content/markdown/guides/plugin/guide-java-plugin-development.md
@@ -252,9 +252,9 @@ mvn groupId:artifactId:version:goal
- If you need to run the latest version of a plugin installed in your local repository, you can omit its version number. So just use "`mvn sample.plugin:hello-maven-plugin:sayhi`" to run your plugin.
- - You can assign a shortened prefix to your plugin, such as `mvn hello:sayhi`. This is done automatically if you follow the convention of using `${prefix}-maven-plugin` (or `maven-${prefix}-plugin` if the plugin is part of the Apache Maven project). You may also assign one through additional configuration - for more information see [ Introduction to Plugin Prefix Mapping](../introduction/introduction-to-plugin-prefix-mapping.html).
+ - You can assign a shortened prefix to your plugin, such as `mvn hello:sayhi`. This is done automatically if you follow the convention of using `$\{prefix\}-maven-plugin` (or `maven-$\{prefix\}-plugin` if the plugin is part of the Apache Maven project). You may also assign one through additional configuration - for more information see [ Introduction to Plugin Prefix Mapping](../introduction/introduction-to-plugin-prefix-mapping.html).
- - Finally, you can also add your plugin's groupId to the list of groupIds searched by default. To do this, you need to add the following to your `${user.home}/.m2/settings.xml` file:
+ - Finally, you can also add your plugin's groupId to the list of groupIds searched by default. To do this, you need to add the following to your `$\{user.home\}/.m2/settings.xml` file:
```
<pluginGroups>
@@ -352,7 +352,7 @@ mvn archetype:generate \
private String greeting;
```
- The portion before the annotations is the description of the parameter. The `parameter` annotation identifies the variable as a mojo parameter. The `defaultValue` parameter of the annotation defines the default value for the variable. This value can include expressions which reference the project, such as "`${project.version}`" (more can be found in the ["Parameter Expressions" document](/ref/current/maven-core/apidocs/org/apache/maven/plugin/PluginParameterExpressionEvaluator.html)). T [...]
+ The portion before the annotations is the description of the parameter. The `parameter` annotation identifies the variable as a mojo parameter. The `defaultValue` parameter of the annotation defines the default value for the variable. This value can include expressions which reference the project, such as "`$\{project.version\}`" (more can be found in the ["Parameter Expressions" document](/ref/current/maven-core/apidocs/org/apache/maven/plugin/PluginParameterExpressionEvaluator.html)). [...]
diff --git a/content/markdown/plugin-developers/common-bugs.md b/content/markdown/plugin-developers/common-bugs.md
index 947be36d..95d21d2c 100644
--- a/content/markdown/plugin-developers/common-bugs.md
+++ b/content/markdown/plugin-developers/common-bugs.md
@@ -269,7 +269,7 @@ public MyMojo extends AbstractMojo
### Resolving Relative Paths
- It is common practice for users of Maven to specify relative paths in the POM, not to mention that the Super POM does so, too. The intention is to resolve such relative paths against the base directory of the current project. In other words, the paths `target/classes` and `${basedir}/target/classes` should resolve to the same directory for a given POM.
+ It is common practice for users of Maven to specify relative paths in the POM, not to mention that the Super POM does so, too. The intention is to resolve such relative paths against the base directory of the current project. In other words, the paths `target/classes` and `$\{basedir\}/target/classes` should resolve to the same directory for a given POM.
Unfortunately, the class `[java.io.File](http://java.sun.com/javase/6/docs/api/java/io/File.html)` does not resolve relative paths against the project's base directory. As mentioned in its class javadoc, it resolves relative paths against the current working directory. In plain English: Unless a Maven component has complete control over the current working directory, any usage of `java.io.File` in combination with a relative path is a bug.
@@ -343,7 +343,7 @@ if ( !file.isAbsolute() )
Most reporting plugins inherit from `AbstractMavenReport`. In doing so, they need to implement the inherited but abstract method `getOutputDirectory()`. To implement this method, plugins usually declare a field named `outputDirectory` which they return in the method. Nothing wrong so far.
- Now, some plugins need to create additional files in the report output directory that accompany the report generated via the sink interface. While it is tempting to use either the method `getOutputDirectory()` or the field `outputDirectory` directly in order to setup a path for the output files, this leads most likely to a bug. More precisely, those plugins will not properly output files when run by the Maven Site Plugin as part of the site lifecycle. This is best noticed when the outpu [...]
+ Now, some plugins need to create additional files in the report output directory that accompany the report generated via the sink interface. While it is tempting to use either the method `getOutputDirectory()` or the field `outputDirectory` directly in order to setup a path for the output files, this leads most likely to a bug. More precisely, those plugins will not properly output files when run by the Maven Site Plugin as part of the site lifecycle. This is best noticed when the outpu [...]
diff --git a/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md b/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
index d3e506ad..3a0436c3 100644
--- a/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
+++ b/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
@@ -128,7 +128,7 @@ default: `${basedir}/src/test/resources/META-INF/plexus`|
</project>
```
- If `merge-descriptors` is used, move the handwritten xml file to `${basedir}/src/main/resources/META-INF/plexus`.
+ If `merge-descriptors` is used, move the handwritten xml file to `$\{basedir\}/src/main/resources/META-INF/plexus`.
[maven-site] 07/14: Revert "reformt"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit 7d348a3e4ec55fa3a4b7f82b9bd63a067a2b02e0
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:33:35 2023 +0100
Revert "reformt"
This reverts commit d333017cde70daf47d0790b9057e1ff2bd13edd4.
---
content/markdown/plugins/index.md | 210 +++++++++++++++++++++-----------------
1 file changed, 116 insertions(+), 94 deletions(-)
diff --git a/content/markdown/plugins/index.md b/content/markdown/plugins/index.md
index 1a9ab4de..b92246ce 100644
--- a/content/markdown/plugins/index.md
+++ b/content/markdown/plugins/index.md
@@ -22,8 +22,11 @@ under the License.
-->
## Available Plugins
+
Maven is - at its heart - a plugin execution framework; all work is done by plugins. Looking for a specific goal to execute? This page lists the core plugins and others. There are the build and the reporting plugins:
+
+
- **Build plugins** will be executed during the build and they should be configured in the `<build>` element from the POM.
- **Reporting plugins** will be executed during the site generation and they should be configured in the `<reporting>` element from the POM. Because the result of a Reporting plugin is part of the generated site, Reporting plugins should be both internationalized and localized. You can read more about the [localization of our plugins](./localization.html) and how you can help.
@@ -31,7 +34,8 @@ under the License.
### Supported By The Maven Project
- To see the most up-to-date list browse the Maven repository, specifically the [`org/apache/maven/plugins`](https://repo.maven.apache.org/maven2/org/apache/maven/plugins/) subdirectory. _(Plugins are organized according to a directory structure that resembles the standard Java package naming convention)_
+
+ To see the most up-to-date list browse the Maven repository, specifically the [ `org/apache/maven/plugins`](https://repo.maven.apache.org/maven2/org/apache/maven/plugins/) subdirectory. _(Plugins are organized according to a directory structure that resembles the standard Java package naming convention)_
<!-- TODO: the repository manager should be able to produce a page like this. Ensure all descriptions are in the POM of these plugins. -->
@@ -39,125 +43,143 @@ under the License.
<!-- The release dates in this table must follow the ISO-8601 standard: yyyy-MM-dd -->
<!-- See https://maven.apache.org/guides/development/guide-documentation-style.html -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-| **Plugin** | **Type*** | **Version** | **Release Date** | **Description** | **Source Repository** | **Issue Tracking** |
-| ---------- | --------- | ----------- | ---------------- | --------------- | --------------------- | ----------------- |
-| **Core plugins** | | | | **Plugins corresponding to default core phases (ie. clean, compile). They may have multiple goals as well.** | | |
-| [`clean`](/plugins/maven-clean-plugin/) | B | 3.2.0 | 2022-04-01 | Clean up after the build. | [Git](https://gitbox.apache.org/repos/asf/maven-clean-plugin.git) / [GitHub](https://github.com/apache/maven-clean-plugin/) | [Jira MCLEAN](https://issues.apache.org/jira/browse/MCLEAN) |
-| [`compiler`](/plugins/maven-compiler-plugin/) | B | 3.10.1 | 2022-03-11 | Compiles Java sources. | [Git](https://gitbox.apache.org/repos/asf/maven-compiler-plugin.git) / [GitHub](https://github.com/apache/maven-compiler-plugin/) | [Jira MCOMPILER](https://issues.apache.org/jira/browse/MCOMPILER) |
-| [`deploy`](/plugins/maven-deploy-plugin/) | B | 3.0.0 | 2022-07-16 | Deploy the built artifact to the remote repository. | [Git](https://gitbox.apache.org/repos/asf/maven-deploy-plugin.git) / [GitHub](https://github.com/apache/maven-deploy-plugin/) | [Jira MDEPLOY](https://issues.apache.org/jira/browse/MDEPLOY) |
-| [`failsafe`](/surefire/maven-failsafe-plugin/) | B | 3.0.0-M8 | 2023-01-11 | Run the JUnit integration tests in an isolated classloader. | [Git](https://gitbox.apache.org/repos/asf/maven-surefire.git) / [GitHub](https://github.com/apache/maven-surefire/) | [Jira SUREFIRE](https://issues.apache.org/jira/browse/SUREFIRE) |
-| [`install`](/plugins/maven-install-plugin/) | B | 3.1.0 | 2022-11-13 | Install the built artifact into the local repository. | [Git](https://gitbox.apache.org/repos/asf/maven-install-plugin.git) / [GitHub](https://github.com/apache/maven-install-plugin/) | [Jira MINSTALL](https://issues.apache.org/jira/browse/MINSTALL) |
-| [`resources`](/plugins/maven-resources-plugin/) | B | 3.3.0 | 2022-07-23 | Copy the resources to the output directory for including in the JAR. | [Git](https://gitbox.apache.org/repos/asf/maven-resources-plugin.git) / [GitHub](https://github.com/apache/maven-resources-plugin/) | [Jira MRESOURCES](https://issues.apache.org/jira/browse/MRESOURCES) |
-| [`site`](/plugins/maven-site-plugin/) | B | 4.0.0-M4 | 2022-12-02 | Generate a site for the current project. | [Git](https://gitbox.apache.org/repos/asf/maven-site-plugin.git) / [GitHub](https://github.com/apache/maven-site-plugin/) | [Jira MSITE](https://issues.apache.org/jira/browse/MSITE) |
-| [`surefire`](/surefire/maven-surefire-plugin/) | B | 3.0.0-M9 | 2023-02-14 | Run the JUnit unit tests in an isolated classloader. | [Git](https://gitbox.apache.org/repos/asf/maven-surefire.git) / [GitHub](https://github.com/apache/maven-surefire/) | [Jira SUREFIRE](https://issues.apache.org/jira/browse/SUREFIRE) |
-| [`verifier`](/plugins/maven-verifier-plugin/) | B | 1.1 | 2015-04-14 | Useful for integration tests - verifies the existence of certain conditions. | [Git](https://gitbox.apache.org/repos/asf/maven-verifier-plugin.git) / [GitHub](https://github.com/apache/maven-verifier-plugin/) | [Jira MVERIFIER](https://issues.apache.org/jira/browse/MVERIFIER) |
-| **Packaging types/tools** | | | | **These plugins relate to packaging respective artifact types.** | | |
-| [`ear`](/plugins/maven-ear-plugin/) | B | 3.3.0 | 2022-10-18 | Generate an EAR from the current project. | [Git](https://gitbox.apache.org/repos/asf/maven-ear-plugin.git) / [GitHub](https://github.com/apache/maven-ear-plugin/) | [Jira MEAR](https://issues.apache.org/jira/browse/MEAR) |
-| [`ejb`](/plugins/maven-ejb-plugin/) | B | 3.2.1 | 2022-04-18 | Build an EJB (and optional client) from the current project. | [Git](https://gitbox.apache.org/repos/asf/maven-ejb-plugin.git) / [GitHub](https://github.com/apache/maven-ejb-plugin/) | [Jira MEJB](https://issues.apache.org/jira/browse/MEJB) |
-| [`jar`](/plugins/maven-jar-plugin/) | B | 3.3.0 | 2022-09-12 | Build a JAR from the current project. | [Git](https://gitbox.apache.org/repos/asf/maven-jar-plugin.git) / [GitHub](https://github.com/apache/maven-jar-plugin/) | [Jira MJAR](https://issues.apache.org/jira/browse/MJAR) |
-| [`rar`](/plugins/maven-rar-plugin/) | B | 3.0.0 | 2022-07-17 | Build a RAR from the current project. | [Git](https://gitbox.apache.org/repos/asf/maven-rar-plugin.git) / [GitHub](https://github.com/apache/maven-rar-plugin/) | [Jira MRAR](https://issues.apache.org/jira/browse/MRAR) |
-| [`war`](/plugins/maven-war-plugin/) | B | 3.3.2 | 2021-09-10 | Build a WAR from the current project. | [Git](https://gitbox.apache.org/repos/asf/maven-war-plugin.git) / [GitHub](https://github.com/apache/maven-war-plugin/) | [Jira MWAR](https://issues.apache.org/jira/browse/MWAR) |
-| [`app-client/acr`](/plugins/maven-acr-plugin/) | B | 3.1.0 | 2018-06-19 | Build a JavaEE application client from the current project. | [Git](https://gitbox.apache.org/repos/asf/maven-acr-plugin.git) / [GitHub](https://github.com/apache/maven-acr-plugin/) | [Jira MACR](https://issues.apache.org/jira/browse/MACR) |
-| [`shade`](/plugins/maven-shade-plugin/) | B | 3.4.1 | 2022-10-27 | Build an Uber-JAR from the current project, including dependencies. | [Git](https://gitbox.apache.org/repos/asf/maven-shade-plugin.git) / [GitHub](https://github.com/apache/maven-shade-plugin/) | [Jira MSHADE](https://issues.apache.org/jira/browse/MSHADE) |
-| [`source`](/plugins/maven-source-plugin/) | B | 3.2.1 | 2019-12-21 | Build a source-JAR from the current project. | [Git](https://gitbox.apache.org/repos/asf/maven-source-plugin.git) / [GitHub](https://github.com/apache/maven-source-plugin/) | [Jira MSOURCES](https://issues.apache.org/jira/browse/MSOURCES) |
-| [`jlink`](/plugins/maven-jlink-plugin/) | B | 3.1.0 | 2020-12-28 | Build Java Run Time Image. | [Git](https://gitbox.apache.org/repos/asf/maven-jlink-plugin.git) / [GitHub](https://github.com/apache/maven-jlink-plugin/) | [Jira MJLINK](https://issues.apache.org/jira/browse/MJLINK) |
-| [`jmod`](/plugins/maven-jmod-plugin/) | B | 3.0.0-alpha-1 | 2017-09-17 | Build Java JMod files. | [Git](https://gitbox.apache.org/repos/asf/maven-jmod-plugin.git) / [GitHub](https://github.com/apache/maven-jmod-plugin/) | [Jira MJMOD](https://issues.apache.org/jira/browse/MJMOD) |
-| **Reporting plugins** | | | | **Plugins which generate reports, are configured as reports in the POM and run under the site generation lifecycle.** | | |
-| [`changelog`](/plugins/maven-changelog-plugin/) | R | 2.3 | 2014-06-24 | Generate a list of recent changes from your SCM. | [Git](https://gitbox.apache.org/repos/asf/maven-changelog-plugin.git) / [GitHub](https://github.com/apache/maven-changelog-plugin/) | [Jira MCHANGELOG](https://issues.apache.org/jira/browse/MCHANGELOG) |
-| [`changes`](/plugins/maven-changes-plugin/) | B+R | 2.12.1 | 2016-11-01 | Generate a report from an issue tracker or a change document. | [Git](https://gitbox.apache.org/repos/asf/maven-changes-plugin.git) / [GitHub](https://github.com/apache/maven-changes-plugin/) | [Jira MCHANGES](https://issues.apache.org/jira/browse/MCHANGES) |
-| [`checkstyle`](/plugins/maven-checkstyle-plugin/) | B+R | 3.2.1 | 2023-01-11 | Generate a Checkstyle report. | [Git](https://gitbox.apache.org/repos/asf/maven-checkstyle-plugin.git) / [GitHub](https://github.com/apache/maven-checkstyle-plugin/) | [Jira MCHECKSTYLE](https://issues.apache.org/jira/browse/MCHECKSTYLE) |
-| [`doap`](/plugins/maven-doap-plugin/) | B | 1.2 | 2015-03-17 | Generate a Description of a Project (DOAP) file from a POM. | [Git](https://gitbox.apache.org/repos/asf/maven-doap-plugin.git) / [GitHub](https://github.com/apache/maven-doap-plugin/) | [Jira MDOAP](https://issues.apache.org/jira/browse/MDOAP) |
-| [`docck`](/plugins/maven-docck-plugin/) | B | 1.1 | 2015-04-03 | Documentation checker plugin. | [Git](https://gitbox.apache.org/repos/asf/maven-docck-plugin.git) / [GitHub](https://github.com/apache/maven-docck-plugin/) | [Jira MDOCCK](https://issues.apache.org/jira/browse/MDOCCK) |
-| [`javadoc`](/plugins/maven-javadoc-plugin/) | B+R | 3.4.1 | 2022-08-13 | Generate Javadoc for the project. | [Git](https://gitbox.apache.org/repos/asf/maven-javadoc-plugin.git) / [GitHub](https://github.com/apache/maven-javadoc-plugin/) | [Jira MJAVADOC](https://issues.apache.org/jira/browse/MJAVADOC) |
-| [`jdeps`](/plugins/maven-jdeps-plugin/) | B | 3.1.2 | 2019-06-12 | Run JDK's JDeps tool on the project. | [Git](https://gitbox.apache.org/repos/asf/maven-jdeps-plugin.git) / [GitHub](https://github.com/apache/maven-jdeps-plugin/) | [Jira MJDEPS](https://issues.apache.org/jira/browse/MJDEPS) |
-| [`jxr`](/jxr/maven-jxr-plugin/) | R | 3.3.0 | 2022-08-16 | Generate a source cross reference. | [Git](https://gitbox.apache.org/repos/asf/maven-jxr.git) / [GitHub](https://github.com/apache/maven-jxr/) | [Jira JXR](https://issues.apache.org/jira/browse/JXR) |
-| [`linkcheck`](/plugins/maven-linkcheck-plugin/) | R | 1.2 | 2014-10-08 | Generate a Linkcheck report of your project's documentation. | [Git](https://gitbox.apache.org/repos/asf/maven-linkcheck-plugin.git) / [GitHub](https://github.com/apache/maven-linkcheck-plugin/) | [Jira MLINKCHECK](https://issues.apache.org/jira/browse/MLINKCHECK) |
-| [`pmd`](/plugins/maven-pmd-plugin/) | B+R | 3.20.0 | 2022-09-11 | Generate a PMD report. | [Git](https://gitbox.apache.org/repos/asf/maven-pmd-plugin.git) / [GitHub](https://github.com/apache/maven-pmd-plugin/) | [Jira MPMD](https://issues.apache.org/jira/browse/MPMD) |
-| [`project-info-reports`](/plugins/maven-project-info-reports-plugin/) | R | 3.4.2 | 2023-01-11 | Generate standard project reports. | [Git](https://gitbox.apache.org/repos/asf/maven-project-info-reports-plugin.git) / [GitHub](https://github.com/apache/maven-project-info-reports-plugin/) | [Jira MPIR](https://issues.apache.org/jira/browse/MPIR) |
-| [`surefire-report`](/surefire/maven-surefire-report-plugin/) | R | 3.0.0-M9 | 2023-02-14 | Generate a report based on the results of unit tests. | [Git](https://gitbox.apache.org/repos/asf/maven-surefire.git) / [GitHub](https://github.com/apache/maven-surefire/) | [Jira SUREFIRE](https://issues.apache.org/jira/browse/SUREFIRE) |
-| **Tools** | | | | **These are miscellaneous tools available through Maven by default.** | | |
-| [`antrun`](/plugins/maven-antrun-plugin/) | B | 3.1.0 | 2022-04-18 | Run a set of ant tasks from a phase of the build. | [Git](https://gitbox.apache.org/repos/asf/maven-antrun-plugin.git) / [GitHub](https://github.com/apache/maven-antrun-plugin/) | [Jira MANTRUN](https://issues.apache.org/jira/browse/MANTRUN) |
-| [`artifact`](/plugins/maven-artifact-plugin/) | B | 3.4.0 | 2023-02-07 | Manage artifacts tasks like buildinfo. | [Git](https://gitbox.apache.org/repos/asf/maven-artifact-plugin.git) / [GitHub](https://github.com/apache/maven-artifact-plugin/) | [Jira MARTIFACT](https://issues.apache.org/jira/browse/MARTIFACT) |
-| [`archetype`](/archetype/maven-archetype-plugin/) | B | 3.2.1 | 2021-12-30 | Generate a skeleton project structure from an archetype. | [Git](https://gitbox.apache.org/repos/asf/maven-archetype.git) / [GitHub](https://github.com/apache/maven-archetype/) | [Jira ARCHETYPE](https://issues.apache.org/jira/browse/ARCHETYPE) |
-| [`assembly`](/plugins/maven-assembly-plugin/) | B | 3.4.2 | 2022-07-20 | Build an assembly (distribution) of sources and/or binaries. | [Git](https://gitbox.apache.org/repos/asf/maven-assembly-plugin.git) / [GitHub](https://github.com/apache/maven-assembly-plugin/) | [Jira MASSEMBLY](https://issues.apache.org/jira/browse/MASSEMBLY) |
-| [`dependency`](/plugins/maven-dependency-plugin/) | B+R | 3.5.0 | 2023-01-11 | Dependency manipulation (copy, unpack) and analysis. | [Git](https://gitbox.apache.org/repos/asf/maven-dependency-plugin.git) / [GitHub](https://github.com/apache/maven-dependency-plugin/) | [Jira MDEP](https://issues.apache.org/jira/browse/MDEP) |
-| [`enforcer`](/enforcer/maven-enforcer-plugin/) | B | 3.2.1 | 2023-01-28 | Environmental constraint checking (Maven Version, JDK etc), User Custom Rule Execution. | [Git](https://gitbox.apache.org/repos/asf/maven-enforcer.git) / [GitHub](https://github.com/apache/maven-enforcer/) | [Jira MENFORCER](https://issues.apache.org/jira/browse/MENFORCER) |
-| [`gpg`](/plugins/maven-gpg-plugin/) | B | 3.0.1 | 2021-05-08 | Create signatures for the artifacts and poms. | [Git](https://gitbox.apache.org/repos/asf/maven-gpg-plugin.git) / [GitHub](https://github.com/apache/maven-gpg-plugin/) | [Jira MGPG](https://issues.apache.org/jira/browse/MGPG) |
-| [`help`](/plugins/maven-help-plugin/) | B | 3.3.0 | 2022-08-14 | Get information about the working environment for the project. | [Git](https://gitbox.apache.org/repos/asf/maven-help-plugin.git) / [GitHub](https://github.com/apache/maven-help-plugin/) | [Jira MPH](https://issues.apache.org/jira/browse/MPH) |
-| [`invoker`](/plugins/maven-invoker-plugin/) | B+R | 3.4.0 | 2022-12-20 | Run a set of Maven projects and verify the output. | [Git](https://gitbox.apache.org/repos/asf/maven-invoker-plugin.git) / [GitHub](https://github.com/apache/maven-invoker-plugin/) | [Jira MINVOKER](https://issues.apache.org/jira/browse/MINVOKER) |
-| [`jarsigner`](/plugins/maven-jarsigner-plugin/) | B | 3.0.0 | 2018-11-06 | Signs or verifies project artifacts. | [Git](https://gitbox.apache.org/repos/asf/maven-jarsigner-plugin.git) / [GitHub](https://github.com/apache/maven-jarsigner-plugin/) | [Jira MJARSIGNER](https://issues.apache.org/jira/browse/MJARSIGNER) |
-| [`jdeprscan`](/plugins/maven-jdeprscan-plugin/) | B | 3.0.0-alpha-1 | 2017-11-15 | Run JDK's JDeprScan tool on the project. | [Git](https://gitbox.apache.org/repos/asf/maven-jdeprscan-plugin.git) / [GitHub](https://github.com/apache/maven-jdeprscan-plugin/) | [Jira MJDEPRSCAN](https://issues.apache.org/jira/browse/MJDEPRSCAN) |
-| [`patch`](/plugins/maven-patch-plugin/) | B | 1.2 | 2015-03-09 | Use the gnu patch tool to apply patch files to source code. | [Git](https://gitbox.apache.org/repos/asf/maven-patch-plugin.git) / [GitHub](https://github.com/apache/maven-patch-plugin/) | [Jira MPATCH](https://issues.apache.org/jira/browse/MPATCH) |
-| [`pdf`](/plugins/maven-pdf-plugin/) | B | 1.6.1 | 2022-08-16 | Generate a PDF version of your project's documentation. | [Git](https://gitbox.apache.org/repos/asf/maven-pdf-plugin.git) / [GitHub](https://github.com/apache/maven-pdf-plugin/) | [Jira MPDF](https://issues.apache.org/jira/browse/MPDF) |
-| [`plugin`](/plugin-tools/maven-plugin-plugin/) | B+R | 3.7.1 | 2023-01-13 | Create a Maven plugin descriptor for any mojos found in the source tree, to include in the JAR. | [Git](https://gitbox.apache.org/repos/asf/maven-plugin-tools.git) / [GitHub](https://github.com/apache/maven-plugin-tools/) | [Jira MPLUGIN](https://issues.apache.org/jira/browse/MPLUGIN) |
-| [`release`](/plugins/maven-release-plugin/) | B | 3.0.0-M7 | 2022-10-29 | Release the current project - updating the POM and tagging in the SCM. | [Git](https://gitbox.apache.org/repos/asf/maven-release.git) / [GitHub](https://github.com/apache/maven-release/) | [Jira MRELEASE](https://issues.apache.org/jira/browse/MRELEASE) |
-| [`remote-resources`](/plugins/maven-remote-resources-plugin/) | B | 3.0.0 | 2022-07-17 | Copy remote resources to the output directory for inclusion in the artifact. | [Git](https://gitbox.apache.org/repos/asf/maven-remote-resources-plugin.git) / [GitHub](https://github.com/apache/maven-remote-resources-plugin/) | [Jira MRRESOURCES](https://issues.apache.org/jira/browse/MRRESOURCES) |
-| [`scm`](/scm/maven-scm-plugin/) | B | 2.0.0-M3 | 2022-10-25 | Execute SCM commands for the current project. | [Git](https://gitbox.apache.org/repos/asf/maven-scm.git ) / [GitHub](https://github.com/apache/maven-scm/) | [Jira SCM](https://issues.apache.org/jira/browse/SCM) |
-| [`scm-publish`](/plugins/maven-scm-publish-plugin/) | B | 3.1.0 | 2020-12-26 | Publish your Maven website to a scm location. | [Git](https://gitbox.apache.org/repos/asf/maven-scm-publish-plugin.git) / [GitHub](https://github.com/apache/maven-scm-publish-plugin/) | [Jira MSCMPUB](https://issues.apache.org/jira/browse/MSCMPUB) |
-| [`scripting`](/plugins/maven-scripting-plugin/) | B | 3.0.0 | 2021-03-01 | The Maven Scripting Plugin wraps the Scripting API according to JSR223. | [Git](https://gitbox.apache.org/repos/asf/maven-scripting-plugin.git) / [GitHub](https://github.com/apache/maven-scripting-plugin/) | [Jira MSCRIPTING](https://issues.apache.org/jira/browse/MSCRIPTING) |
-| [`stage`](/plugins/maven-stage-plugin/) | B | 1.0 | 2015-03-03 | Assists with release staging and promotion. | [Git](https://gitbox.apache.org/repos/asf/maven-stage-plugin.git) / [GitHub](https://github.com/apache/maven-stage-plugin/) | [Jira MSTAGE](https://issues.apache.org/jira/browse/MSTAGE) |
-| [`toolchains`](/plugins/maven-toolchains-plugin/) | B | 3.1.0 | 2022-06-18 | Allows to share configuration across plugins. | [Git](https://gitbox.apache.org/repos/asf/maven-toolchains-plugin.git) / [GitHub](https://github.com/apache/maven-toolchains-plugin/) | [Jira MTOOLCHAINS](https://issues.apache.org/jira/browse/MTOOLCHAINS) |
-| [`wrapper`](/plugins/maven-wrapper-plugin/) | B | 3.1.1 | 2022-05-14 | Download and unpack the maven wrapper distribution | [Git](https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git) / [GitHub](https://github.com/apache/maven-wrapper/) | [Jira MWRAPPER](https://issues.apache.org/jira/browse/MWRAPPER) |
+|**Plugin**|**Type***|**Version**|**Release Date**|**Description**|**Source Repository**|**Issue Tracking**|
+|---|---|---|---|---|---|---|
+|**Core plugins**||||**Plugins corresponding to default core phases (ie. clean, compile). They may have multiple goals as well.**|||
+|[ `clean`](/plugins/maven-clean-plugin/)|B|3.2.0|2022-04-01|Clean up after the build.|[Git](https://gitbox.apache.org/repos/asf/maven-clean-plugin.git) / [GitHub](https://github.com/apache/maven-clean-plugin/)|[Jira MCLEAN](https://issues.apache.org/jira/browse/MCLEAN)|
+|[ `compiler`](/plugins/maven-compiler-plugin/)|B|3.10.1|2022-03-11|Compiles Java sources.|[Git](https://gitbox.apache.org/repos/asf/maven-compiler-plugin.git) / [GitHub](https://github.com/apache/maven-compiler-plugin/)|[Jira MCOMPILER](https://issues.apache.org/jira/browse/MCOMPILER)|
+|[ `deploy`](/plugins/maven-deploy-plugin/)|B|3.0.0|2022-07-16|Deploy the built artifact to the remote repository.|[Git](https://gitbox.apache.org/repos/asf/maven-deploy-plugin.git) / [GitHub](https://github.com/apache/maven-deploy-plugin/)|[Jira MDEPLOY](https://issues.apache.org/jira/browse/MDEPLOY)|
+|[ `failsafe`](/surefire/maven-failsafe-plugin/)|B|3.0.0-M8|2023-01-11|Run the JUnit integration tests in an isolated classloader.|[Git](https://gitbox.apache.org/repos/asf/maven-surefire.git) / [GitHub](https://github.com/apache/maven-surefire/)|[Jira SUREFIRE](https://issues.apache.org/jira/browse/SUREFIRE)|
+|[ `install`](/plugins/maven-install-plugin/)|B|3.1.0|2022-11-13|Install the built artifact into the local repository.|[Git](https://gitbox.apache.org/repos/asf/maven-install-plugin.git) / [GitHub](https://github.com/apache/maven-install-plugin/)|[Jira MINSTALL](https://issues.apache.org/jira/browse/MINSTALL)|
+|[ `resources`](/plugins/maven-resources-plugin/)|B|3.3.0|2022-07-23|Copy the resources to the output directory for including in the JAR.|[Git](https://gitbox.apache.org/repos/asf/maven-resources-plugin.git) / [GitHub](https://github.com/apache/maven-resources-plugin/)|[Jira MRESOURCES](https://issues.apache.org/jira/browse/MRESOURCES)|
+|[ `site`](/plugins/maven-site-plugin/)|B|4.0.0-M4|2022-12-02|Generate a site for the current project.|[Git](https://gitbox.apache.org/repos/asf/maven-site-plugin.git) / [GitHub](https://github.com/apache/maven-site-plugin/)|[Jira MSITE](https://issues.apache.org/jira/browse/MSITE)|
+|[ `surefire`](/surefire/maven-surefire-plugin/)|B|3.0.0-M9|2023-02-14|Run the JUnit unit tests in an isolated classloader.|[Git](https://gitbox.apache.org/repos/asf/maven-surefire.git) / [GitHub](https://github.com/apache/maven-surefire/)|[Jira SUREFIRE](https://issues.apache.org/jira/browse/SUREFIRE)|
+|[ `verifier`](/plugins/maven-verifier-plugin/)|B|1.1|2015-04-14|Useful for integration tests - verifies the existence of certain conditions.|[Git](https://gitbox.apache.org/repos/asf/maven-verifier-plugin.git) / [GitHub](https://github.com/apache/maven-verifier-plugin/)|[Jira MVERIFIER](https://issues.apache.org/jira/browse/MVERIFIER)|
+|**Packaging types/tools**||||**These plugins relate to packaging respective artifact types.**|||
+|[ `ear`](/plugins/maven-ear-plugin/)|B|3.3.0|2022-10-18|Generate an EAR from the current project.|[Git](https://gitbox.apache.org/repos/asf/maven-ear-plugin.git) / [GitHub](https://github.com/apache/maven-ear-plugin/)|[Jira MEAR](https://issues.apache.org/jira/browse/MEAR)|
+|[ `ejb`](/plugins/maven-ejb-plugin/)|B|3.2.1|2022-04-18|Build an EJB (and optional client) from the current project.|[Git](https://gitbox.apache.org/repos/asf/maven-ejb-plugin.git) / [GitHub](https://github.com/apache/maven-ejb-plugin/)|[Jira MEJB](https://issues.apache.org/jira/browse/MEJB)|
+|[ `jar`](/plugins/maven-jar-plugin/)|B|3.3.0|2022-09-12|Build a JAR from the current project.|[Git](https://gitbox.apache.org/repos/asf/maven-jar-plugin.git) / [GitHub](https://github.com/apache/maven-jar-plugin/)|[Jira MJAR](https://issues.apache.org/jira/browse/MJAR)|
+|[ `rar`](/plugins/maven-rar-plugin/)|B|3.0.0|2022-07-17|Build a RAR from the current project.|[Git](https://gitbox.apache.org/repos/asf/maven-rar-plugin.git) / [GitHub](https://github.com/apache/maven-rar-plugin/)|[Jira MRAR](https://issues.apache.org/jira/browse/MRAR)|
+|[ `war`](/plugins/maven-war-plugin/)|B|3.3.2|2021-09-10|Build a WAR from the current project.|[Git](https://gitbox.apache.org/repos/asf/maven-war-plugin.git) / [GitHub](https://github.com/apache/maven-war-plugin/)|[Jira MWAR](https://issues.apache.org/jira/browse/MWAR)|
+|[ `app-client/acr`](/plugins/maven-acr-plugin/)|B|3.1.0|2018-06-19|Build a JavaEE application client from the current project.|[Git](https://gitbox.apache.org/repos/asf/maven-acr-plugin.git) / [GitHub](https://github.com/apache/maven-acr-plugin/)|[Jira MACR](https://issues.apache.org/jira/browse/MACR)|
+|[ `shade`](/plugins/maven-shade-plugin/)|B|3.4.1|2022-10-27|Build an Uber-JAR from the current project, including dependencies.|[Git](https://gitbox.apache.org/repos/asf/maven-shade-plugin.git) / [GitHub](https://github.com/apache/maven-shade-plugin/)|[Jira MSHADE](https://issues.apache.org/jira/browse/MSHADE)|
+|[ `source`](/plugins/maven-source-plugin/)|B|3.2.1|2019-12-21|Build a source-JAR from the current project.|[Git](https://gitbox.apache.org/repos/asf/maven-source-plugin.git) / [GitHub](https://github.com/apache/maven-source-plugin/)|[Jira MSOURCES](https://issues.apache.org/jira/browse/MSOURCES)|
+|[ `jlink`](/plugins/maven-jlink-plugin/)|B|3.1.0|2020-12-28|Build Java Run Time Image.|[Git](https://gitbox.apache.org/repos/asf/maven-jlink-plugin.git) / [GitHub](https://github.com/apache/maven-jlink-plugin/)|[Jira MJLINK](https://issues.apache.org/jira/browse/MJLINK)|
+|[ `jmod`](/plugins/maven-jmod-plugin/)|B|3.0.0-alpha-1|2017-09-17|Build Java JMod files.|[Git](https://gitbox.apache.org/repos/asf/maven-jmod-plugin.git) / [GitHub](https://github.com/apache/maven-jmod-plugin/)|[Jira MJMOD](https://issues.apache.org/jira/browse/MJMOD)|
+|**Reporting plugins**||||**Plugins which generate reports, are configured as reports in the POM and run under the site generation lifecycle.**|||
+|[ `changelog`](/plugins/maven-changelog-plugin/)|R|2.3|2014-06-24|Generate a list of recent changes from your SCM.|[Git](https://gitbox.apache.org/repos/asf/maven-changelog-plugin.git) / [GitHub](https://github.com/apache/maven-changelog-plugin/)|[Jira MCHANGELOG](https://issues.apache.org/jira/browse/MCHANGELOG)|
+|[ `changes`](/plugins/maven-changes-plugin/)|B+R|2.12.1|2016-11-01|Generate a report from an issue tracker or a change document.|[Git](https://gitbox.apache.org/repos/asf/maven-changes-plugin.git) / [GitHub](https://github.com/apache/maven-changes-plugin/)|[Jira MCHANGES](https://issues.apache.org/jira/browse/MCHANGES)|
+|[ `checkstyle`](/plugins/maven-checkstyle-plugin/)|B+R|3.2.1|2023-01-11|Generate a Checkstyle report.|[Git](https://gitbox.apache.org/repos/asf/maven-checkstyle-plugin.git) / [GitHub](https://github.com/apache/maven-checkstyle-plugin/)|[Jira MCHECKSTYLE](https://issues.apache.org/jira/browse/MCHECKSTYLE)|
+|[ `doap`](/plugins/maven-doap-plugin/)|B|1.2|2015-03-17|Generate a Description of a Project (DOAP) file from a POM.|[Git](https://gitbox.apache.org/repos/asf/maven-doap-plugin.git) / [GitHub](https://github.com/apache/maven-doap-plugin/)|[Jira MDOAP](https://issues.apache.org/jira/browse/MDOAP)|
+|[ `docck`](/plugins/maven-docck-plugin/)|B|1.1|2015-04-03|Documentation checker plugin.|[Git](https://gitbox.apache.org/repos/asf/maven-docck-plugin.git) / [GitHub](https://github.com/apache/maven-docck-plugin/)|[Jira MDOCCK](https://issues.apache.org/jira/browse/MDOCCK)|
+|[ `javadoc`](/plugins/maven-javadoc-plugin/)|B+R|3.4.1|2022-08-13|Generate Javadoc for the project.|[Git](https://gitbox.apache.org/repos/asf/maven-javadoc-plugin.git) / [GitHub](https://github.com/apache/maven-javadoc-plugin/)|[Jira MJAVADOC](https://issues.apache.org/jira/browse/MJAVADOC)|
+|[ `jdeps`](/plugins/maven-jdeps-plugin/)|B|3.1.2|2019-06-12|Run JDK's JDeps tool on the project.|[Git](https://gitbox.apache.org/repos/asf/maven-jdeps-plugin.git) / [GitHub](https://github.com/apache/maven-jdeps-plugin/)|[Jira MJDEPS](https://issues.apache.org/jira/browse/MJDEPS)|
+|[ `jxr`](/jxr/maven-jxr-plugin/)|R|3.3.0|2022-08-16|Generate a source cross reference.|[Git](https://gitbox.apache.org/repos/asf/maven-jxr.git) / [GitHub](https://github.com/apache/maven-jxr/)|[Jira JXR](https://issues.apache.org/jira/browse/JXR)|
+|[ `linkcheck`](/plugins/maven-linkcheck-plugin/)|R|1.2|2014-10-08|Generate a Linkcheck report of your project's documentation.|[Git](https://gitbox.apache.org/repos/asf/maven-linkcheck-plugin.git) / [GitHub](https://github.com/apache/maven-linkcheck-plugin/)|[Jira MLINKCHECK](https://issues.apache.org/jira/browse/MLINKCHECK)|
+|[ `pmd`](/plugins/maven-pmd-plugin/)|B+R|3.20.0|2022-09-11|Generate a PMD report.|[Git](https://gitbox.apache.org/repos/asf/maven-pmd-plugin.git) / [GitHub](https://github.com/apache/maven-pmd-plugin/)|[Jira MPMD](https://issues.apache.org/jira/browse/MPMD)|
+|[ `project-info-reports`](/plugins/maven-project-info-reports-plugin/)|R|3.4.2|2023-01-11|Generate standard project reports.|[Git](https://gitbox.apache.org/repos/asf/maven-project-info-reports-plugin.git) / [GitHub](https://github.com/apache/maven-project-info-reports-plugin/)|[Jira MPIR](https://issues.apache.org/jira/browse/MPIR)|
+|[ `surefire-report`](/surefire/maven-surefire-report-plugin/)|R|3.0.0-M9|2023-02-14|Generate a report based on the results of unit tests.|[Git](https://gitbox.apache.org/repos/asf/maven-surefire.git) / [GitHub](https://github.com/apache/maven-surefire/)|[Jira SUREFIRE](https://issues.apache.org/jira/browse/SUREFIRE)|
+|**Tools**||||**These are miscellaneous tools available through Maven by default.**|||
+|[ `antrun`](/plugins/maven-antrun-plugin/)|B|3.1.0|2022-04-18|Run a set of ant tasks from a phase of the build.|[Git](https://gitbox.apache.org/repos/asf/maven-antrun-plugin.git) / [GitHub](https://github.com/apache/maven-antrun-plugin/)|[Jira MANTRUN](https://issues.apache.org/jira/browse/MANTRUN)|
+|[ `artifact`](/plugins/maven-artifact-plugin/)|B|3.4.0|2023-02-07|Manage artifacts tasks like buildinfo.|[Git](https://gitbox.apache.org/repos/asf/maven-artifact-plugin.git) / [GitHub](https://github.com/apache/maven-artifact-plugin/)|[Jira MARTIFACT](https://issues.apache.org/jira/browse/MARTIFACT)|
+|[ `archetype`](/archetype/maven-archetype-plugin/)|B|3.2.1|2021-12-30|Generate a skeleton project structure from an archetype.|[Git](https://gitbox.apache.org/repos/asf/maven-archetype.git) / [GitHub](https://github.com/apache/maven-archetype/)|[Jira ARCHETYPE](https://issues.apache.org/jira/browse/ARCHETYPE)|
+|[ `assembly`](/plugins/maven-assembly-plugin/)|B|3.4.2|2022-07-20|Build an assembly (distribution) of sources and/or binaries.|[Git](https://gitbox.apache.org/repos/asf/maven-assembly-plugin.git) / [GitHub](https://github.com/apache/maven-assembly-plugin/)|[Jira MASSEMBLY](https://issues.apache.org/jira/browse/MASSEMBLY)|
+|[ `dependency`](/plugins/maven-dependency-plugin/)|B+R|3.5.0|2023-01-11|Dependency manipulation (copy, unpack) and analysis.|[Git](https://gitbox.apache.org/repos/asf/maven-dependency-plugin.git) / [GitHub](https://github.com/apache/maven-dependency-plugin/)|[Jira MDEP](https://issues.apache.org/jira/browse/MDEP)|
+|[ `enforcer`](/enforcer/maven-enforcer-plugin/)|B|3.2.1|2023-01-28|Environmental constraint checking (Maven Version, JDK etc), User Custom Rule Execution.|[Git](https://gitbox.apache.org/repos/asf/maven-enforcer.git) / [GitHub](https://github.com/apache/maven-enforcer/)|[Jira MENFORCER](https://issues.apache.org/jira/browse/MENFORCER)|
+|[ `gpg`](/plugins/maven-gpg-plugin/)|B|3.0.1|2021-05-08|Create signatures for the artifacts and poms.|[Git](https://gitbox.apache.org/repos/asf/maven-gpg-plugin.git) / [GitHub](https://github.com/apache/maven-gpg-plugin/)|[Jira MGPG](https://issues.apache.org/jira/browse/MGPG)|
+|[ `help`](/plugins/maven-help-plugin/)|B|3.3.0|2022-08-14|Get information about the working environment for the project.|[Git](https://gitbox.apache.org/repos/asf/maven-help-plugin.git) / [GitHub](https://github.com/apache/maven-help-plugin/)|[Jira MPH](https://issues.apache.org/jira/browse/MPH)|
+|[ `invoker`](/plugins/maven-invoker-plugin/)|B+R|3.4.0|2022-12-20|Run a set of Maven projects and verify the output.|[Git](https://gitbox.apache.org/repos/asf/maven-invoker-plugin.git) / [GitHub](https://github.com/apache/maven-invoker-plugin/)|[Jira MINVOKER](https://issues.apache.org/jira/browse/MINVOKER)|
+|[ `jarsigner`](/plugins/maven-jarsigner-plugin/)|B|3.0.0|2018-11-06|Signs or verifies project artifacts.|[Git](https://gitbox.apache.org/repos/asf/maven-jarsigner-plugin.git) / [GitHub](https://github.com/apache/maven-jarsigner-plugin/)|[Jira MJARSIGNER](https://issues.apache.org/jira/browse/MJARSIGNER)|
+|[ `jdeprscan`](/plugins/maven-jdeprscan-plugin/)|B|3.0.0-alpha-1|2017-11-15|Run JDK's JDeprScan tool on the project.|[Git](https://gitbox.apache.org/repos/asf/maven-jdeprscan-plugin.git) / [GitHub](https://github.com/apache/maven-jdeprscan-plugin/)|[Jira MJDEPRSCAN](https://issues.apache.org/jira/browse/MJDEPRSCAN)|
+|[ `patch`](/plugins/maven-patch-plugin/)|B|1.2|2015-03-09|Use the gnu patch tool to apply patch files to source code.|[Git](https://gitbox.apache.org/repos/asf/maven-patch-plugin.git) / [GitHub](https://github.com/apache/maven-patch-plugin/)|[Jira MPATCH](https://issues.apache.org/jira/browse/MPATCH)|
+|[ `pdf`](/plugins/maven-pdf-plugin/)|B|1.6.1|2022-08-16|Generate a PDF version of your project's documentation.|[Git](https://gitbox.apache.org/repos/asf/maven-pdf-plugin.git) / [GitHub](https://github.com/apache/maven-pdf-plugin/)|[Jira MPDF](https://issues.apache.org/jira/browse/MPDF)|
+|[ `plugin`](/plugin-tools/maven-plugin-plugin/)|B+R|3.7.1|2023-01-13|Create a Maven plugin descriptor for any mojos found in the source tree, to include in the JAR.|[Git](https://gitbox.apache.org/repos/asf/maven-plugin-tools.git) / [GitHub](https://github.com/apache/maven-plugin-tools/)|[Jira MPLUGIN](https://issues.apache.org/jira/browse/MPLUGIN)|
+|[ `release`](/plugins/maven-release-plugin/)|B|3.0.0-M7|2022-10-29|Release the current project - updating the POM and tagging in the SCM.|[Git](https://gitbox.apache.org/repos/asf/maven-release.git) / [GitHub](https://github.com/apache/maven-release/)|[Jira MRELEASE](https://issues.apache.org/jira/browse/MRELEASE)|
+|[ `remote-resources`](/plugins/maven-remote-resources-plugin/)|B|3.0.0|2022-07-17|Copy remote resources to the output directory for inclusion in the artifact.|[Git](https://gitbox.apache.org/repos/asf/maven-remote-resources-plugin.git) / [GitHub](https://github.com/apache/maven-remote-resources-plugin/)|[Jira MRRESOURCES](https://issues.apache.org/jira/browse/MRRESOURCES)|
+|[ `scm`](/scm/maven-scm-plugin/)|B|2.0.0-M3|2022-10-25|Execute SCM commands for the current project.|[Git](https://gitbox.apache.org/repos/asf/maven-scm.git ) / [GitHub](https://github.com/apache/maven-scm/)|[Jira SCM](https://issues.apache.org/jira/browse/SCM)|
+|[ `scm-publish`](/plugins/maven-scm-publish-plugin/)|B|3.1.0|2020-12-26|Publish your Maven website to a scm location.|[Git](https://gitbox.apache.org/repos/asf/maven-scm-publish-plugin.git) / [GitHub](https://github.com/apache/maven-scm-publish-plugin/)|[Jira MSCMPUB](https://issues.apache.org/jira/browse/MSCMPUB)|
+|[ `scripting`](/plugins/maven-scripting-plugin/)|B|3.0.0|2021-03-01|The Maven Scripting Plugin wraps the Scripting API according to JSR223.|[Git](https://gitbox.apache.org/repos/asf/maven-scripting-plugin.git) / [GitHub](https://github.com/apache/maven-scripting-plugin/)|[Jira MSCRIPTING](https://issues.apache.org/jira/browse/MSCRIPTING)|
+|[ `stage`](/plugins/maven-stage-plugin/)|B|1.0|2015-03-03|Assists with release staging and promotion.|[Git](https://gitbox.apache.org/repos/asf/maven-stage-plugin.git) / [GitHub](https://github.com/apache/maven-stage-plugin/)|[Jira MSTAGE](https://issues.apache.org/jira/browse/MSTAGE)|
+|[ `toolchains`](/plugins/maven-toolchains-plugin/)|B|3.1.0|2022-06-18|Allows to share configuration across plugins.|[Git](https://gitbox.apache.org/repos/asf/maven-toolchains-plugin.git) / [GitHub](https://github.com/apache/maven-toolchains-plugin/)|[Jira MTOOLCHAINS](https://issues.apache.org/jira/browse/MTOOLCHAINS)|
+|[ `wrapper`](/plugins/maven-wrapper-plugin/)|B|3.1.1|2022-05-14|Download and unpack the maven wrapper distribution|[Git](https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git) / [GitHub](https://github.com/apache/maven-wrapper/)|[Jira MWRAPPER](https://issues.apache.org/jira/browse/MWRAPPER)|
\* **B**uild or **R**eporting plugin
There are also some sandbox plugins into our [source repository](https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins).
+
Previous archived versions of plugins reference documentations are [located here](../plugins-archives/).
+
+
### Retired
-| **Plugin** | **Type*** | **Version** | **Retired Date** | **Description** |
-| ---------- | --------- | ----------- | ---------------- | --------------- |
-| [`ant`](/plugins/maven-ant-plugin/) | B | 2.4 | 2019-06-02 | Generate an Ant build file for the project. |
-| [`eclipse`](/plugins/maven-eclipse-plugin/) | B | 2.10 | 2015-10-07 | Generate an Eclipse project files for the current project. |
-| [`idea`](/plugins/maven-idea-plugin/) | B | 2.2.1 | 2013-07-26 | Create/update an IDEA workspace for the current project (individual modules are created as IDEA modules) |
-| [`one`](/plugins/maven-one-plugin/) | B | 1.3 | 2013-07-30 | A plugin for interacting with legacy Maven 1.x repositories and builds. |
-| [`reactor`](/plugins/maven-reactor-plugin/) | B | 1.1 | 2014-03-24 | Build a subset of interdependent projects in a reactor (Maven 2 only). |
-| [`repository`](/plugins/maven-repository-plugin/) | B | 2.4 | 2019-04-30 | Plugin to help with repository-based tasks. |
+
+|**Plugin**|**Type***|**Version**|**Retired Date**|**Description**|
+|---|---|---|---|---|
+|[ `ant`](/plugins/maven-ant-plugin/)|B|2.4|2019-06-02|Generate an Ant build file for the project.|
+|[ `eclipse`](/plugins/maven-eclipse-plugin/)|B|2.10|2015-10-07|Generate an Eclipse project files for the current project.|
+|[ `idea`](/plugins/maven-idea-plugin/)|B|2.2.1|2013-07-26|Create/update an IDEA workspace for the current project (individual modules are created as IDEA modules)|
+|[ `one`](/plugins/maven-one-plugin/)|B|1.3|2013-07-30|A plugin for interacting with legacy Maven 1.x repositories and builds.|
+|[ `reactor`](/plugins/maven-reactor-plugin/)|B|1.1|2014-03-24|Build a subset of interdependent projects in a reactor (Maven 2 only).|
+|[ `repository`](/plugins/maven-repository-plugin/)|B|2.4|2019-04-30|Plugin to help with repository-based tasks.|
+
### Outside The Maven Land
+
#### At MojoHaus (formerly known as codehaus.org)
+
There are also [many plug-ins](https://www.mojohaus.org/plugins.html) available at the [ MojoHaus](https://github.com/mojohaus) project at GitHub.
+
Here are a few common ones:
-| **Plugin** (see [complete list with version](https://www.mojohaus.org/plugins.html)) | **Description** |
-| --- | --- |
-| [`animal-sniffer`](https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/) | Build signatures of APIs (JDK for example) and checks your classes against them. |
-| [`build-helper`](https://www.mojohaus.org/build-helper-maven-plugin/) | Attach extra artifacts and source directories to build. |
-| [`buildplan`](https://www.mojohaus.org/buildplan-maven-plugin/) | Inspect the lifecycle of your build. |
-| [`castor`](https://www.mojohaus.org/castor-maven-plugin/) | Generate sources from an XSD using Castor. |
-| [`clirr`](https://www.mojohaus.org/clirr-maven-plugin/) | Compare binaries or sources for compatibility using Clirr |
-| [`javacc`](https://www.mojohaus.org/javacc-maven-plugin/) | Generate sources from a JavaCC grammar. |
-| [`jdepend`](https://www.mojohaus.org/jdepend-maven-plugin/) | Generate a report on code metrics using JDepend. |
-| [`nar-maven-plugin`](https://maven-nar.github.io/) | Compiles C, C++, Fortran for different architectures. |
-| [`native`](https://www.mojohaus.org/maven-native/native-maven-plugin/) | Compiles C and C++ code with native compilers. |
-| [`sql`](https://www.mojohaus.org/sql-maven-plugin/) | Executes SQL scripts from files or inline. |
-| [`taglist`](https://www.mojohaus.org/taglist-maven-plugin/) | Generate a list of tasks based on tags in your code. |
-| [`versions`](https://www.mojohaus.org/versions-maven-plugin/) | Manage versions of your project, its modules, dependencies and plugins. |
+
+|**Plugin** (see [complete list with version](https://www.mojohaus.org/plugins.html))|**Description**|
+|---|---|
+|[ `animal-sniffer`](https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/)|Build signatures of APIs (JDK for example) and checks your classes against them.|
+|[ `build-helper`](https://www.mojohaus.org/build-helper-maven-plugin/)|Attach extra artifacts and source directories to build.|
+|[ `buildplan`](https://www.mojohaus.org/buildplan-maven-plugin/)|Inspect the lifecycle of your build.|
+|[ `castor`](https://www.mojohaus.org/castor-maven-plugin/)|Generate sources from an XSD using Castor.|
+|[ `clirr`](https://www.mojohaus.org/clirr-maven-plugin/)|Compare binaries or sources for compatibility using Clirr|
+|[ `javacc`](https://www.mojohaus.org/javacc-maven-plugin/)|Generate sources from a JavaCC grammar.|
+|[ `jdepend`](https://www.mojohaus.org/jdepend-maven-plugin/)|Generate a report on code metrics using JDepend.|
+|[ `nar-maven-plugin`](https://maven-nar.github.io/)|Compiles C, C++, Fortran for different architectures.|
+|[ `native`](https://www.mojohaus.org/maven-native/native-maven-plugin/)|Compiles C and C++ code with native compilers.|
+|[ `sql`](https://www.mojohaus.org/sql-maven-plugin/)|Executes SQL scripts from files or inline.|
+|[ `taglist`](https://www.mojohaus.org/taglist-maven-plugin/)|Generate a list of tasks based on tags in your code.|
+|[ `versions`](https://www.mojohaus.org/versions-maven-plugin/)|Manage versions of your project, its modules, dependencies and plugins.|
+
#### Misc
+
A number of other projects provide their own Maven plugins. This includes:
-| **Plugin** | **Maintainer** | **Description** |
-| --- | --- | --- |
-| [`cargo`](https://codehaus-cargo.github.io/) | [Cargo Project](https://codehaus-cargo.github.io/) | Start/stop/configure J2EE containers and deploy to them. |
-| [`clover`](https://confluence.atlassian.com/display/CLOVER/Clover-for-Maven+2) | [Atlassian Clover](https://www.atlassian.com/software/clover/) | Generate a Clover report. |
-| [`jetty`](https://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html) | [Jetty Project](https://www.eclipse.org/jetty/) | Jetty Run a Jetty container for rapid webapp development. |
-| [`jalopy`](http://www.triemax.com/products/jalopy/manual/plugin-maven.html) | [Triemax](http://www.triemax.com/) | Use Jalopy to format your source code. |
-| [`rat`](https://creadur.apache.org/rat/) | [Apache Creadur Project](https://creadur.apache.org/) | Release Audit Tool (RAT) to verify files. |
-| [`Genesis Plugins`](https://geronimo.apache.org/maven/genesis/plugins/tools-maven-plugin/index.html) | [Apache Geronimo Project](https://geronimo.apache.org/) | Verify legal files in artifacts. |
-| [`Apache Tomcat`](https://tomcat.apache.org/maven-plugin.html) | [Apache Tomcat Project](https://tomcat.apache.org/maven-plugin.html) | Run an Apache Tomcat container for rapid webapp development. |
-| [`OWASP dependency-check`](https://jeremylong.github.io/DependencyCheck/) | [OWASP Dependency-check Project](https://www.owasp.org/index.php/OWASP_Dependency_Check) | Run OWASP Dependency-Check, a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. |
-| [`CycloneDX`](https://github.com/CycloneDX/cyclonedx-maven-plugin) | [CycloneDX Project](https://cyclonedx.org/) | Generate Software Bill of Materials (SBOM) in CycloneDX format. |
-| [`pgpverify`](https://www.simplify4u.org/pgpverify-maven-plugin/) | [Simplify4U](https://www.simplify4u.org/) | Verify PGP signature of all project dependencies. |
+
+|**Plugin**|**Maintainer**|**Description**|
+|---|---|---|
+|[ `cargo`](https://codehaus-cargo.github.io/)|[Cargo Project](https://codehaus-cargo.github.io/)|Start/stop/configure J2EE containers and deploy to them.|
+|[ `clover`](https://confluence.atlassian.com/display/CLOVER/Clover-for-Maven+2)|[Atlassian Clover](https://www.atlassian.com/software/clover/)|Generate a Clover report.|
+|[ `jetty`](https://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html)|[Jetty Project](https://www.eclipse.org/jetty/)|Jetty Run a Jetty container for rapid webapp development.|
+|[ `jalopy`](http://www.triemax.com/products/jalopy/manual/plugin-maven.html)|[Triemax](http://www.triemax.com/)|Use Jalopy to format your source code.|
+|[ `rat`](https://creadur.apache.org/rat/)|[Apache Creadur Project](https://creadur.apache.org/)|Release Audit Tool (RAT) to verify files.|
+|[ `Genesis Plugins`](https://geronimo.apache.org/maven/genesis/plugins/tools-maven-plugin/index.html)|[Apache Geronimo Project](https://geronimo.apache.org/)|Verify legal files in artifacts.|
+|[ `Apache Tomcat`](https://tomcat.apache.org/maven-plugin.html)|[Apache Tomcat Project](https://tomcat.apache.org/maven-plugin.html)|Run an Apache Tomcat container for rapid webapp development.|
+|[ `OWASP dependency-check`](https://jeremylong.github.io/DependencyCheck/)|[OWASP Dependency-check Project](https://www.owasp.org/index.php/OWASP_Dependency_Check)|Run OWASP Dependency-Check, a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities.|
+|[ `CycloneDX`](https://github.com/CycloneDX/cyclonedx-maven-plugin)|[CycloneDX Project](https://cyclonedx.org/)|Generate Software Bill of Materials (SBOM) in CycloneDX format.|
+|[ `pgpverify`](https://www.simplify4u.org/pgpverify-maven-plugin/)|[Simplify4U](https://www.simplify4u.org/)|Verify PGP signature of all project dependencies.|
+
### Resources
+
+
1 [Guide to Configuring Plugins](../guides/mini/guide-configuring-plugins.html)
+
+
+
[maven-site] 11/14: Revert "surefire 3.0.0-M9"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit 9c5f1ff1b5061ae6f7a3e4adcaa898dcf4c6ecfb
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:34:39 2023 +0100
Revert "surefire 3.0.0-M9"
This reverts commit 2fa0e38aa8289f445aa26b49db789ab77d3e9d6f.
---
content/markdown/plugins/index.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/content/markdown/plugins/index.md b/content/markdown/plugins/index.md
index e3564f51..484bd08b 100644
--- a/content/markdown/plugins/index.md
+++ b/content/markdown/plugins/index.md
@@ -53,7 +53,7 @@ under the License.
|[ `install`](/plugins/maven-install-plugin/)|B|3.1.0|2022-11-13|Install the built artifact into the local repository.|[Git](https://gitbox.apache.org/repos/asf/maven-install-plugin.git) / [GitHub](https://github.com/apache/maven-install-plugin/)|[Jira MINSTALL](https://issues.apache.org/jira/browse/MINSTALL)|
|[ `resources`](/plugins/maven-resources-plugin/)|B|3.3.0|2022-07-23|Copy the resources to the output directory for including in the JAR.|[Git](https://gitbox.apache.org/repos/asf/maven-resources-plugin.git) / [GitHub](https://github.com/apache/maven-resources-plugin/)|[Jira MRESOURCES](https://issues.apache.org/jira/browse/MRESOURCES)|
|[ `site`](/plugins/maven-site-plugin/)|B|4.0.0-M4|2022-12-02|Generate a site for the current project.|[Git](https://gitbox.apache.org/repos/asf/maven-site-plugin.git) / [GitHub](https://github.com/apache/maven-site-plugin/)|[Jira MSITE](https://issues.apache.org/jira/browse/MSITE)|
-|[ `surefire`](/surefire/maven-surefire-plugin/)|B|3.0.0-M9|2023-02-14|Run the JUnit unit tests in an isolated classloader.|[Git](https://gitbox.apache.org/repos/asf/maven-surefire.git) / [GitHub](https://github.com/apache/maven-surefire/)|[Jira SUREFIRE](https://issues.apache.org/jira/browse/SUREFIRE)|
+|[ `surefire`](/surefire/maven-surefire-plugin/)|B|3.0.0-M8|2023-01-11|Run the JUnit unit tests in an isolated classloader.|[Git](https://gitbox.apache.org/repos/asf/maven-surefire.git) / [GitHub](https://github.com/apache/maven-surefire/)|[Jira SUREFIRE](https://issues.apache.org/jira/browse/SUREFIRE)|
|[ `verifier`](/plugins/maven-verifier-plugin/)|B|1.1|2015-04-14|Useful for integration tests - verifies the existence of certain conditions.|[Git](https://gitbox.apache.org/repos/asf/maven-verifier-plugin.git) / [GitHub](https://github.com/apache/maven-verifier-plugin/)|[Jira MVERIFIER](https://issues.apache.org/jira/browse/MVERIFIER)|
|**Packaging types/tools**||||**These plugins relate to packaging respective artifact types.**|||
|[ `ear`](/plugins/maven-ear-plugin/)|B|3.3.0|2022-10-18|Generate an EAR from the current project.|[Git](https://gitbox.apache.org/repos/asf/maven-ear-plugin.git) / [GitHub](https://github.com/apache/maven-ear-plugin/)|[Jira MEAR](https://issues.apache.org/jira/browse/MEAR)|
@@ -78,7 +78,7 @@ under the License.
|[ `linkcheck`](/plugins/maven-linkcheck-plugin/)|R|1.2|2014-10-08|Generate a Linkcheck report of your project's documentation.|[Git](https://gitbox.apache.org/repos/asf/maven-linkcheck-plugin.git) / [GitHub](https://github.com/apache/maven-linkcheck-plugin/)|[Jira MLINKCHECK](https://issues.apache.org/jira/browse/MLINKCHECK)|
|[ `pmd`](/plugins/maven-pmd-plugin/)|B+R|3.20.0|2022-09-11|Generate a PMD report.|[Git](https://gitbox.apache.org/repos/asf/maven-pmd-plugin.git) / [GitHub](https://github.com/apache/maven-pmd-plugin/)|[Jira MPMD](https://issues.apache.org/jira/browse/MPMD)|
|[ `project-info-reports`](/plugins/maven-project-info-reports-plugin/)|R|3.4.2|2023-01-11|Generate standard project reports.|[Git](https://gitbox.apache.org/repos/asf/maven-project-info-reports-plugin.git) / [GitHub](https://github.com/apache/maven-project-info-reports-plugin/)|[Jira MPIR](https://issues.apache.org/jira/browse/MPIR)|
-|[ `surefire-report`](/surefire/maven-surefire-report-plugin/)|R|3.0.0-M9|2023-02-14|Generate a report based on the results of unit tests.|[Git](https://gitbox.apache.org/repos/asf/maven-surefire.git) / [GitHub](https://github.com/apache/maven-surefire/)|[Jira SUREFIRE](https://issues.apache.org/jira/browse/SUREFIRE)|
+|[ `surefire-report`](/surefire/maven-surefire-report-plugin/)|R|3.0.0-M8|2023-01-11|Generate a report based on the results of unit tests.|[Git](https://gitbox.apache.org/repos/asf/maven-surefire.git) / [GitHub](https://github.com/apache/maven-surefire/)|[Jira SUREFIRE](https://issues.apache.org/jira/browse/SUREFIRE)|
|**Tools**||||**These are miscellaneous tools available through Maven by default.**|||
|[ `antrun`](/plugins/maven-antrun-plugin/)|B|3.1.0|2022-04-18|Run a set of ant tasks from a phase of the build.|[Git](https://gitbox.apache.org/repos/asf/maven-antrun-plugin.git) / [GitHub](https://github.com/apache/maven-antrun-plugin/)|[Jira MANTRUN](https://issues.apache.org/jira/browse/MANTRUN)|
|[ `artifact`](/plugins/maven-artifact-plugin/)|B|3.4.0|2023-02-07|Manage artifacts tasks like buildinfo.|[Git](https://gitbox.apache.org/repos/asf/maven-artifact-plugin.git) / [GitHub](https://github.com/apache/maven-artifact-plugin/)|[Jira MARTIFACT](https://issues.apache.org/jira/browse/MARTIFACT)|
[maven-site] 06/14: Revert "many plugins released"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit 591a1fd2fac42afc48597fee6921c430330896dc
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:33:30 2023 +0100
Revert "many plugins released"
This reverts commit ae4c8542514c46a61772a59ff532c15fca1f90b3.
---
content/markdown/plugins/index.md | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/content/markdown/plugins/index.md b/content/markdown/plugins/index.md
index 8edb86f8..1a9ab4de 100644
--- a/content/markdown/plugins/index.md
+++ b/content/markdown/plugins/index.md
@@ -44,11 +44,11 @@ under the License.
| **Core plugins** | | | | **Plugins corresponding to default core phases (ie. clean, compile). They may have multiple goals as well.** | | |
| [`clean`](/plugins/maven-clean-plugin/) | B | 3.2.0 | 2022-04-01 | Clean up after the build. | [Git](https://gitbox.apache.org/repos/asf/maven-clean-plugin.git) / [GitHub](https://github.com/apache/maven-clean-plugin/) | [Jira MCLEAN](https://issues.apache.org/jira/browse/MCLEAN) |
| [`compiler`](/plugins/maven-compiler-plugin/) | B | 3.10.1 | 2022-03-11 | Compiles Java sources. | [Git](https://gitbox.apache.org/repos/asf/maven-compiler-plugin.git) / [GitHub](https://github.com/apache/maven-compiler-plugin/) | [Jira MCOMPILER](https://issues.apache.org/jira/browse/MCOMPILER) |
-| [`deploy`](/plugins/maven-deploy-plugin/) | B | 3.1.0 | 2023-02-06 | Deploy the built artifact to the remote repository. | [Git](https://gitbox.apache.org/repos/asf/maven-deploy-plugin.git) / [GitHub](https://github.com/apache/maven-deploy-plugin/) | [Jira MDEPLOY](https://issues.apache.org/jira/browse/MDEPLOY) |
-| [`failsafe`](/surefire/maven-failsafe-plugin/) | B | 3.0.0-M9 | 2023-02-14 | Run the JUnit integration tests in an isolated classloader. | [Git](https://gitbox.apache.org/repos/asf/maven-surefire.git) / [GitHub](https://github.com/apache/maven-surefire/) | [Jira SUREFIRE](https://issues.apache.org/jira/browse/SUREFIRE) |
+| [`deploy`](/plugins/maven-deploy-plugin/) | B | 3.0.0 | 2022-07-16 | Deploy the built artifact to the remote repository. | [Git](https://gitbox.apache.org/repos/asf/maven-deploy-plugin.git) / [GitHub](https://github.com/apache/maven-deploy-plugin/) | [Jira MDEPLOY](https://issues.apache.org/jira/browse/MDEPLOY) |
+| [`failsafe`](/surefire/maven-failsafe-plugin/) | B | 3.0.0-M8 | 2023-01-11 | Run the JUnit integration tests in an isolated classloader. | [Git](https://gitbox.apache.org/repos/asf/maven-surefire.git) / [GitHub](https://github.com/apache/maven-surefire/) | [Jira SUREFIRE](https://issues.apache.org/jira/browse/SUREFIRE) |
| [`install`](/plugins/maven-install-plugin/) | B | 3.1.0 | 2022-11-13 | Install the built artifact into the local repository. | [Git](https://gitbox.apache.org/repos/asf/maven-install-plugin.git) / [GitHub](https://github.com/apache/maven-install-plugin/) | [Jira MINSTALL](https://issues.apache.org/jira/browse/MINSTALL) |
| [`resources`](/plugins/maven-resources-plugin/) | B | 3.3.0 | 2022-07-23 | Copy the resources to the output directory for including in the JAR. | [Git](https://gitbox.apache.org/repos/asf/maven-resources-plugin.git) / [GitHub](https://github.com/apache/maven-resources-plugin/) | [Jira MRESOURCES](https://issues.apache.org/jira/browse/MRESOURCES) |
-| [`site`](/plugins/maven-site-plugin/) | B | 4.0.0-M5 | 2023-02-11 | Generate a site for the current project. | [Git](https://gitbox.apache.org/repos/asf/maven-site-plugin.git) / [GitHub](https://github.com/apache/maven-site-plugin/) | [Jira MSITE](https://issues.apache.org/jira/browse/MSITE) |
+| [`site`](/plugins/maven-site-plugin/) | B | 4.0.0-M4 | 2022-12-02 | Generate a site for the current project. | [Git](https://gitbox.apache.org/repos/asf/maven-site-plugin.git) / [GitHub](https://github.com/apache/maven-site-plugin/) | [Jira MSITE](https://issues.apache.org/jira/browse/MSITE) |
| [`surefire`](/surefire/maven-surefire-plugin/) | B | 3.0.0-M9 | 2023-02-14 | Run the JUnit unit tests in an isolated classloader. | [Git](https://gitbox.apache.org/repos/asf/maven-surefire.git) / [GitHub](https://github.com/apache/maven-surefire/) | [Jira SUREFIRE](https://issues.apache.org/jira/browse/SUREFIRE) |
| [`verifier`](/plugins/maven-verifier-plugin/) | B | 1.1 | 2015-04-14 | Useful for integration tests - verifies the existence of certain conditions. | [Git](https://gitbox.apache.org/repos/asf/maven-verifier-plugin.git) / [GitHub](https://github.com/apache/maven-verifier-plugin/) | [Jira MVERIFIER](https://issues.apache.org/jira/browse/MVERIFIER) |
| **Packaging types/tools** | | | | **These plugins relate to packaging respective artifact types.** | | |
@@ -68,7 +68,7 @@ under the License.
| [`checkstyle`](/plugins/maven-checkstyle-plugin/) | B+R | 3.2.1 | 2023-01-11 | Generate a Checkstyle report. | [Git](https://gitbox.apache.org/repos/asf/maven-checkstyle-plugin.git) / [GitHub](https://github.com/apache/maven-checkstyle-plugin/) | [Jira MCHECKSTYLE](https://issues.apache.org/jira/browse/MCHECKSTYLE) |
| [`doap`](/plugins/maven-doap-plugin/) | B | 1.2 | 2015-03-17 | Generate a Description of a Project (DOAP) file from a POM. | [Git](https://gitbox.apache.org/repos/asf/maven-doap-plugin.git) / [GitHub](https://github.com/apache/maven-doap-plugin/) | [Jira MDOAP](https://issues.apache.org/jira/browse/MDOAP) |
| [`docck`](/plugins/maven-docck-plugin/) | B | 1.1 | 2015-04-03 | Documentation checker plugin. | [Git](https://gitbox.apache.org/repos/asf/maven-docck-plugin.git) / [GitHub](https://github.com/apache/maven-docck-plugin/) | [Jira MDOCCK](https://issues.apache.org/jira/browse/MDOCCK) |
-| [`javadoc`](/plugins/maven-javadoc-plugin/) | B+R | 3.5.0 | 2023-02-12 | Generate Javadoc for the project. | [Git](https://gitbox.apache.org/repos/asf/maven-javadoc-plugin.git) / [GitHub](https://github.com/apache/maven-javadoc-plugin/) | [Jira MJAVADOC](https://issues.apache.org/jira/browse/MJAVADOC) |
+| [`javadoc`](/plugins/maven-javadoc-plugin/) | B+R | 3.4.1 | 2022-08-13 | Generate Javadoc for the project. | [Git](https://gitbox.apache.org/repos/asf/maven-javadoc-plugin.git) / [GitHub](https://github.com/apache/maven-javadoc-plugin/) | [Jira MJAVADOC](https://issues.apache.org/jira/browse/MJAVADOC) |
| [`jdeps`](/plugins/maven-jdeps-plugin/) | B | 3.1.2 | 2019-06-12 | Run JDK's JDeps tool on the project. | [Git](https://gitbox.apache.org/repos/asf/maven-jdeps-plugin.git) / [GitHub](https://github.com/apache/maven-jdeps-plugin/) | [Jira MJDEPS](https://issues.apache.org/jira/browse/MJDEPS) |
| [`jxr`](/jxr/maven-jxr-plugin/) | R | 3.3.0 | 2022-08-16 | Generate a source cross reference. | [Git](https://gitbox.apache.org/repos/asf/maven-jxr.git) / [GitHub](https://github.com/apache/maven-jxr/) | [Jira JXR](https://issues.apache.org/jira/browse/JXR) |
| [`linkcheck`](/plugins/maven-linkcheck-plugin/) | R | 1.2 | 2014-10-08 | Generate a Linkcheck report of your project's documentation. | [Git](https://gitbox.apache.org/repos/asf/maven-linkcheck-plugin.git) / [GitHub](https://github.com/apache/maven-linkcheck-plugin/) | [Jira MLINKCHECK](https://issues.apache.org/jira/browse/MLINKCHECK) |
@@ -84,7 +84,7 @@ under the License.
| [`enforcer`](/enforcer/maven-enforcer-plugin/) | B | 3.2.1 | 2023-01-28 | Environmental constraint checking (Maven Version, JDK etc), User Custom Rule Execution. | [Git](https://gitbox.apache.org/repos/asf/maven-enforcer.git) / [GitHub](https://github.com/apache/maven-enforcer/) | [Jira MENFORCER](https://issues.apache.org/jira/browse/MENFORCER) |
| [`gpg`](/plugins/maven-gpg-plugin/) | B | 3.0.1 | 2021-05-08 | Create signatures for the artifacts and poms. | [Git](https://gitbox.apache.org/repos/asf/maven-gpg-plugin.git) / [GitHub](https://github.com/apache/maven-gpg-plugin/) | [Jira MGPG](https://issues.apache.org/jira/browse/MGPG) |
| [`help`](/plugins/maven-help-plugin/) | B | 3.3.0 | 2022-08-14 | Get information about the working environment for the project. | [Git](https://gitbox.apache.org/repos/asf/maven-help-plugin.git) / [GitHub](https://github.com/apache/maven-help-plugin/) | [Jira MPH](https://issues.apache.org/jira/browse/MPH) |
-| [`invoker`](/plugins/maven-invoker-plugin/) | B+R | 3.5.0 | 2023-02-12 | Run a set of Maven projects and verify the output. | [Git](https://gitbox.apache.org/repos/asf/maven-invoker-plugin.git) / [GitHub](https://github.com/apache/maven-invoker-plugin/) | [Jira MINVOKER](https://issues.apache.org/jira/browse/MINVOKER) |
+| [`invoker`](/plugins/maven-invoker-plugin/) | B+R | 3.4.0 | 2022-12-20 | Run a set of Maven projects and verify the output. | [Git](https://gitbox.apache.org/repos/asf/maven-invoker-plugin.git) / [GitHub](https://github.com/apache/maven-invoker-plugin/) | [Jira MINVOKER](https://issues.apache.org/jira/browse/MINVOKER) |
| [`jarsigner`](/plugins/maven-jarsigner-plugin/) | B | 3.0.0 | 2018-11-06 | Signs or verifies project artifacts. | [Git](https://gitbox.apache.org/repos/asf/maven-jarsigner-plugin.git) / [GitHub](https://github.com/apache/maven-jarsigner-plugin/) | [Jira MJARSIGNER](https://issues.apache.org/jira/browse/MJARSIGNER) |
| [`jdeprscan`](/plugins/maven-jdeprscan-plugin/) | B | 3.0.0-alpha-1 | 2017-11-15 | Run JDK's JDeprScan tool on the project. | [Git](https://gitbox.apache.org/repos/asf/maven-jdeprscan-plugin.git) / [GitHub](https://github.com/apache/maven-jdeprscan-plugin/) | [Jira MJDEPRSCAN](https://issues.apache.org/jira/browse/MJDEPRSCAN) |
| [`patch`](/plugins/maven-patch-plugin/) | B | 1.2 | 2015-03-09 | Use the gnu patch tool to apply patch files to source code. | [Git](https://gitbox.apache.org/repos/asf/maven-patch-plugin.git) / [GitHub](https://github.com/apache/maven-patch-plugin/) | [Jira MPATCH](https://issues.apache.org/jira/browse/MPATCH) |
[maven-site] 02/14: Revert "(doc) lint markdown files"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit 763c0ed315da0dccee48589fba1571886bc1dad4
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:31:15 2023 +0100
Revert "(doc) lint markdown files"
This reverts commit dbcc0c8feef3dc2e1c725e24bdf0fb230c5dd079.
---
content/markdown/aether.md | 2 +-
content/markdown/archives/maven-2.x/index.md | 2 +-
.../maven-2.x/maven-2.1-architectural-goals.md | 73 +++---
content/markdown/background/history-of-maven.md | 4 +-
content/markdown/background/philosophy-of-maven.md | 2 +-
content/markdown/code-quality-management.md | 10 +-
content/markdown/configure.md | 36 +--
.../markdown/developers/committer-environment.md | 20 +-
content/markdown/developers/committer-settings.md | 14 +-
content/markdown/developers/compatibility-plan.md | 42 +++-
content/markdown/developers/conventions/code.md | 133 +++++++---
content/markdown/developers/conventions/git.md | 77 +++++-
content/markdown/developers/conventions/jira.md | 2 +-
content/markdown/developers/dependency-policies.md | 30 ++-
content/markdown/developers/index.md | 75 ++++--
content/markdown/developers/release/index.md | 14 +-
.../developers/release/maven-core-release.md | 7 +-
.../release/maven-project-release-procedure.md | 117 +++++++--
.../developers/release/parent-pom-release.md | 26 +-
.../markdown/developers/release/pmc-gpg-keys.md | 20 ++
.../markdown/developers/retirement-plan-plugins.md | 28 ++-
.../component-reference-documentation-helper.md | 2 +-
.../deploy-component-reference-documentation.md | 54 +++-
.../developers/website/deploy-maven-website.md | 55 +++-
content/markdown/developers/website/index.md | 31 ++-
.../developers/website/website-overview.md | 9 +-
.../developers/welcome-to-new-committers.md | 29 ++-
content/markdown/docs/3.2.1/release-notes.md | 4 +
content/markdown/docs/3.2.2/release-notes.md | 3 +-
content/markdown/docs/3.2.3/release-notes.md | 5 +
content/markdown/docs/3.2.5/release-notes.md | 1 +
content/markdown/docs/3.3.1/release-notes.md | 70 +++---
content/markdown/docs/3.3.3/release-notes.md | 1 +
content/markdown/docs/3.3.9/release-notes.md | 125 +++++-----
.../markdown/docs/3.5.0-alpha-1/release-notes.md | 200 ++++++++-------
.../markdown/docs/3.5.0-beta-1/release-notes.md | 74 +++---
content/markdown/docs/3.5.0/release-notes.md | 39 ++-
content/markdown/docs/3.5.2/release-notes.md | 38 ++-
content/markdown/docs/3.5.3/release-notes.md | 1 +
content/markdown/docs/3.5.4/release-notes.md | 6 +-
content/markdown/docs/3.6.0/release-notes.md | 39 ++-
content/markdown/docs/3.6.1/release-notes.md | 176 ++++++-------
content/markdown/docs/3.6.2/release-notes.md | 5 +-
content/markdown/docs/3.6.3/release-notes.md | 9 +-
content/markdown/docs/3.8.1/release-notes.md | 30 +--
content/markdown/docs/3.8.3/release-notes.md | 6 +-
content/markdown/docs/3.8.4/release-notes.md | 5 +-
content/markdown/docs/3.8.5/release-notes.md | 2 +-
content/markdown/docs/3.8.6/release-notes.md | 4 +-
content/markdown/docs/3.8.7/release-notes.md | 6 +-
content/markdown/docs/3.9.0/release-notes.md | 48 ++--
.../markdown/docs/4.0.0-alpha-2/release-notes.md | 8 +-
.../markdown/docs/4.0.0-alpha-3/release-notes.md | 6 +-
.../markdown/docs/4.0.0-alpha-4/release-notes.md | 10 +-
content/markdown/examples/index.md | 6 +-
.../examples/injecting-properties-via-settings.md | 14 ++
content/markdown/faq-unoffical.md | 228 ++++++-----------
content/markdown/glossary.md | 24 +-
.../guides/development/guide-building-maven.md | 37 ++-
.../guides/development/guide-committer-school.md | 47 +++-
.../development/guide-documentation-style.md | 47 +++-
.../markdown/guides/development/guide-helping.md | 62 +++--
.../guides/development/guide-maven-development.md | 117 +++++++--
.../development/guide-plugin-documentation.md | 161 +++++++++---
.../guide-testing-development-plugins.md | 43 +++-
.../guides/development/guide-testing-releases.md | 67 +++--
content/markdown/guides/getting-started/index.md | 277 +++++++++++++++++----
.../getting-started/maven-in-five-minutes.md | 92 ++++++-
.../getting-started/windows-prerequisites.md | 18 ++
.../introduction/introduction-to-archetypes.md | 19 ++
.../introduction-to-dependency-mechanism.md | 144 +++++++++--
...uction-to-optional-and-excludes-dependencies.md | 65 ++++-
.../introduction-to-plugin-prefix-mapping.md | 43 +++-
.../guides/introduction/introduction-to-plugins.md | 19 ++
.../introduction/introduction-to-profiles.md | 272 ++++++++++++++++----
.../introduction/introduction-to-repositories.md | 50 ++++
.../introduction/introduction-to-the-lifecycle.md | 124 ++++++++-
.../guides/introduction/introduction-to-the-pom.md | 213 +++++++++++++---
...ntroduction-to-the-standard-directory-layout.md | 10 +
.../guides/mini/guide-3rd-party-jars-local.md | 12 +-
.../guides/mini/guide-3rd-party-jars-remote.md | 19 ++
.../guides/mini/guide-archive-configuration.md | 10 +
content/markdown/guides/mini/guide-assemblies.md | 16 ++
.../markdown/guides/mini/guide-attached-tests.md | 7 +
.../guides/mini/guide-bash-m2-completion.md | 3 +
.../guide-building-for-different-environments.md | 47 +++-
.../guides/mini/guide-configuring-maven.md | 72 +++++-
.../guides/mini/guide-configuring-plugins.md | 172 +++++++++++--
.../guides/mini/guide-creating-archetypes.md | 54 +++-
.../guides/mini/guide-default-execution-ids.md | 47 +++-
.../mini/guide-deployment-security-settings.md | 10 +-
content/markdown/guides/mini/guide-encryption.md | 101 +++++++-
.../guides/mini/guide-generating-sources.md | 6 +
.../markdown/guides/mini/guide-http-settings.md | 150 +++++++++--
.../guide-large-scale-centralized-deployments.md | 63 ++++-
content/markdown/guides/mini/guide-manifest.md | 2 +
.../guides/mini/guide-maven-classloading.md | 63 ++++-
.../markdown/guides/mini/guide-mirror-settings.md | 58 ++++-
.../guides/mini/guide-multiple-modules-4.md | 2 +
.../markdown/guides/mini/guide-multiple-modules.md | 59 +++--
.../guides/mini/guide-multiple-repositories.md | 24 ++
.../guides/mini/guide-naming-conventions.md | 22 +-
.../markdown/guides/mini/guide-new-committers.md | 6 +
content/markdown/guides/mini/guide-proxies.md | 10 +
content/markdown/guides/mini/guide-releasing.md | 90 ++++++-
content/markdown/guides/mini/guide-relocation.md | 36 +++
.../markdown/guides/mini/guide-repository-ssl.md | 41 ++-
.../guides/mini/guide-reproducible-builds.md | 65 ++++-
content/markdown/guides/mini/guide-site.md | 106 ++++++--
.../markdown/guides/mini/guide-snippet-macro.md | 32 ++-
content/markdown/guides/mini/guide-using-ant.md | 6 +
.../markdown/guides/mini/guide-using-extensions.md | 32 ++-
.../markdown/guides/mini/guide-using-modello.md | 19 +-
.../mini/guide-using-one-source-directory.md | 56 ++++-
.../markdown/guides/mini/guide-using-toolchains.md | 25 +-
.../markdown/guides/mini/guide-wagon-providers.md | 20 ++
.../guides/plugin/guide-java-plugin-development.md | 33 +--
.../plugin/guide-java-report-plugin-development.md | 126 ++++++++--
content/markdown/ide.md | 6 +-
content/markdown/maven-1.x-eol.md | 15 +-
content/markdown/maven-2.x-eol.md | 3 +-
content/markdown/maven-ci-friendly.md | 12 +-
content/markdown/maven-conventions.md | 3 +-
content/markdown/maven-features.md | 28 ++-
content/markdown/maven-jsr330.md | 6 +-
content/markdown/maven-logging.md | 6 +-
content/markdown/plugin-developers/common-bugs.md | 109 +++++++-
.../markdown/plugin-developers/cookbook/index.md | 9 +-
.../cookbook/plexus-plugin-upgrade.md | 33 ++-
content/markdown/plugin-developers/index.md | 41 +--
.../plugin-developers/plugin-documenting.md | 14 +-
.../markdown/plugin-developers/plugin-testing.md | 37 +++
content/markdown/plugins/index.md | 198 +++++++--------
content/markdown/plugins/localization.md | 72 ++++--
content/markdown/privacy-policy.md | 11 +-
content/markdown/project-roles.md | 94 +++----
content/markdown/reference/maven-classloading.md | 7 +-
content/markdown/repositories/artifacts.md | 44 ++--
content/markdown/repositories/index.md | 5 +-
content/markdown/repositories/layout.md | 6 +-
content/markdown/repositories/local.md | 12 +-
content/markdown/repositories/metadata.md | 10 +-
content/markdown/repositories/remote.md | 18 +-
content/markdown/repository-management.md | 15 +-
content/markdown/repository/central-index.md | 17 +-
content/markdown/repository/central-metadata.md | 12 +
.../repository/guide-central-repository-upload.md | 67 ++++-
content/markdown/run-maven/index.md | 26 +-
content/markdown/run.md | 1 +
content/markdown/security-plexus-archiver.md | 30 +--
content/markdown/security.md | 30 +--
content/markdown/settings.md | 97 ++++----
content/markdown/shared/index.md | 52 ++--
content/markdown/skins/index.md | 31 ++-
content/markdown/support-and-training.md | 15 +-
content/markdown/testimonials.md | 1 +
content/markdown/users/getting-help.md | 40 ++-
content/markdown/users/index.md | 20 +-
content/markdown/what-is-maven.md | 25 +-
159 files changed, 5265 insertions(+), 1769 deletions(-)
diff --git a/content/markdown/aether.md b/content/markdown/aether.md
index d3da54c0..8b780131 100644
--- a/content/markdown/aether.md
+++ b/content/markdown/aether.md
@@ -32,7 +32,7 @@ and through [MNG-6007](https://issues.apache.org/jira/browse/MNG-6007).
|**central groupId**|[org.eclipse.aether](https://repo.maven.apache.org/maven2/org/eclipse/aether/)|[org.apache.maven.resolver](https://repo.maven.apache.org/maven2/org/apache/maven/resolver/)|
|**artifactIds**|aether<br/>aether-api<br/>aether-impl<br/>aether-spi<br/>aether-util<br/>aether-transport-\*|maven-resolver<br/>maven-resolver-api<br/>maven-resolver-impl<br/>maven-resolver-spi<br/>maven-resolver-util<br/>maven-resolver-transport-*|
|**OSGi Bundles**|org.eclipse.aether.api<br/>org.eclipse.aether.impl<br/>org.eclipse.aether....|no OSGi bundles in Apache Maven|
-|**P2 repo**|<http://download.eclipse.org/aether/aether-core/releases/<br/>http://download.eclipse.org/aether/maven-aether-provider/releases/|no> P2 repo|
+|**P2 repo**|http://download.eclipse.org/aether/aether-core/releases/<br/>http://download.eclipse.org/aether/maven-aether-provider/releases/|no P2 repo|
|**API java packages**|org.eclipse.aether...|**Keep packages in Maven 3.x to maintain compatibility for some plugins or extensions using Aether API.**|
|**Impl java packages**|org.eclipse.aether.impl.\*<br/>org.eclipse.aether.internal.\*|Same as API, even if nobody should rely on impl...|
|**SPI java packages**|org.eclipse.aether.spi.\*|Same as API (is it really used outside?)|
diff --git a/content/markdown/archives/maven-2.x/index.md b/content/markdown/archives/maven-2.x/index.md
index a636e5d9..ac2b0c27 100644
--- a/content/markdown/archives/maven-2.x/index.md
+++ b/content/markdown/archives/maven-2.x/index.md
@@ -31,6 +31,6 @@ under the License.
|**Plugin**|**Type***|**Version**|**Last Release Date**|**Description**|**Date of Funeral**|
|---|---|---|---|---|---|
|**Core plugins**||||**Plugins corresponding to default core phases (ie. clean, compile). They may have multiple goals as well.**||
-|[`reactor`](/plugins/maven-reactor-plugin/)|B|1.0|2008-09-27|Build a subset of interdependent projects in a reactor|2014-03-24|
+|[ `reactor`](/plugins/maven-reactor-plugin/)|B|1.0|2008-09-27|Build a subset of interdependent projects in a reactor|2014-03-24|
\* **B**uild or **R**eporting plugin
diff --git a/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md b/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md
index dd18a46f..7c73f05e 100644
--- a/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md
+++ b/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md
@@ -8,7 +8,7 @@ h1. Maven 2.1 -- Jason van Zyl
~~ "License"); you may not use this file except in compliance
~~ with the License. You may obtain a copy of the License at
~~
-~~ <http://www.apache.org/licenses/LICENSE-2.0>
+~~ http://www.apache.org/licenses/LICENSE-2.0
~~
~~ Unless required by applicable law or agreed to in writing,
~~ software distributed under the License is distributed on an
@@ -35,7 +35,7 @@ h2. Architectural Goals
h3. Backward Compatibility
-We must ensure that plugins and reports written against the Maven 2.0.x APIs remain to work in 2.1. We don't want people to have to rewrite
+We must ensure that plugins and reports written against the Maven 2.0.x APIs remain to work in 2.1. We don't want people to have to rewrite
their plugins. There are several plugins that are using the current artifact resolution code that will not be supported (please see the Mercury section below). The
ones that are in our control we can port over to use Mercury, and external users will have to deal with the major version change. Most people will not be affected and
Mercury will be a far better solution.
@@ -75,6 +75,7 @@ So the basic problem we're up against is that there can be core api changes betw
h3. Strategies for ensuring backward compatibility
+
* Plugin integration testing
{code}
@@ -99,7 +100,7 @@ jason: so when you and benjamin went through the tests you have "integration-tes
[08:07am] aheritier: it's too long
[08:07am] jason: a smoke test in one mode
[08:07am] jason: and then turn them all on in hudson
-[08:07am] aheritier: it's why we invented CI servers
+[08:07am] aheritier: it's why we invented CI servers
[08:07am] aheritier: yes
[08:07am] eu left the chat room. (Ping timeout)
[08:08am] jason: i will document the setup but you and ben should figure out the pattern you want for a given plugin test
@@ -140,7 +141,7 @@ jason: so when you and benjamin went through the tests you have "integration-tes
[08:15am] bentmann: Not sure what kind of consistency you actually require
[08:16am] bentmann: The IT profile should be named equal for all of them
[08:16am] bentmann: by inheriting from the parent
-[08:16am] i386_left the chat room. (i386_)
+[08:16am] i386_ left the chat room. (i386_)
[08:16am] bentmann: whether the are run by Invoker or Shitty shouldn't matter, I guess
[08:17am] jason: no, the actual project just needs a profile name the same. not taken from the parent but stated in the project itself
[08:17am] jason: though the parent could specify that profile which just echos "No ITs"
@@ -160,7 +161,7 @@ We just need some way to easy support multiple versions and support mediation be
* Tags: loose categorization people to use to help categorize as they see fit
* Categories: more standard categories that form over time by using category structures that exist or common tags that are used so often they become categories
* Dendency excludes: being to transitively exclude a dependency
-* Properties on dependencies
+* Properties on dependencies
* Specification Dependencies
* Schematron/RelaxNG descriptor for each plugin -- Bryon Jacob proposed a flexible model but XSD is hard to fight here so I'm not sure how far this will go
@@ -175,17 +176,17 @@ h3. Custom Components
As discussed in [Substituting of Custom Components|http://docs.codehaus.org/display/MAVEN/Substitution+of+Custom+Maven+Components] we now have two ways
to insert new components into the system.
-* Using a directory and specifying it in the Classworlds configuration. Tycho simply has a special set of components that load first before the standard maven components and they override
+* Using a directory and specifying it in the Classworlds configuration. Tycho simply has a special set of components that load first before the standard maven components and they override
the standard Maven components. Here's the example based on what Tycho is currently doing which allows custom components to be used.
{code}
-main is org.apache.maven.cli.MavenCli from plexus.core
-
-set maven.home default ${user.home}/m2
-
-[plexus.core]
-load ${maven.home}/tycho/*.jar
-load ${maven.home}/lib/*.jar
+main is org.apache.maven.cli.MavenCli from plexus.core
+
+set maven.home default ${user.home}/m2
+
+[plexus.core]
+load ${maven.home}/tycho/*.jar
+load ${maven.home}/lib/*.jar
{code}
* The embedder has the ContainerCustomizer which allow you to inject new component descriptors. This is used in the IDE integration (m2ecipse, Netbeans) for adding
@@ -203,7 +204,7 @@ Mercury is a replacement for the current Maven Artifact subsystem, and a complet
The primary reasons for replacing the code are that it is unmaintainable and nearly impossible to navigate, it uses completely non-standard structures and libraries for
version calculations, the API is too hard for people to use, and it is not given to users to consume as a single componment to use. Users are forced to know how several
complicated components interact in order to implement a mechanism of retrieving artifacts from a repository. The entire mechanism needs to be replaced with something
-that can be maintained and is reliable.
+that can be maintained and is reliable.
Mercury started as some fixes to Maven Artifact to first help with embeddability and error reporting for IDE integration. This was a direct result of all IDE integrators
having to reimplement the current artifact resolver to provide decent feedback to users when errors occured. The artifact subsystem would just die and leave the IDE in
@@ -213,21 +214,21 @@ behavior, Oleg and I decided to make a break from the old codebase and attempt t
* Find the best people in the world to help create an awesome HTTP and DAV implementation. We did this by talking to Greg, Jan, and Jesse who are the Jetty folks
and there just isn't anyone who knows HTTP better. Greg and Jan are awesome, and Jesse is Maven committer so we have some deep understanding of the issues involved. So
- what Oleg and I wanted to see was:
-**Easy SSL support where mucky with certificates in the default install is not required.
-** Connection pooling
-**Connection parallelization
+ what Oleg and I wanted to see was:
+** Easy SSL support where mucky with certificates in the default install is not required.
+** Connection pooling
+** Connection parallelization
** Built in DAV client support for deployment
-**Atomic retrieval: we make sure absolutely everything is been safely transported to disk before we place it in the local Maven repository
-** Atomic deployment: in this case we could only support this using a special filter Greg created which blocks requests for any artifacts being deploy in the current
- set until the entire set land safely to disk. So it becomes impossible to ask for an artifact that refers to something else in the set before it is actually available.
+** Atomic retrieval: we make sure absolutely everything is been safely transported to disk before we place it in the local Maven repository
+** Atomic deployment: in this case we could only support this using a special filter Greg created which blocks requests for any artifacts being deploy in the current
+ set until the entire set land safely to disk. So it becomes impossible to ask for an artifact that refers to something else in the set before it is actually available.
** Starting thinking about a client that can understand GeoIP. Given the recent spikes in traffic we are going to start needing to distribute the load.
* Find the best solution possible solution for dealing with version calculations, in particular ranges. For this we called on Daniel Le Berre and ask for some help in
integrating his SAT4J library. We learned about the SAT4J library from the P2 project over at Eclipse.org at the last EclipseCon. SAT4J was deemed the best way forward
- by the P2 team in providing the most reliable, and most workable solution for doing version calculation. SAT4J provides ways to plug-in strategies to deal with our
+ by the P2 team in providing the most reliable, and most workable solution for doing version calculation. SAT4J provides ways to plug-in strategies to deal with our
scopes, conflict resolution strategies and it is deadly fast. We felt we are in good company as we can call on Daniel and the P2 team and collaborate when difficult
- problems arise.
+ problems arise.
* Find the best people to help with with security. This might an SSL-based solution to secure the channel where the source is known to be safe, a PGP-based solution where
the contents must be secured assuming a hostile channel, or a combination of the two. To that end I have contacted the folks at the Legion of the Bouncy Castle and asked
@@ -235,24 +236,22 @@ behavior, Oleg and I decided to make a break from the old codebase and attempt t
So in the end I believe it would be detrimental to use the Maven Artifact code in the 2.1.x tree and the change needs to be made to use Mercury before the first alpha ships. Oleg
and I started this work, and Oleg has subsequently worked tirelessly on Mercury along with a great deal of help from Greg, Jan and Jesse. I think Oleg understands the requirements
-as he's seen Maven in action in one of the largest development environments in the world and watched how Maven can fail spectacularly.
+as he's seen Maven in action in one of the largest development environments in the world and watched how Maven can fail spectacularly.
h3. Plugin API
-
* Symmetric output expressions
* Java5 Mojo annotations (Yoav Landman has this working already)
* Clean separation of plugins from reports. It's not good that those are the same thing in the Maven internals.
** Not using concrete XML classes in the Plugin API (Xpp3Dom)
h3. Core Refactorings
-
* Project Builder ([architecture|http://docs.codehaus.org/display/MAVENUSER/Project+Builder])
-**Maven shared model work: a new way of reading in the models for Maven that is not format dependent in any way i.e. XML, text, YAML, scripts, whatever.
+** Maven shared model work: a new way of reading in the models for Maven that is not format dependent in any way i.e. XML, text, YAML, scripts, whatever.
** Pluggable model readers: this could leverage different implementations provided by the shared model work, but we still need a way to detect the type and version
of the model that we want to consume
-**A new terse format that uses attributes
+** A new terse format that uses attributes
** Automatic parent versioning
-**New interpolation component (plexus-interpolation)
+** New interpolation component (plexus-interpolation)
** Dynamic build sections ([MNG-3530|http://jira.codehaus.org/browse/MNG-3530])
** Mixin support -- allowing a paramterizable template which can be imported with one line.
@@ -264,12 +263,12 @@ h3. Core Refactorings
* Have one configuration model for session: session takes the request in the constructor and delegates
* Domain logging
* Plugin Manager
-**Removal of the Plugin Registry (done) -- we moved in a direction where people lock down their versions and we've helped by putting default versions
+** Removal of the Plugin Registry (done) -- we moved in a direction where people lock down their versions and we've helped by putting default versions
in the parent POM.
** Load Plugin dependencies into a separate ClassRealm (done)
** Plugin Execution Environment: Ability to run any version of a plugin where an environment is created which contains all the
requirements for a particular version of the Plugin API
-* Lifecycle Executor
+* Lifecycle Executor
** Queryable Lifecycle
*** The most important change in the embedding environment. You can actually query Maven for the complete execution before it happens. We must know the entire
model of execution before we execute.
@@ -277,17 +276,15 @@ h3. Core Refactorings
h3. Java 5
-Java5 annotations for plugins: we have two implementations that have now been merged in plexus-cdc. QDOX 1.7 has now been released so we may want to check the
+Java5 annotations for plugins: we have two implementations that have now been merged in plexus-cdc. QDOX 1.7 has now been released so we may want to check the
source level gleaning again. Jason Dillon has created a working class processing model. We need to deal with Plexus components and Maven plugins.
-
+
h3. Integration and promotion of scriptable plugins
-
+
h3. Toolchains
-
* Milos has implemented this and Shane had some feedback so this needs to be linked together
h3. Reporting
-
* Report Execution Environment: Ability to run any version of a report where an environment is created which contains all the requirements for a particular version of the Report API.
* Decouple the reporting core. We need to get Doxia out of the core. Anything it needs to run should be isolated.
@@ -318,7 +315,7 @@ or
This test will return false negative for some WAR projects (not added to classpath and don't have any sources to compile). Also, compileSourceRoots and testCompileSourceRoots only become fully populated after running maven build lifecycle, which is expensive.
* Extensions
-**Different categories of extensions: providers vs packaging vs PMD/Checkstyle resources stuff in a JAR
+** Different categories of extensions: providers vs packaging vs PMD/Checkstyle resources stuff in a JAR
** Transparent Extension Loading
-***Any Wagon or SCM providers should get picked up automatically from SCM and distributionManagement URLs
+*** Any Wagon or SCM providers should get picked up automatically from SCM and distributionManagement URLs
*** Any extensions containing packaging/lifecycle related bits needs to be picked up automatically
diff --git a/content/markdown/background/history-of-maven.md b/content/markdown/background/history-of-maven.md
index 015e9a49..b160b046 100644
--- a/content/markdown/background/history-of-maven.md
+++ b/content/markdown/background/history-of-maven.md
@@ -1,4 +1,4 @@
-# History of Maven
+# History of Maven
<!--
Licensed to the Apache Software Foundation (ASF) under one
@@ -107,4 +107,4 @@ was written by myself with lots of help from Bob McWhirter
[6]: http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/200202.mbox/%3c20020202153719.50163.qmail@icarus.apache.org%3e
[7]: http://turbine.apache.org/
[8]: http://www.oreillynet.com/pub/a/network/2005/08/30/ruby-rails-david-heinemeier-hansson.html
-[9]: http://www.ibiblio.org
+[9]: http://www.ibiblio.org
\ No newline at end of file
diff --git a/content/markdown/background/philosophy-of-maven.md b/content/markdown/background/philosophy-of-maven.md
index 1c2d7437..919a33f0 100644
--- a/content/markdown/background/philosophy-of-maven.md
+++ b/content/markdown/background/philosophy-of-maven.md
@@ -1,4 +1,4 @@
-# Philosophy of Maven
+# Philosophy of Maven
<!--
Licensed to the Apache Software Foundation (ASF) under one
diff --git a/content/markdown/code-quality-management.md b/content/markdown/code-quality-management.md
index 2b45082e..76fd15ac 100644
--- a/content/markdown/code-quality-management.md
+++ b/content/markdown/code-quality-management.md
@@ -27,11 +27,11 @@ this information to offer enhanced quality management functionalities.
Following is an alphabetical list of those we've heard mentioned around
the Maven community:
-- [Hudson](https://hudson-ci.org)
-- [Jenkins](https://jenkins-ci.org)
-- [SonarQube](http://www.sonarqube.org/)
-- [Squale](http://www.squale.org/)
-- [XRadar](http://xradar.sourceforge.net)
+- [Hudson](https://hudson-ci.org)
+- [Jenkins](https://jenkins-ci.org)
+- [SonarQube](http://www.sonarqube.org/)
+- [Squale](http://www.squale.org/)
+- [XRadar](http://xradar.sourceforge.net)
[PMD]: https://maven.apache.org/plugins/maven-pmd-plugin/
[Checkstyle]: https://maven.apache.org/plugins/maven-checkstyle-plugin/
diff --git a/content/markdown/configure.md b/content/markdown/configure.md
index 7eb897fe..aaf782b9 100644
--- a/content/markdown/configure.md
+++ b/content/markdown/configure.md
@@ -17,39 +17,39 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
-The configuration for Apache Maven usage itself and projects built with resides
-in a number of places:
+The configuration for Apache Maven usage itself and projects built with resides
+in a number of places:
-## `MAVEN_OPTS` environment variable
+## `MAVEN_OPTS` environment variable:
This variable contains parameters used to start up the JVM running Maven and
can be used to supply additional options to it. E.g. JVM memory
settings could be defined with the value `-Xms256m -Xmx512m`.
-## `MAVEN_ARGS` environment variable
+## `MAVEN_ARGS` environment variable:
Starting with Maven 3.9.0, this variable contains arguments passed to Maven before
CLI arguments. E.g., options and goals could be defined with the value
`-B -V checkstyle:checkstyle`.
-## `settings.xml` file
+## `settings.xml` file:
Located in USER_HOME/.m2 the settings files is designed to contain any
configuration for Maven usage across projects.
-## `.mvn` directory
+## `.mvn` directory:
Located within the project's top level directory, the files `maven.config`, `jvm.config`, and `extensions.xml`
contain project specific configuration for running Maven.
This directory is part of the project and may be checked in into your version control.
-### `.mvn/extensions.xml` file
+### `.mvn/extensions.xml` file:
-The old way (up to Maven 3.2.5) was to create a jar (must be shaded if you have other dependencies) which contains the extension and put
+The old way (up to Maven 3.2.5) was to create a jar (must be shaded if you have other dependencies) which contains the extension and put
it manually into the `${MAVEN_HOME}/lib/ext` directory. This means you had to change the Maven installation. The consequence was that everyone
-who likes to use this needed to change it’s installation and makes the on-boarding for a developer much more inconvenient. The other
-option was to give the path to the jar on command line via `mvn -Dmaven.ext.class.path=extension.jar`. This has the drawback giving those
+who likes to use this needed to change it’s installation and makes the on-boarding for a developer much more inconvenient. The other
+option was to give the path to the jar on command line via `mvn -Dmaven.ext.class.path=extension.jar`. This has the drawback giving those
options to your Maven build every time you are calling Maven. Not very convenient as well.
From now on this can be done much more simpler and in a more Maven like way. So you can define an `${maven.projectBasedir}/.mvn/extensions.xml` file which looks like the following:
@@ -67,15 +67,15 @@ From now on this can be done much more simpler and in a more Maven like way. So
Now you can simply use an extension by defining the usual maven coordinates groupId, artifactId, version as any other artifact. Furthermore all transitive dependencies of those extensions will automatically being downloaded from your repository. So no need to create a shaded artifact anymore.
-### `.mvn/maven.config` file
+### `.mvn/maven.config` file:
-It’s really hard to define a general set of options for calling the maven command line. Starting with Maven 3.3.1+, this can be solved by
-putting this
-options to a script but this can now simple being done by defining `${maven.projectBasedir}/.mvn/maven.config` file which contains the
-configuration options for the `mvn` command line.
+It’s really hard to define a general set of options for calling the maven command line. Starting with Maven 3.3.1+, this can be solved by
+putting this
+options to a script but this can now simple being done by defining `${maven.projectBasedir}/.mvn/maven.config` file which contains the
+configuration options for the `mvn` command line.
-For example things like `-T3 -U --fail-at-end`. So you only have to call Maven just by using `mvn
-clean package` instead of `mvn -T3 -U --fail-at-end clean package` and not to miss the `-T3 -U --fail-at-end` options on every call.
+For example things like `-T3 -U --fail-at-end`. So you only have to call Maven just by using `mvn
+clean package` instead of `mvn -T3 -U --fail-at-end clean package` and not to miss the `-T3 -U --fail-at-end` options on every call.
The `${maven.projectBasedir}/.mvn/maven.config` is located in the `${maven.projectBasedir}/.mvn/` directory; also works if in the root of a multi module build.
**NOTICE** starting with Maven **3.9.0** each single argument must be put in new line, so for the mentioned example your file will have content like:
@@ -86,7 +86,7 @@ The `${maven.projectBasedir}/.mvn/maven.config` is located in the `${maven.proje
--fail-at-end
```
-### `.mvn/jvm.config` file
+### `.mvn/jvm.config` file:
Starting with Maven 3.3.1+ you can define JVM configuration via `${maven.projectBasedir}/.mvn/jvm.config` file which means you can define the options for your build on a per project base. This file will become part of your project and will be checked in along with your project. So no need anymore for `MAVEN_OPTS`, `.mavenrc` files. So for example if you put the following JVM options into the `${maven.projectBasedir}/.mvn/jvm.config` file
diff --git a/content/markdown/developers/committer-environment.md b/content/markdown/developers/committer-environment.md
index 52719085..b933c92b 100644
--- a/content/markdown/developers/committer-environment.md
+++ b/content/markdown/developers/committer-environment.md
@@ -23,22 +23,38 @@ under the License.
## Committer Environment
+
### Introduction
+
This document describes how to set up the Maven committer environment.
+
+
### Source File Encoding
+
When editing source files, make sure you use the right file encoding. For the Maven project, UTF-8 has been chosen as the default file encoding. UTF-8 is an encoding scheme for the Unicode character set that can encode all characters that Java can handle. The source files should not contain the byte order mark (BOM). There are exceptions to this general rule. For instance, properties files are encoded using ISO-8859-1 as per the JRE API, so please keep this in mind, too.
+
+
### Maven Code Style
+
Refer to [Maven Code Style And Code Conventions](./conventions/code.html)
+
+
### Useful software
+
The Maven Team uses assorted software. Here is a partial list:
-- [Cygwin](https://www.cygwin.com/): collection of free software tools that allow various versions of Microsoft Windows to act somewhat like a Unix system
-- [GnuPG](https://www.gnupg.org/): GNU Privacy Guard.
+
+ - [Cygwin](https://www.cygwin.com/): collection of free software tools that allow various versions of Microsoft Windows to act somewhat like a Unix system
+
+ - [GnuPG](https://www.gnupg.org/): GNU Privacy Guard.
+
+
+
diff --git a/content/markdown/developers/committer-settings.md b/content/markdown/developers/committer-settings.md
index 54d00842..d979a678 100644
--- a/content/markdown/developers/committer-settings.md
+++ b/content/markdown/developers/committer-settings.md
@@ -23,13 +23,19 @@ under the License.
## Introduction
+
This document is intended to set up the Maven committer settings, i.e. the `${user.home}/.m2/settings.xml`.
+
### Enable Apache Servers
+
Maven uses several servers configuration to deploy snapshots and releases on the Apache servers. You need to tell to Maven what your Apache username is.
- **It is highly recommended to use Maven's [password encryption capabilities](../guides/mini/guide-encryption.html) for your passwords**.
+
+ **It is highly recommended to use Maven's [ password encryption capabilities](../guides/mini/guide-encryption.html) for your passwords**.
+
+
```
<settings>
@@ -52,10 +58,14 @@ under the License.
</settings>
```
+
### Enable sending announcement e-mails
+
To be able to send out announcements of Maven releases you need to add a couple of properties to the `apache-release` profile.
+
+
```
<settings>
...
@@ -71,3 +81,5 @@ under the License.
</profiles>
</settings>
```
+
+
diff --git a/content/markdown/developers/compatibility-plan.md b/content/markdown/developers/compatibility-plan.md
index e8220330..37d42df5 100644
--- a/content/markdown/developers/compatibility-plan.md
+++ b/content/markdown/developers/compatibility-plan.md
@@ -23,42 +23,62 @@ under the License.
## Maven Plugins Compatibility Plan
+
### Scope
+
This page describes the system requirements plan, which consists of:
+
+
1 minimum **Java** runtime prerequisite for Maven plugins, which can be extended to shared components,
1 minimum **Maven** runtime prerequisite for plugins.
+
Such requirements are displayed as "System Requirements" in every plugin info report (see [this example](/plugins/maven-clean-plugin/plugin-info.html)).
+
Consolidated view for all LATEST plugins release is visible in a [daily generated report](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html).
+
+
### Maven Plan
-- Until 2012, Maven 2.2.1 + Java 5 prerequisites, with plugins versions in 2.x
-- Since 2012, Maven 3.0 + Java 7 prerequisites, with plugins in 3.x.y
-- Since June 2020, Maven Plugin API used by plugins >= 3.1.0 + Java 8 prerequisites [Technical details](https://s.apache.org/MVN-PLUGIN-MIGRATION-3.1)
+ - Until 2012, Maven 2.2.1 + Java 5 prerequisites, with plugins versions in 2.x
+
+ - Since 2012, Maven 3.0 + Java 7 prerequisites, with plugins in 3.x.y
+
+ - Since June 2020, Maven Plugin API used by plugins >= 3.1.0 + Java 8 prerequisites [Technical details](https://s.apache.org/MVN-PLUGIN-MIGRATION-3.1)
+
+
### Context
-- Maven core history with Java prerequisite is available in the [release notes](/docs/history.html)
-- JDK/JRE availability dates:
-- Java 5 (2004) is closed source, End of Public Update in 2009
+ - Maven core history with Java prerequisite is available in the [release notes](/docs/history.html)
+
+ - JDK/JRE availability dates:
+
+ - Java 5 (2004) is closed source, End of Public Update in 2009
+
+ - Java 6 (2006) is Open Source, maintained at OpenJDK until 2018
-- Java 6 (2006) is Open Source, maintained at OpenJDK until 2018
+ - Java 7 (2011) is Open Source, maintained [at OpenJDK](https://wiki.openjdk.java.net/display/jdk7u) at least until June 2020
-- Java 7 (2011) is Open Source, maintained [at OpenJDK](https://wiki.openjdk.java.net/display/jdk7u) at least until June 2020
+ - Java 8 (2014) is Open Source, maintained [at OpenJDK](https://wiki.openjdk.java.net/display/jdk8u) at least until September 2023
-- Java 8 (2014) is Open Source, maintained [at OpenJDK](https://wiki.openjdk.java.net/display/jdk8u) at least until September 2023
+ - Java 11 (LTS, 2018) is Open Source, maintained [at OpenJDK](https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u) at least until September 2025
-- Java 11 (LTS, 2018) is Open Source, maintained [at OpenJDK](https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u) at least until September 2025
+ - see [Java Version Almanac](https://javaalmanac.io/jdk/) for updated JDK releases
-- see [Java Version Almanac](https://javaalmanac.io/jdk/) for updated JDK releases
see also [Java Is Still Free](https://docs.google.com/document/d/1nFGazvrCvHMZJgFstlbzoHjpAVwv5DEdnaBr_5pKuHo) for more details
+
+
+
+
+
diff --git a/content/markdown/developers/conventions/code.md b/content/markdown/developers/conventions/code.md
index 3f96f8a9..b67457fd 100644
--- a/content/markdown/developers/conventions/code.md
+++ b/content/markdown/developers/conventions/code.md
@@ -26,99 +26,139 @@ under the License.
As the formatting is automatically enforced or even applied with [spotless-maven-plugin](https://github.com/diffplug/spotless/tree/main/plugin-maven) for all projects using [Maven Project Parent POM 38 or newer](/pom/maven/index.html) developers usually don't need to care and the following sections are just for informational purposes.
+
Optionally you can still import the code style formatter for your IDE from [shared-resources](https://gitbox.apache.org/repos/asf?p=maven-shared-resources.git;a=tree;f=src/main/resources/config;hb=HEAD)
-- [Generic Code Style And Convention](#generic-code-style-and-convention)
-- [Java](#java)
+ - [Generic Code Style And Convention](#generic-code-style-and-convention)
+
+ - [Java](#java)
+
+ - [Java Code Style](#java-code-style)
+
+ - [Java Code Convention](#java-code-convention)
+
+ - [Java Code Convention - import layouts](#java-code-convention---import-layouts)
-- [Java Code Style](#java-code-style)
+ - [JavaDoc Convention](#javadoc-convention)
-- [Java Code Convention](#java-code-convention)
-- [Java Code Convention - import layouts](#java-code-convention---import-layouts)
-- [JavaDoc Convention](#javadoc-convention)
+ - [XML](#xml)
-- [XML](#xml)
+ - [XML Code Style](#xml-code-style)
-- [XML Code Style](#xml-code-style)
+ - [Generic XML Code Convention](#generic-xml-code-convention)
-- [Generic XML Code Convention](#generic-xml-code-convention)
+ - [POM Code Convention](#pom-code-convention)
+
+ - [XDOC Code Convention](#xdoc-code-convention)
+
+ - [FML Code Convention](#fml-code-convention)
-- [POM Code Convention](#pom-code-convention)
-- [XDOC Code Convention](#xdoc-code-convention)
-- [FML Code Convention](#fml-code-convention)
### Generic Code Style And Convention
+
All working files (java, xml, others) should respect the following conventions:
-- **License Header**: Always add the current [ASF license header](https://www.apache.org/legal/src-headers.html#headers) in all files checked into the source code repository.
-- **Trailing Whitespace**: No trailing whitespaces allowed.
+
+ - **License Header**: Always add the current [ASF license header](https://www.apache.org/legal/src-headers.html#headers) in all files checked into the source code repository.
+
+ - **Trailing Whitespace**: No trailing whitespaces allowed.
+
and the following style:
-- **Indentation**: **Never** use tabs!
-- **Line wrapping**: Always use a 120-column line width.
+
+ - **Indentation**: **Never** use tabs!
+
+ - **Line wrapping**: Always use a 120-column line width.
+
**Note**: The specific styles and conventions, listed in the next sections, can override these generic rules.
+
+
### Java
+
#### Java Code Style
+
Maven adopts the [palantir Java format](https://github.com/palantir/palantir-java-format).
+
+
#### Java Code Convention
+
For consistency reasons, our Java code convention is mainly:
-- **Naming**: Constants (i.e. static final members) should always be in upper case. Use short, descriptive names for classes and methods.
-- **Organization**: Avoid using public inner classes. Prefer interfaces instead of default implementation.
-- **Modifier**: Avoid using final modifier on all fields and arguments. Prefer using private or protected fields instead of public fields.
+ - **Naming**: Constants (i.e. static final members) should always be in upper case. Use short, descriptive names for classes and methods.
+
+ - **Organization**: Avoid using public inner classes. Prefer interfaces instead of default implementation.
+
+ - **Modifier**: Avoid using final modifier on all fields and arguments. Prefer using private or protected fields instead of public fields.
-- **Exceptions**: Throw meaningful exceptions to make debugging and testing easier.
+ - **Exceptions**: Throw meaningful exceptions to make debugging and testing easier.
+
+ - **Documentation**: Document public interfaces well, i.e. all non-trivial public and protected functions should include Javadoc that indicates what they do.
+
+ - **Testing**: All non-trivial public classes should have corresponding unit or integration tests.
-- **Documentation**: Document public interfaces well, i.e. all non-trivial public and protected functions should include Javadoc that indicates what they do.
-- **Testing**: All non-trivial public classes should have corresponding unit or integration tests.
#### Java Code Convention - import layouts
+
For consistency reasons, Java imports should be organized as:
-- import **javax.\***
-- import **java.\***
-- blank line
+ - import **javax.\***
+
+ - import **java.\***
+
+ - blank line
+
+ - import **all other imports**
-- import **all other imports**
all imports in each group should be sorted alphabetically.
+
To ensure a package import order consistent with the layout described above, download `[maven-eclipse-importorder.txt](https://gitbox.apache.org/repos/asf?p=maven-shared-resources.git;a=blob_plain;f=src/main/resources/config/maven-eclipse-importorder.txt;hb=HEAD)`, select _Window \> Preferences_ and navigate to _Java \> Code Style \> Organize Imports_. Click on _Import..._ and select the downloaded file to change the import order.
+
+
#### JavaDoc Convention
+
TO BE DISCUSSED
+
+
+
### XML
+
#### XML Code Style
+
The Maven style for XML files is mainly:
-- **Indentation**: Always use 2 space indents, unless you're wrapping a new XML tags line in which case you should indent 4 spaces.
-- **Line Breaks**: Always use a new line with indentation for complex XML types and no line break for simple XML types. Always use a new line to separate XML sections or blocks, for instance:
+
+ - **Indentation**: Always use 2 space indents, unless you're wrapping a new XML tags line in which case you should indent 4 spaces.
+
+ - **Line Breaks**: Always use a new line with indentation for complex XML types and no line break for simple XML types. Always use a new line to separate XML sections or blocks, for instance:
```
<aTag>
@@ -130,30 +170,46 @@ under the License.
</aTag>
```
+
In some cases, adding comments could improve the readability of blocks, for instance:
+
+
```
<!-- Simple XML documentation -->
```
+
or
+
+
```
<!-- ====================================================================== -->
<!-- Block documentation -->
<!-- ====================================================================== -->
```
+
+
+
#### Generic XML Code Convention
+
No generic code convention exists yet for XML files.
+
+
#### POM Code Convention
+
The team has [voted](https://lists.apache.org/thread/h8px5t6f3q59cnkzpj1t02wsoynr3ygk) during the end of June 2008 to follow a specific POM convention to ordering POM elements. The consequence of this vote is that the [Maven project descriptor](https://maven.apache.org/ref/current/maven-model/maven.html) is **no more** considered as the reference for the ordering.
+
The following is the recommended ordering for all Maven POM files:
+
+
```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion/>
@@ -204,24 +260,39 @@ under the License.
**Comments**:
+
+
1 The `<project>` element is always on one line.
1 The blocks are voluntary separated by a new line to improve the readiness.
1 The dependencies in `<dependencies>` and `<dependencyManagement>` tags have no specific ordering. Developers are free to choose the ordering, but grouping dependencies by topics (like groupId i.e. `org.apache.maven`) is a good practice.
+
+
#### XDOC Code Convention
+
For consistency and readability reasons, XDOC files should respect:
-- **Metadata**: Always specify metadata in the `<properties>` tag.
-- **Sections**: Always use a new line with indentation for `<section>` tags.
+
+ - **Metadata**: Always specify metadata in the `<properties>` tag.
+
+ - **Sections**: Always use a new line with indentation for `<section>` tags.
+
+
#### FML Code Convention
+
For readability reasons, FML files should respect:
-- **FAQ**: Always use a new line with indentation for `<faq>` tags.
+
+
+ - **FAQ**: Always use a new line with indentation for `<faq>` tags.
+
<!-- * {APT} Do we need any specific APT style/convention? -->
+
+
diff --git a/content/markdown/developers/conventions/git.md b/content/markdown/developers/conventions/git.md
index ef568786..de40447b 100644
--- a/content/markdown/developers/conventions/git.md
+++ b/content/markdown/developers/conventions/git.md
@@ -23,16 +23,23 @@ under the License.
## Maven Git Convention
- This document describes how developers should use Git.
+
+ This document describes how developers should use Git.
+
### Git Configuration
+
#### For contributors who are not committers
+
Apache git repositories are at _git://git.apache.org_. However, the ASF uses clones on github.com to make it easier for people to contribute changes via pull requests.
+
To contribute to a Maven component that is maintained in git, please follow these steps:
+
+
1 create a JIRA for bug or improvement that you wish to work on. The Maven project uses JIRA to organize and track our work, and in particular to keep track of which changes are included in which releases.
1 Make a fork of the official ASF clone from github.com. For example, `https://github.com/apache/maven-scm`.
@@ -43,16 +50,24 @@ under the License.
1 Make a pull request to pull your changes to the official clone. Add a link to your pull request to the JIRA. Committers will take it from here.
+
+
#### For committers
+
Committers may, of course, commit directly to the ASF repositories. For complex changes, you may find it valuable to make a pull request at github to make it easier to collaborate with others.
+
##### Commit Message Template
+
Commits should be focused on one issue at a time, because that makes it easier for others to review the commit.
+
A commit message should use this template:
+
+
```
[ISSUE-1] <<Summary field from JIRA>>
Submitted by: <<Name of non-committer>>
@@ -62,14 +77,19 @@ o Comments
Where:
-- **ISSUE-1** can be omitted if there was no relevant JIRA issue, though you are strongly encouraged to create one for significant changes.
-- **Submitted by** only needs to be specified when a patch is being applied for a non-committer.
-- **Comments** some optional words about the solution.
+ - **ISSUE-1** can be omitted if there was no relevant JIRA issue, though you are strongly encouraged to create one for significant changes.
+
+ - **Submitted by** only needs to be specified when a patch is being applied for a non-committer.
+
+ - **Comments** some optional words about the solution.
+
eg:
+
+
```
[MNG-1456] Added the foo to the bar
Submitted by: Baz Bazman
@@ -77,30 +97,46 @@ Submitted by: Baz Bazman
o Applied without change
```
+
+
+
### Apply User Patch
+
To keep the history of contributions clear, The committer should usually apply the patch without any **major** modifications, and then create his or her own commits for further modifications. However, committers should never commit code to a live branch which is not suitable to release. If a contribution requires significant work to make it useful, commit it to a branch, fix it up, and merge the branch.
+
If the user created a pull request, the committer is responsible for closing that pull request. You do this by adding a note to a commit message:
+
+
```
Closes #NNN.
```
where NNN is the number of the pull request.
+
+
### Edit Commit Message
+
to edit last commit comment:
+
+
```
-git commit --amend -m "new comment"
+$ git commit --amend -m "new comment"
```
+
### Workflow
+
Workflow for svn folks is something like :
+
+
```
$ git pull
$ hack hack hack
@@ -113,6 +149,8 @@ git commit --amend -m "new comment"
A more quiet workflow :
+
+
```
$ git pull
$ hack hack hack
@@ -125,24 +163,34 @@ $ git rebase origin/master
$ git push
```
+
### Other useful Git commands while developing
+
If you've done a chunk of work and you would like to ditch your changes and start from scratch use this command to revert to the original checkout:
+
+
```
-git checkout .
+$ git checkout .
```
TODO .gitignore
+
#### power-git checkout
+
This checkout is typical for highly experienced git users, and may serve as inspiration for others; as usual the best way to learn is by doing. Sample shown for maven-surefire
- Go to <https://github.com/apache/maven-surefire> and fork surefire to your own github account.
+
+ Go to https://github.com/apache/maven-surefire and fork surefire to your own github account.
+
Starting with nothing (no existing clone)
+
+
```
git clone https://github.com/<youraccount>/maven-surefire.git
git remote add apache https://git-wip-us.apache.org/repos/asf/maven-surefire.git
@@ -153,18 +201,25 @@ git fetch --all
(You may consider adding --global to the git config statement above to always fetch pull requests for any remote named "asfgithub")
+
In this setup, running "git push" will normally push to your personal github account. Furthermore, all pull requests from github are also fetched to your local clone, use
+
+
```
gitk --all
```
to try to make some sense of it all. This is an important command to understand! (gitk may need to be installed additionally)
+
gitk also has a quite excellent context menu that is far more context sensitive than most people realize at first impression. Right-clicking on a commit in a github pull-request will allow you to cherry-pick straight in the gui.
+
If you're working on the master branch, you can do stuff like this:
+
+
```
git push # your github account
git push apache # the authoritative apache repo
@@ -172,8 +227,11 @@ git push apache # the authoritative apache repo
Using your github account as a storage for half-finished work is excellent if you switch between multiple computers, always push to github before leaving your current computer and start by pulling at the next computer.
+
To merge a pull request
+
+
```
git merge pr/10 # merge pull request number 10 from asf@github into master
git push apache # upload to apache
@@ -181,9 +239,14 @@ git push apache # upload to apache
Or if you're comfortable with rebasing;
+
+
```
git checkout pr/10
git rebase apache/master
git push apache
```
+
+
+
diff --git a/content/markdown/developers/conventions/jira.md b/content/markdown/developers/conventions/jira.md
index 8b1b9b9b..30f7ea1d 100644
--- a/content/markdown/developers/conventions/jira.md
+++ b/content/markdown/developers/conventions/jira.md
@@ -73,4 +73,4 @@ The Maven team doesn't use this. Committers can if it helps them.
- [JIRA Documentation](https://confluence.atlassian.com/jira064/jira-documentation-720411693.html)
- [What is an Issue?](https://confluence.atlassian.com/jira064/what-is-an-issue-720416138.html)
-- [What is a project?](https://confluence.atlassian.com/jira064/what-is-a-project-720416135.html)
+- [What is a project?](https://confluence.atlassian.com/jira064/what-is-a-project-720416135.html)
\ No newline at end of file
diff --git a/content/markdown/developers/dependency-policies.md b/content/markdown/developers/dependency-policies.md
index 7625546d..064a45ff 100644
--- a/content/markdown/developers/dependency-policies.md
+++ b/content/markdown/developers/dependency-policies.md
@@ -23,36 +23,60 @@ under the License.
## Maven Dependency Policies
+
### Scope
+
This page describes the policies around the use of dependencies by the Apache Maven Developers in the process of developing Apache Maven itself.
+
This page does not apply to projects hosted outside of the Apache Maven project. In order to remove all doubt, this page only applies to code which has a Github URL that starts with `https://github.com/apache/maven` or a Gitbox URL starting with `https://gitbox.apache.org/repos/asf?p=maven`
+
If you have stumbled across this page and you are working on code that does not have a Github URL starting with `https://github.com/apache/maven` then this page does not apply to you.
+
+
### Background
+
The Apache Maven PMC is tasked with ensuring (among other things) that all legal issues are addressed and that each and every release is the product of the community as a whole.
+
The Apache Maven project consists of quite a number of components. For the purposes of this policy, we will make a distinction between the core Maven distribution and all the other components.
- The core Maven distribution is the binary and source distributions made available from the <https://maven.apache.org/download> page.
+
+ The core Maven distribution is the binary and source distributions made available from the https://maven.apache.org/download page.
+
+
### Applicability
+
This policy applies to all changes to dependencies as and from Subversion revision 1067464.
+
+
### Core Maven Distribution Dependencies
+
All dependencies which are included in the Core Maven Distribution must either:
-- be licensed under a [Category A license](https://www.apache.org/legal/resolved.html#category-a); or
-- be licensed under a [Category B license](https://www.apache.org/legal/resolved.html#category-b) and approved by a majority vote of the Apache Maven PMC.
+
+ - be licensed under a [Category A license](https://www.apache.org/legal/resolved.html#category-a); or
+
+ - be licensed under a [Category B license](https://www.apache.org/legal/resolved.html#category-b) and approved by a majority vote of the Apache Maven PMC.
+
Votes for Category B licenses will be held on the dev@maven.apache.org mailing list. A majority of the PMC must vote in favour of a Category B licensed dependency before a release can be made containing that dependency.
+
+
### Non-Core Dependencies
+
Non-Core components may only use Category A or Category B licenses.
+
+
+
diff --git a/content/markdown/developers/index.md b/content/markdown/developers/index.md
index cb7ac499..32526fe3 100644
--- a/content/markdown/developers/index.md
+++ b/content/markdown/developers/index.md
@@ -23,72 +23,103 @@ under the License.
## Maven Developer Centre
+
This documentation centre is for people who are Maven developers, or would like to contribute.
+
If you cannot find your answers here, feel free to ask the [Maven Developer List](mailto:dev@maven.apache.org).
+
### Contributors Resources
-- [Guide to helping with Maven](../guides/development/guide-helping.html)
-- [Developing Maven](../guides/development/guide-maven-development.html)
-- [Building Maven](../guides/development/guide-building-maven.html)
+ - [Guide to helping with Maven](../guides/development/guide-helping.html)
+
+ - [Developing Maven](../guides/development/guide-maven-development.html)
-- [Source Code](../scm.html)
+ - [Building Maven](../guides/development/guide-building-maven.html)
-- [Continuous Integration](https://ci-maven.apache.org/job/Maven/job/maven-box/)
+ - [Source Code](../scm.html)
+
+ - [Continuous Integration](https://ci-maven.apache.org/job/Maven/job/maven-box/)
+
+ - [Common Bugs and Pitfalls](../plugin-developers/common-bugs.html)
+
+ - [Apache Maven Project Roles](../project-roles.html)
-- [Common Bugs and Pitfalls](../plugin-developers/common-bugs.html)
-- [Apache Maven Project Roles](../project-roles.html)
### Committers Resources
+
#### General Resources
-- [Guide for new Maven committers](./welcome-to-new-committers.html)
-- [Committer Environment](./committer-environment.html)
-- [Committer Settings](./committer-settings.html)
+ - [Guide for new Maven committers](./welcome-to-new-committers.html)
-- [Retirement Plan for Plugins](./retirement-plan-plugins.html)
+ - [Committer Environment](./committer-environment.html)
+
+ - [Committer Settings](./committer-settings.html)
+
+ - [Retirement Plan for Plugins](./retirement-plan-plugins.html)
+
+ - [Maven Dependency Policies](./dependency-policies.html)
+
+ - [Maven Plugins and Components Compatibility Plan](./compatibility-plan.html)
+
+ - [Maven Proposals/Backlog](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567)
-- [Maven Dependency Policies](./dependency-policies.html)
-- [Maven Plugins and Components Compatibility Plan](./compatibility-plan.html)
-- [Maven Proposals/Backlog](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567)
### Developers Conventions
+
There are a number of conventions used in the Maven projects, which contributors and developers alike should follow for consistency's sake.
-- [Maven Code Style And Conventions](./conventions/code.html)
-- [Maven JIRA Convention](./conventions/jira.html)
-- [Maven Git Convention](./conventions/git.html)
+ - [Maven Code Style And Conventions](./conventions/code.html)
+
+ - [Maven JIRA Convention](./conventions/jira.html)
+
+ - [Maven Git Convention](./conventions/git.html)
+
**Note**: If you cannot find your answers here, feel free to ask the [Maven Developer List](mailto:dev@maven.apache.org).
+
+
### Making Releases
-- [Making GPG Keys](./release/pmc-gpg-keys.html)
-- [Release Process](./release/index.html)
+
+ - [Making GPG Keys](./release/pmc-gpg-keys.html)
+
+ - [Release Process](./release/index.html)
+
+
### Maven Website
-- [Deploy Maven Website](./website/index.html)
+
+
+ - [Deploy Maven Website](./website/index.html)
+
+
### Other Resources
-- [ASF Development Infrastructure Information](https://www.apache.org/dev/)
-- [About the Apache Software Foundation](https://www.apache.org/foundation/)
+
+ - [ASF Development Infrastructure Information](https://www.apache.org/dev/)
+
+ - [About the Apache Software Foundation](https://www.apache.org/foundation/)
+
<!-- TODO: tasks as buttons? -->
<!-- TODO: de-dupe with existing documents in community -->
<!-- TODO: clean up, have cookbook with more in depth documents like cutting releases, etc. -->
+
diff --git a/content/markdown/developers/release/index.md b/content/markdown/developers/release/index.md
index c001ef96..083735d3 100644
--- a/content/markdown/developers/release/index.md
+++ b/content/markdown/developers/release/index.md
@@ -23,17 +23,25 @@ under the License.
## Releasing A Maven Project
+
What follows is a description of releasing a Maven project to a staging repository and its documentation, whereupon it is scrutinized by the community, approved, and transferred to a production repository.
+
The steps involved are similar for any Apache project, with more specifics for parent POMs and Maven itself. The steps involved, and the relevant documents for each, are listed below.
+
<!-- nothing specific: normal component * {{{./maven-plugin-release.html} Releasing a Maven plugin project}} -->
<!-- nothing specific: normal component * {{{./maven-shared-release.html} Releasing a Maven shared component or subproject}} -->
-- [Releasing Maven Core](./maven-core-release.html)
+ - [ Releasing Maven Core](./maven-core-release.html)
+
+ - [ Releasing a parent POM](./parent-pom-release.html)
-- [Releasing a parent POM](./parent-pom-release.html)
The above links all provide specific information for those types of releases, but they all refer back to the common documentation:
-- [Maven Project Common Release procedure](./maven-project-release-procedure.html)
+
+
+ - [ Maven Project Common Release procedure](./maven-project-release-procedure.html)
+
+
diff --git a/content/markdown/developers/release/maven-core-release.md b/content/markdown/developers/release/maven-core-release.md
index 4e3fedaa..70b772bd 100644
--- a/content/markdown/developers/release/maven-core-release.md
+++ b/content/markdown/developers/release/maven-core-release.md
@@ -51,13 +51,13 @@ with 3.2.5.
For non-alpha/beta releases, release candidates are produced before the actual release.
-Checkout <https://dist.apache.org/repos/dist/dev/maven/maven-3> then create the necessary directory tree.
+Checkout https://dist.apache.org/repos/dist/dev/maven/maven-3 then create the necessary directory tree.
Copy the binaries and src-tar.gz with their sha512/asc to the created directories.
To produce a release candidate, follow the first seven steps only from the following procedure:
-- [Maven Project Common Release Procedure](./maven-project-release-procedure.html)
+- [Maven Project Common Release Procedure](./maven-project-release-procedure.html)
The version used should be the eventual version with -RC1, -RC2, etc. appended.
@@ -71,7 +71,7 @@ Once happy with a release candidate, the full release is performed, with the fin
To produce a final release, the same process as for standard projects is followed:
-- [Maven Project Common Release Procedure](./maven-project-release-procedure.html)
+- [Maven Project Common Release Procedure](./maven-project-release-procedure.html)
Below describes the additional steps that need to be taken at the points where the website are updated in those instructions.
@@ -151,3 +151,4 @@ Next, any superseded releases should be removed from the above locations (after
#### Proceed with Announcement
You can now proceed with the steps outlined after deploying the website on [Maven Project Common Release Procedure](./maven-project-release-procedure.html)
+
diff --git a/content/markdown/developers/release/maven-project-release-procedure.md b/content/markdown/developers/release/maven-project-release-procedure.md
index 91df9d3c..8709bbc2 100644
--- a/content/markdown/developers/release/maven-project-release-procedure.md
+++ b/content/markdown/developers/release/maven-project-release-procedure.md
@@ -22,52 +22,78 @@ under the License.
-->
## Performing a Maven Project Release
+
This document covers the common release procedures used by the Maven team to perform releases.
+
### Prerequisites
+
Be sure that:
-- you have a recent Git client installed and on your shell's path.
-- you have JDK 8 installed and on your shell's path to build Maven 3.7.0+. Details about minimum JDK version to build an appropriate version can be found here: [https://maven.apache.org/docs/history.html](/docs/history.html)
-- if you receive an OutOfMemoryError during the build, make sure to have set the environment variable `MAVEN_OPTS=-Xmx512m`
+ - you have a recent Git client installed and on your shell's path.
+
+ - you have JDK 8 installed and on your shell's path to build Maven 3.7.0+. Details about minimum JDK version to build an appropriate version can be found here: [https://maven.apache.org/docs/history.html](/docs/history.html)
+
+ - if you receive an OutOfMemoryError during the build, make sure to have set the environment variable `MAVEN_OPTS=-Xmx512m`
+
+ - you must use Maven 3.3.9+.
+
+ - follow Apache environment configuration steps outlined at: [Publishing Maven Artifacts](https://www.apache.org/dev/publishing-maven-artifacts.html#dev-env).
-- you must use Maven 3.3.9+.
-- follow Apache environment configuration steps outlined at: [Publishing Maven Artifacts](https://www.apache.org/dev/publishing-maven-artifacts.html#dev-env).
### Before you begin
+
If you started here, you may first want to review one of the following documents that cover the specifics of various types of releases we have in the Maven Project:
-- [Releasing Maven Core](./maven-core-release.html)
-- [Releasing a parent POM](./parent-pom-release.html)
+
+ - [ Releasing Maven Core](./maven-core-release.html)
+
+ - [ Releasing a parent POM](./parent-pom-release.html)
+
+
### Consider updating the parent versions
+
If the item you are planning to release is not using the most recent version of its parent (see [parent POMs](../../pom/) index), consider taking this opportunity to update to it.
+
+
### Make sure that site compilation works
+
Particularly if you update the parent or if you updated your javadoc, the site compilation process may fail, or reveal a conspicuous error. It is stressful and time-consuming to discover this \*after\* you stage a release and then try to follow the procedure to deploy the site for review. So you may find it more pleasant to check out the state of the site before you start:
+
+
```
mvn -Preporting site site:stage
```
+
### Stage the Release
- 1 Follow the release preparation, staging and closing the repository steps outlined in [Publishing Maven Releases](https://infra.apache.org/publishing-maven-artifacts.html).
+
+
+ 1 Follow the release preparation, staging and closing the repository steps outlined in [Publishing Maven Releases](https://infra.apache.org/publishing-maven-artifacts.html).
1 Stage the latest documentation as explained in [deploying Maven components reference documentation](../website/deploy-component-reference-documentation.html).
+
+
### Call the vote
+
Propose a vote on the dev list with the closed issues, the issues left, the staging repository and the staging site. For instance:
+
+
```
To: "Maven Developers List" <de...@maven.apache.org>
Subject: [VOTE] Release Apache Maven XXX Plugin version Y.Z
@@ -103,14 +129,21 @@ Vote open for at least 72 hours.
To get the JIRA release notes link, browse to the plugin's or component's JIRA page, select the _Road Map_ link, and use the link to _Release Notes_ that is next to the version being released.
+
To get the list of issues left in JIRA, browse to the plugin's or component's JIRA page, and from the _Preset Filters_ on the right, use the link for _Outstanding_ issues.
+
The vote is open for at least 72 hours means, that you need to wait at least 72 hours before proceeding. This gives others time to test your release and check that everything is good. If you have received after that not enough +1 votes to reach the quorum, this doesn't mean, the vote failed. It just takes a bit longer.
+
+
### Check the vote results
+
Copied from [Votes on Package Releases](https://www.apache.org/foundation/voting.html#ReleaseVotes).
+
+
```
Votes on whether a package is ready to be released use majority approval
-- i.e. at least three PMC members must vote affirmatively for release,
@@ -123,10 +156,14 @@ but the 'minimum quorum of three +1 votes' rule is universal.
The list of PMC members is available at [https://people.apache.org/committers-by-project.html#maven-pmc](https://people.apache.org/committers-by-project.html#maven-pmc).
+
#### Successful vote
+
Once a vote is **successful**, post the result to the `dev` list and cc the `PMC`. For instance:
+
+
```
To: "Maven Developers List" <de...@maven.apache.org>
CC: "Maven Project Management Committee List" <pr...@maven.apache.org>
@@ -145,10 +182,15 @@ I will promote the source release zip file to Apache distribution area and the a
Follow the procedure to the end.
+
+
#### Unsuccessful vote
+
Once a vote is **unsuccessful**, post the result to the `dev` list, For instance:
+
+
```
To: "Maven Developers List" <de...@maven.apache.org>
Subject: [CANCEL] [VOTE] Release Apache Maven XXX Plugin version Y.Z
@@ -160,34 +202,47 @@ The vote has been canceled.
For canceled vote the process will need to be restarted.
+
Be sure to:
-- drop your staging repository as described in [Drop a repository](https://www.apache.org/dev/publishing-maven-artifacts.html)
-- create new version for next round `Y.Z+1`
-- assign issues from version `Y.Z` also to version `Y.Z+1`
+ - drop your staging repository as described in [Drop a repository](https://www.apache.org/dev/publishing-maven-artifacts.html)
+
+ - create new version for next round `Y.Z+1`
+
+ - assign issues from version `Y.Z` also to version `Y.Z+1`
-- mark the `Y.Z` version as **archived**
+ - mark the `Y.Z` version as **archived**
-- report found issues and assign them to version `Y.Z+1`
+ - report found issues and assign them to version `Y.Z+1`
+
+ - fix found issues
-- fix found issues
Start the process for version `Y.Z+1` from the beginning.
+
+
+
### Copy the source release to the Apache Distribution Area
+
The official Apache release is the 'source-release' bundle distributed in `www.apache.org/dist`, as described in [Apache Release Distribution Policy](https://www.apache.org/dev/release-distribution). All releases for Maven must be copied to [the official Maven release area](https://www.apache.org/dist/maven/).
+
The release area is maintained with svnpubsub. To deliver a release, you add it to [the subversion repository for the dist area](https://dist.apache.org/repos/dist/release/maven): add the release, its signature and sha512 checksum files, copying them from `target/checkout/target/` directory created during `mvn release:perform` step. Currently this requires to be in maven-pmc group (see [INFRA-5945](https://issues.apache.org/jira/browse/INFRA-5945)). If you are not a PMC member, drop a l [...]
+
+
```
for f in *.zip ; do echo -n $(sha512sum $f | cut -c -128) > $f.sha512 ; done
```
For example:
+
+
```
wagon/wagon-2.2-source-release.zip
wagon/wagon-2.2-source-release.zip.asc
@@ -196,48 +251,76 @@ wagon/wagon-2.2-source-release.zip.sha512
You should also run 'svn rm' as needed to clear out older releases. As per [Apache Release Policy](https://www.apache.org/legal/release-policy.html#where-do-releases-go), only the latest release on a branch should stay in the main dist areas. So long as the previous release is at least a day old, the automatic archiver will have copied it to the archive.
+
To check that everything is ok in the dist area, dist-tool-plugin has been written and run once a day to produce ["Check Source Release" and "Check Errors" reports](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/).
+
+
### Add the release for next board report
+
After committing the 3 source-release files, visit [Apache Committee Report Helper](https://reporter.apache.org/addrelease.html?maven) to add your release data with the Full Version Name and Date of Release. (You will receive an e-mail for it as well).
+
If you are not a PMC member, drop a line to _private@maven.apache.org_ and ask them to do this step for you if they did not do the update while adding to release area.
+
+
### Promote the release
+
Once the release is deemed fit for public consumption it can be transfered to a production repository where it will be available to all users.
+
+
1 See [Promoting a Repo](https://www.apache.org/dev/publishing-maven-artifacts.html#promote) for details on promotion.
1 Deploy the current website
As above, deploy the web site if appropriate and update the project site for the new release: use [Component Reference Documentation Helper](../website/component-reference-documentation-helper.html) to generate commands or see [Publishing versioned component reference documentation](../website/deploy-component-reference-documentation.html#Publishing_versioned_component_reference_documentation) for explanations. Note that not all projects follow these conventions exactly.
+
+
In case there's an overview table with version (e.g. [plugins](/plugins/index.html) and [shared](/shared/index.html)) you can directly edit it on the github page.
+
+
1 Update the version tracking in JIRA
In the relevant project, go to Administration, then Versions. Mark the `Y.Z` version as 'released'. Create version `Y.Z+1`, if that hasn't already been done. You may also archive any deprecated releases (milestones or alphas) at this time.
+
+
Note: Currently this requires to be in the maven-pmc group. So, if you don't see the Administration option in JIRA, kindly ask _private@maven.apache.org_ to do this step for you.
+
+
1 Wait for everything to sync
a Sync to [Maven Central](https://repo.maven.apache.org/maven2/org/apache/maven/)
The sync into central staging from repository.apache.org occurs every 4 hours. There is a separate hourly schedule that runs which pushes from staging to the other central machines, and then updates the indexes.
+
+
a Sync to Maven Website
If the project you are releasing doesn't yet use svnpubsub for site deployment, the deployment of the Maven website will [take an hour or so to sync](https://www.apache.org/dev/release-publishing.html#sync-delay).
+
+
+
+
1 Create an announcement.
Following instructions are done for plugins: if you are releasing anything else than a plugin, you should adapt email content to match what you are releasing.
+
+
**Note:** You must send this email from your apache email account, e.g. YOUR_APACHE_USERNAME@apache.org otherwise the email to `announce@maven.apache.org` will bounce.
+
+
```
From: YOUR_APACHE_USERNAME@apache.org
To: announce@maven.apache.org, users@maven.apache.org
@@ -272,8 +355,14 @@ Enjoy,
```
+
1 If releasing the Apache Parent POM, notify `release-discuss@apache.org`: Several projects follow this list, and should be made aware of changes to the common parent. This might also be a step to take if other shared resources are released, or if plugin releases are of particular interest to that group.
If releasing Maven Core, notify `announce@apache.org`
+
+
1 Celebrate :o)
+
+
+
diff --git a/content/markdown/developers/release/parent-pom-release.md b/content/markdown/developers/release/parent-pom-release.md
index b9eef9ed..667abcdd 100644
--- a/content/markdown/developers/release/parent-pom-release.md
+++ b/content/markdown/developers/release/parent-pom-release.md
@@ -23,16 +23,24 @@ under the License.
## Releasing A Parent POM
+
Releasing a Parent POM is much the same as any other Maven project. The following guide walks through most of the steps:
-- [Maven Project Common Release procedure](./maven-project-release-procedure.html)
+
+
+ - [ Maven Project Common Release procedure](./maven-project-release-procedure.html)
+
Note that Parent POMs have particular conventions for managing and deploying the documentation.
+
### Rationale
+
To be able to publish a documentation for the parent POM without affecting released `pom.xml` and `site.xml`, parent POM projects have a specific structure, with the addition of `site-pom.xml` and `src/site-docs` to provide `mvn -f site-pom.xml site` with useful documentation content:
+
+
```
|-- pom.xml
|-- site-pom.xml
@@ -47,30 +55,44 @@ under the License.
And the `index.apt` page not only contains instructions about the content of the parent POM, but it maintains a history of POM releases links and diffs.
+
Each specific step is done to maintain `site-pom.xml` and `index.apt` in sync with the release being released.
+
+
### Stage the release
+
Before staging the release with usual procedure, you need to update `site-pom.xml` and `index.apt` to take the future release into account:
+
+
1 update `site-pom.xml` parent POM version to match the version being released,
1 update `src/site-docs/index.apt.vm`: add a line in the history of `pom.xml` for the version being released, referring to the future git release tag and date.
+
Once these modifications are done, you can follow [standard component documentation staging steps](../website/deploy-component-reference-documentation.html), taking care to use the `site-pom.xml` POM, with `mvn -f site-pom.xml ...` command, each time the parent POM's site is generated or published.
+
Then the only difference is with commands to stage the site:
+
+
```
cd target/checkout
mvn -f site-pom.xml site
mvn -f site-pom.xml scm-publish:publish-scm
```
+
### Call the vote
+
In the vote, instead of providing links to JIRA, the parent POMs should include a link to the Git changes since the last release:
+
+
```
...
Hi,
@@ -85,3 +107,5 @@ https://github.com/apache/maven-parent/compare/maven-parent-<VERSION-OF-PREVIOUS
Staging repo:
...
```
+
+
diff --git a/content/markdown/developers/release/pmc-gpg-keys.md b/content/markdown/developers/release/pmc-gpg-keys.md
index 4a5890fb..a235cdf2 100644
--- a/content/markdown/developers/release/pmc-gpg-keys.md
+++ b/content/markdown/developers/release/pmc-gpg-keys.md
@@ -23,10 +23,14 @@ under the License.
## Introduction
+
You need to add your GPG keys in [https://svn.apache.org/repos/asf/maven/project/KEYS](https://svn.apache.org/repos/asf/maven/project/KEYS) before a release. Here are some useful [GnuPG](http://www.gnupg.org/) commands to generate your Keys.
+
### gpg --gen-key
+
+
```
>gpg --gen-key
gpg (GnuPG) 1.4.5; Copyright (C) 2006 Free Software Foundation, Inc.
@@ -104,8 +108,11 @@ sub 2048g/D2814A59 2006-10-10
```
+
### gpg --list-sigs && gpg --armor --export
+
+
```
>gpg --list-sigs "Vincent Siveton" && gpg --armor --export "Vincent Siveton"
pub 1024D/07DDB702 2006-10-10
@@ -116,16 +123,25 @@ sig 07DDB702 2006-10-10 Vincent Siveton <vs...@apache.org>
```
+
+
## Version: GnuPG v1.4.5 (MingW32)
+
+
## mQGiBEUrnAsRBACQDiYGc1IQmkENLO9iznBg8otGPEbzqQozT5tsip5mB30f6Mc/ uuLxJkLdna7Ul3goIXDtCeLJq38gHvruNtVNR6S+juJFkd5sLEH8UJ18PbKuo/9I KGlzjtCYUUDC48czRr0efhqd54NH8ydNdpaZ76NGPPYfpXtk7kKgH/nPiwCgxozK IG2frMuWIvdFafbqdAl7y/sD/1Csf0r9jtHEeXOuyhm8jCGrSwzLbHUGKPUQP37P ajECHoWp6HnvHEEEpgVl+UjfZvrcVhzUoP+3r5HAugqERfkzK8AWc7qjIRjf64kU sjvto31G2KYz17Y8K9y4LkRkUspu8uw903pKnW/QELg4vvPVaEYpVVIdS6+cUreu V0hOA/4tW7T/GpzSbQmjvnIRQ7GVHbQeXsANwrS6NmGYIxafN9P9dfHV+eUieTu6 rvMP9coOhTYyEKZksrXw2MmXx5SzgxsXT0 [...]
+
You need to append this result to [https://svn.apache.org/repos/asf/maven/project/KEYS](https://svn.apache.org/repos/asf/maven/project/KEYS).
+
You also need to upload your key to the public server: [http://pgp.mit.edu/](http://pgp.mit.edu/) by copying the same you appended in the text field and submit. You can ensure by searching your email in key search engine.
+
### gpg --fingerprint
+
+
```
>gpg --fingerprint vsiveton
pub 1024D/07DDB702 2006-10-10
@@ -136,4 +152,8 @@ sub 2048g/D2814A59 2006-10-10
Go to [https://id.apache.org](https://id.apache.org), log in and fill `OpenPGP Public Key Primary Fingerprint:` with the value of `Key fingerprint`.
+
You can read more about [Checksums And Signatures](https://www.apache.org/dev/release-signing.html#faq).
+
+
+
diff --git a/content/markdown/developers/retirement-plan-plugins.md b/content/markdown/developers/retirement-plan-plugins.md
index f190e96d..77bbec25 100644
--- a/content/markdown/developers/retirement-plan-plugins.md
+++ b/content/markdown/developers/retirement-plan-plugins.md
@@ -22,20 +22,28 @@ under the License.
-->
## Retirement Plan for Plugins
+
### Decide to retire
+
Propose a vote on the dev-list to retire a plugin. The vote should be open for the standard 72 hours to allow people to voice their opinions. Send a cc to the users-list. Standard Apache voting rules apply. Only PMC votes are binding.
+
The vote must contain one or more options on how to retire the plugin. There are multiple scenarios available. Here are a couple that have been suggested:
+
+
A Move to our retired area in svn
A Move to another Apache project
A Move to www.mojohaus.org, apache-extras.org or another forge
+
Here's a template for scenario A that can be used for the vote email:
+
+
```
To: "Maven Developers List" <de...@maven.apache.org>
Cc: "Maven Users List" <us...@maven.apache.org>
@@ -63,6 +71,8 @@ The vote is open for 72 hours.
If the vote is successful, post the result to the dev list and cc the PMC and users list. For instance:
+
+
```
To: "Maven Developers List" <de...@maven.apache.org>
Cc: "Maven Users List" <us...@maven.apache.org>
@@ -81,8 +91,12 @@ I will continue with the steps required to retire this plugin.
If the vote passes, make one final release of the plugin (with its own standard 72h vote on source release) before it is retired. This allows us to make a clean break. The person who wants to retire a plugin is the one who does the final release. Below you will find the extra steps that you need to follow when retiring a plugin, in addition to [our standard release process](./release/maven-project-release-procedure.html).
+
+
### Make the final release
+
+
1 Create an issue in JIRA with the issue type "Task" and the summary "Retire this plugin", and schedule it for the final release. If the plugin includes a JIRA report in the generated site, you will need to close this issue before you make the release.
1 Add the description "This is the final version of this plugin. It has been retired." to the final version in JIRA.
@@ -93,13 +107,17 @@ I will continue with the steps required to retire this plugin.
Note: This plugin is retired. It is no longer maintained.
```
+
If the plugin is moved elsewhere, that should also be added to the plugin's site. Suggested text:
+
+
```
Note: This plugin has retired from the Apache Maven project,
but has moved to the <Organization> <Project> project.
```
+
1 Add " (RETIRED)" at the end of `<project> <name>` in the plugin's `pom.xml`. This will show up on every page of the generated site.
1 Go ahead with [the standard release process](./release/maven-project-release-procedure.html), making sure that you follow the exceptions mentioned above regarding the site deployment.
@@ -108,15 +126,19 @@ but has moved to the <Organization> <Project> project.
1 When updating the version in JIRA, do not add Y.Z+1 and make sure you remove any future versions.
+
+
### Clean up after the release
- 1 Remove the `.Jenkinsfile` from all branches. This will remove the project from <https://builds.apache.org/job/maven-box/>
+
+
+ 1 Remove the `.Jenkinsfile` from all branches. This will remove the project from https://builds.apache.org/job/maven-box/
1 Ask INFRA for archive git repos (gitbox + github)
1 Republish documentation, postfix project name with (RETIRED)
- 1 When relevant update summary pages for [plugins](https://maven.apache.org/plugins/index.html) or [shared components](https://maven.apache.org/shared/index.html)
+ 1 When relevant update summary pages for [plugins](https://maven.apache.org/plugins/index.html) or [shared components](https://maven.apache.org/shared/index.html)
1 Add " (RETIRED)" at the end of the project name in JIRA.
@@ -130,4 +152,6 @@ but has moved to the <Organization> <Project> project.
1 Announce the fact that the plugin has been retired/moved on the announce@m.a.o and users@m.a.o mailing lists. Explain to people what they should do if they would like to continue development of the plugin.
+
<!-- Insert template for retirement email here -->
+
diff --git a/content/markdown/developers/website/component-reference-documentation-helper.md b/content/markdown/developers/website/component-reference-documentation-helper.md
index 54f110f8..dc881c9b 100644
--- a/content/markdown/developers/website/component-reference-documentation-helper.md
+++ b/content/markdown/developers/website/component-reference-documentation-helper.md
@@ -34,7 +34,7 @@ select component category, then type artifact id and version to generate svn com
<li><a href="?doxia-tools">Doxia Tools</a></li>
<li><a href="?others">others</a></li>
</ul>
-
+
</td><td>
<h3>Component information</h3>
diff --git a/content/markdown/developers/website/deploy-component-reference-documentation.md b/content/markdown/developers/website/deploy-component-reference-documentation.md
index ca48febc..976a785c 100644
--- a/content/markdown/developers/website/deploy-component-reference-documentation.md
+++ b/content/markdown/developers/website/deploy-component-reference-documentation.md
@@ -23,69 +23,102 @@ under the License.
## Introduction
+
This document gives step-by-step instructions for deploying Maven components reference documentation inside the Maven [https://maven.apache.org/](/) website.
+
See [Maven website introduction](./index.html) for instructions on the whole website publication (main site content + components).
+
+
## Overview
+
Since December 2012, the overall website uses svnpubsub mechanism:
<img src="component-reference-documentation.png" />Components reference documentation mechanisms overview
+
## How components reference documentation publication works
+
Components don't use CMS: components reference documentation are versioned and generated from full sources, with both handwritten content (like Maven main site) and content generated from sources (javadoc, unit-test results, integration test results...).
+
### Staging component reference documentation
+
Reference documentation of a component is staged in `https://maven.apache.org/xxx-archives/yyy-LATEST/`, where `yyy` is the component name and `xxx` can be:
-- the component type, like `shared`, `plugins`, `skins`, ... (see [/shared-archives/](/shared-archives/), [/plugins-archives/](/plugins-archives/), [/pom-archives/](/pom-archives/), [/skins-archives/](/skins-archives/))
-- the component name for standalone components, like `archetype`, `plugin-tools`, `surefire`, `wagon`, ... (see [/archetype-archives/](/archetype-archives/), [/archetypes-archives/](/archetypes-archives/), [/plugin-tools-archives/](/plugin-tools-archives/), [/scm-archives/](/scm-archives/), [/surefire-archives/](/surefire-archives/), [/wagon-archives/](/wagon-archives/))
+
+ - the component type, like `shared`, `plugins`, `skins`, ... (see [/shared-archives/](/shared-archives/), [/plugins-archives/](/plugins-archives/), [/pom-archives/](/pom-archives/), [/skins-archives/](/skins-archives/))
+
+ - the component name for standalone components, like `archetype`, `plugin-tools`, `surefire`, `wagon`, ... (see [/archetype-archives/](/archetype-archives/), [/archetypes-archives/](/archetypes-archives/), [/plugin-tools-archives/](/plugin-tools-archives/), [/scm-archives/](/scm-archives/), [/surefire-archives/](/surefire-archives/), [/wagon-archives/](/wagon-archives/))
+
To publish component reference documentation:
+
+
1 prerequisite: eventually build the component if it has not been done previously, or some reports may miss build or integration information:
Notice: In cases where you have prepared a release you can simple change into `target/checkout` directory and continue with 2.
+
+
```
mvn -Prun-its install
```
+
1 build the reference documentation:
```
mvn -Preporting site site:stage
```
+
Notice: `site:stage` is really necessary only for multi-modules components, but added unconditionally in these instructions to keep them as straightforward as possible.
+
+
1 stage the reference documentation to website production svn area, using [maven-scm-publish-plugin](/plugins/maven-scm-publish-plugin): (TODO: explanations on configuration in pom to yyy-LATEST)
```
mvn scm-publish:publish-scm
```
+
svnpubsub mechanism transfers svn production content to live production site
+
+
+
**Notice**: content is in fact published to [/components/](/components/) directory, and symbolic links declared in `resources/\*\*/components.links` in main site source are used by Ant to create a reference from `/xxx` (= what we want to be user-visible) to `/components/xxx` (what what is checked out).
+
+
### Publishing versioned component reference documentation
+
When doing a release, `yyy-LATEST` content staged in previous section needs:
+
+
1 to be archived to versioned directory before a newer revision is published into -LATEST,
1 to replace the actual component reference documentation.
+
This is done with operations on website production svn area: you can use [Component Reference Documentation Helper](./component-reference-documentation-helper.html) to easily prepare svnmucc command line.
+
If you prefer to do everything by hand from command templates, you can do either with `svn` command:
-- Unix:
+
+
+ - Unix:
```
SVNPUBSUB=https://svn.apache.org/repos/asf/maven/website/components
@@ -96,7 +129,8 @@ svn rm $SVNPUBSUB/xxx/yyy -m "Remove old site."
svn cp $SVNPUBSUB/xxx-archives/yyy-$version $SVNPUBSUB/xxx/yyy -m "Publish new site."
```
-- Windows:
+
+ - Windows:
```
set SVNPUBSUB=https://svn.apache.org/repos/asf/maven/website/components
@@ -107,8 +141,12 @@ svn rm %SVNPUBSUB%/xxx/yyy -m "Remove old site."
svn cp %SVNPUBSUB%/xxx-archives/yyy-$version %SVNPUBSUB%/xxx/yyy -m "Publish new site."
```
+
+
or with [`svnmucc` command](http://svnbook.red-bean.com/en/1.8/svn.ref.svnmucc.re.html):
+
+
```
svnmucc -m "Publish yyy $version documentation" \
-U https://svn.apache.org/repos/asf/maven/website/components \
@@ -117,12 +155,20 @@ svnmucc -m "Publish yyy $version documentation" \
cp HEAD xxx-archives/yyy-LATEST xxx/yyy
```
+
### Updating index page in the Maven site
+
Some component types have an index page refering to each components of the same type. This is the case for plugins (see [index](/plugins/)), shared (see [index](/shared/)), poms (see [index](/pom/)) and skins (see [index](/skins/)).
+
Update the version number and release date for the component in the `content/apt/xxx/index.apt` page.
+
See [Deploy Maven website](../website/deploy-maven-website.html) for more in-depth instructions on main site content editing.
+
**Notice**: if you forget about updating the index page, dist-tool has a [report run daily](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/) that will gently send a failure notification on notifications@maven.a.o when "Check Errors" report is not empty.
+
+
+
diff --git a/content/markdown/developers/website/deploy-maven-website.md b/content/markdown/developers/website/deploy-maven-website.md
index aa9f1420..9f0940e1 100644
--- a/content/markdown/developers/website/deploy-maven-website.md
+++ b/content/markdown/developers/website/deploy-maven-website.md
@@ -23,39 +23,56 @@ under the License.
## Introduction
+
This document gives step-by-step instructions for deploying the main Maven [https://maven.apache.org](/) website.
+
**Obsolete** this documentation is obsolete: with the migration of site source to Git, Apache CMS is not used any more. It is replaced by Git edit (eventually through GitHub with the "edit" link accessible from breadcrumb) followed by Jenkins job to build and commit to svnpubsub.
+
See [Maven website introduction](./index.html) for instructions on the whole website publication.
+
+
## Overview
+
Since December 2012, the overall website uses svnpubsub mechanism and the main website uses Apache CMS:
<img src="main-website.png" />Main website mechanisms overview
+
## How main website publication works
+
Maven main website ([https://maven.apache.org](https://maven.apache.org)) is generated with [maven-site-plugin](/plugins/maven-site-plugin) from a source tree stored in svn: [https://svn.apache.org/repos/asf/maven/site/trunk](https://svn.apache.org/repos/asf/maven/site/trunk).
+
### Edit source content
+
You can edit source content in 2 ways:
- 1 use [the CMS UI](https://cms.apache.org/maven/) through your web browser:
-- Go to [https://cms.apache.org/maven/](https://cms.apache.org/maven/).
-- Click link "Get Maven Working Copy".
+ 1 use [the CMS UI](https://cms.apache.org/maven/) through your web browser:
+
+ - Go to [https://cms.apache.org/maven/](https://cms.apache.org/maven/).
+
+ - Click link "Get Maven Working Copy".
+
+ - Navigate to the content you want to modify.
+
+ - Once you have modified the content, commit with the button "Submit".
-- Navigate to the content you want to modify.
-- Once you have modified the content, commit with the button "Submit".
1 checkout the source content locally, modify it with your favorite text editor, eventually test the result (`mvn site`), then check-in source modifications.
- After source tree is modified in svn, [a Buildbot job](http://ci.apache.org/builders/maven-site-staging) is triggered:
+
+ After source tree is modified in svn, [a Buildbot job](http://ci.apache.org/builders/maven-site-staging) is triggered:
+
+
1 it builds the HTML site using [maven-site-plugin](/plugins/maven-site-plugin): `mvn site`,
@@ -63,28 +80,42 @@ under the License.
1 svnpubsub mecanism transfers svn CMS staging content to live CMS staging site: [http://maven.staging.apache.org](http://maven.staging.apache.org),
+
+
### Publish site content
+
If everything is good, **publish modifications** using [CMS publish](https://cms.apache.org/maven/publish) action.
+
Under the hood:
+
+
1 CMS copies CMS staging svn area content to [website production svn area](https://svn.apache.org/repos/infra/websites/production/maven/content/),
1 svnpubsub mecanism transfers svn production content to live production site: [http://maven.apache.org](http://maven.apache.org).
+
+
+
## How Doxia website publication works
+
Doxia uses the exact same mecanisms:
-- you can edit [svn source tree](https://svn.apache.org/repos/asf/maven/doxia/site/trunk) either locally or through [CMS UI](https://cms.apache.org/maven-doxia/),
-- [a Buildbot job](http://ci.apache.org/builders/maven-doxia-site-staging) builds the site and updates [website staging svn area](https://svn.apache.org/repos/infra/websites/staging/maven-doxia/trunk/content/),
-- svnpubsub published to [live staging site](http://maven-doxia.staging.apache.org),
+ - you can edit [svn source tree](https://svn.apache.org/repos/asf/maven/doxia/site/trunk) either locally or through [CMS UI](https://cms.apache.org/maven-doxia/),
+
+ - [a Buildbot job](http://ci.apache.org/builders/maven-doxia-site-staging) builds the site and updates [website staging svn area](https://svn.apache.org/repos/infra/websites/staging/maven-doxia/trunk/content/),
+
+ - svnpubsub published to [live staging site](http://maven-doxia.staging.apache.org),
+
+ - if everything is good, **publish modifications** using [CMS publish](https://cms.apache.org/maven-doxia/publish) action,
+
+ - CMS copies CMS staging svn area content to [website production svn area](https://svn.apache.org/repos/infra/websites/production/maven-doxia/content/),
-- if everything is good, **publish modifications** using [CMS publish](https://cms.apache.org/maven-doxia/publish) action,
+ - svnpubsub mecanism transfers svn production content to live production site: [http://maven.apache.org/doxia](http://maven.apache.org/doxia), with its [`extpaths.txt`](/doxia/extpaths.txt)
-- CMS copies CMS staging svn area content to [website production svn area](https://svn.apache.org/repos/infra/websites/production/maven-doxia/content/),
-- svnpubsub mecanism transfers svn production content to live production site: [http://maven.apache.org/doxia](http://maven.apache.org/doxia), with its [`extpaths.txt`](/doxia/extpaths.txt)
diff --git a/content/markdown/developers/website/index.md b/content/markdown/developers/website/index.md
index 46baa0d4..75ee1501 100644
--- a/content/markdown/developers/website/index.md
+++ b/content/markdown/developers/website/index.md
@@ -23,30 +23,45 @@ under the License.
## Introduction
+
The Maven [https://maven.apache.org](https://maven.apache.org) website is composed from:
-- a main content,
-- multiple components reference documentation, published for each component release.
+
+ - a main content,
+
+ - multiple components reference documentation, published for each component release.
+
And [Doxia](https://maven.apache.org/doxia/) website has the same dual structure.
+
These contents are stored in svn, and svnpubsub/svnwcsub maintains a working copy on the webservers in `/www/maven.apache.org/content` (see [`svnwcsub` configured in infra Puppet](https://github.com/apache/infrastructure-puppet/blob/deployment/modules/svnwcsub/files/svnwcsub.conf#L123)):
-- `/` comes from [https://svn.apache.org/repos/asf/maven/website/content/](https://svn.apache.org/viewvc/maven/website/content/)
-- [`/components`](https://maven.apache.org/components) comes from [https://svn.apache.org/repos/asf/maven/website/components/](https://svn.apache.org/repos/asf/maven/website/components/)
-- `/doxia` comes from [https://svn.apache.org/repos/asf/maven/doxia/website/content/](https://svn.apache.org/viewvc/maven/doxia/website/content/)
+ - `/` comes from [https://svn.apache.org/repos/asf/maven/website/content/](https://svn.apache.org/viewvc/maven/website/content/)
+
+ - [`/components`](https://maven.apache.org/components) comes from [https://svn.apache.org/repos/asf/maven/website/components/](https://svn.apache.org/repos/asf/maven/website/components/)
+
+ - `/doxia` comes from [https://svn.apache.org/repos/asf/maven/doxia/website/content/](https://svn.apache.org/viewvc/maven/doxia/website/content/)
+
+ - [`/doxia/components`](https://maven.apache.org/doxia/components) comes from [https://svn.apache.org/repos/asf/maven/doxia/website/components/](https://svn.apache.org/repos/asf/maven/doxia/website/components/)
-- [`/doxia/components`](https://maven.apache.org/doxia/components) comes from [https://svn.apache.org/repos/asf/maven/doxia/website/components/](https://svn.apache.org/repos/asf/maven/doxia/website/components/)
and the link between main content and components reference documentation (for example from `/plugins/maven-xxx-plugin` to internal `/components/plugins/maven-xxx-plugin`) is done with symbolic links. These links are configured in `components.links` files in `content/resources/` and subdirectories, for example [plugins/components.links](https://github.com/apache/maven-site/blob/master/content/resources/plugins/components.links).
+
+
## How website publication works
+
Instructions on how to publish website content are split in separate documents:
-- on every main content source commit ([maven-site.git](https://github.com/apache/maven-site) and [maven-doxia-site.git](https://github.com/apache/maven-doxia-site)), main content rebuild and publish is triggered through Jenkins jobs ( [maven-site job](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-site/) and [doxia-site job](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-doxia-site/)), which basically run `mvn site-deploy` (it can be run locally if CI is off...),
-- on every Maven component release, release manager follows "[deploying Maven components reference documentation](./deploy-component-reference-documentation.html)", eventually using [Component Reference Documentation Helper](./component-reference-documentation-helper.html) to easily prepare `svnmucc` command line.
+
+ - on every main content source commit ([maven-site.git](https://github.com/apache/maven-site) and [maven-doxia-site.git](https://github.com/apache/maven-doxia-site)), main content rebuild and publish is triggered through Jenkins jobs ( [maven-site job](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-site/) and [doxia-site job](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-doxia-site/)), which basically run `mvn site-deploy` (it can be run locally if CI is off...),
+
+ - on every Maven component release, release manager follows "[deploying Maven components reference documentation](./deploy-component-reference-documentation.html)", eventually using [Component Reference Documentation Helper](./component-reference-documentation-helper.html) to easily prepare `svnmucc` command line.
+
+
diff --git a/content/markdown/developers/website/website-overview.md b/content/markdown/developers/website/website-overview.md
index fe6d8aa8..21fe3bb8 100644
--- a/content/markdown/developers/website/website-overview.md
+++ b/content/markdown/developers/website/website-overview.md
@@ -22,12 +22,17 @@ under the License.
-->
## Introduction
+
The Maven [https://maven.apache.org](/) website is composed from:
-- a main content
-- multiple components reference documentation
+
+ - a main content
+
+ - multiple components reference documentation
<img src="website-overview.png" />Website mechanisms overview
See [Maven website introduction](./index.html) for instructions on website publication.
+
+
diff --git a/content/markdown/developers/welcome-to-new-committers.md b/content/markdown/developers/welcome-to-new-committers.md
index 2bd6315d..3d47244b 100644
--- a/content/markdown/developers/welcome-to-new-committers.md
+++ b/content/markdown/developers/welcome-to-new-committers.md
@@ -22,30 +22,45 @@ under the License.
-->
## Guide for new Maven committers
+
First of all congratulations, thank you, and welcome to the fold! If you are reading this you've recently been voted in as committer on an Apache Maven project and there are a few things that need to be sorted out before you can participate fully.
+
The first thing to get out of the way is sending in your contributor's license agreement (CLA). You can't participate at Apache until we have received your signed CLA, so go to the [Apache website](http://www.apache.org/licenses/#clas), print out the CLA, sign it, and send it in ASAP.
+
Once you've dealt with your CLA, there are a some documents that pertain to Apache as a whole you should read:
-- [How the ASF works](http://www.apache.org/foundation/how-it-works.html)
-- [Guide for new committers](http://www.apache.org/dev/new-committers-guide.html)
-- [The committers FAQ](http://www.apache.org/dev/committers.html)
+ - [How the ASF works](http://www.apache.org/foundation/how-it-works.html)
+
+ - [Guide for new committers](http://www.apache.org/dev/new-committers-guide.html)
+
+ - [The committers FAQ](http://www.apache.org/dev/committers.html)
+
+ - [How voting works](http://www.apache.org/foundation/voting.html)
-- [How voting works](http://www.apache.org/foundation/voting.html)
Here are the documents that pertain to Maven specifically:
-- [Guide to Maven development](/guides/development/guide-maven-development.html)
-- [Setup your committer environment](/developers/committer-environment.html)
+
+ - [Guide to Maven development](/guides/development/guide-maven-development.html)
+
+ - [Setup your committer environment](/developers/committer-environment.html)
+
And here are the specifics on setting up your Git access:
-- [Apache's Source Code Repository](http://www.apache.org/dev/version-control.html)
+
+
+ - [Apache's Source Code Repository](http://www.apache.org/dev/version-control.html)
+
If you have any questions just ask! We're here to help, and looking forward to working with you!
+
The Maven Team!
+
+
diff --git a/content/markdown/docs/3.2.1/release-notes.md b/content/markdown/docs/3.2.1/release-notes.md
index f09242a2..170cf101 100644
--- a/content/markdown/docs/3.2.1/release-notes.md
+++ b/content/markdown/docs/3.2.1/release-notes.md
@@ -99,6 +99,7 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
+[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330185
[5]: ../../docs/history.html
[MNG-2315]: https://issues.apache.org/jira/browse/MNG-2315
@@ -106,6 +107,9 @@ See [complete release notes for all versions][5]
[MNG-5582]: https://issues.apache.org/jira/browse/MNG-5582
[MNG-5230]: https://issues.apache.org/jira/browse/MNG-5230
[MNG-5389]: https://issues.apache.org/jira/browse/MNG-5389
+[MNG-5578]: https://issues.apache.org/jira/browse/MNG-5578
+[MNG-5530]: https://issues.apache.org/jira/browse/MNG-5530
+[MNG-5549]: https://issues.apache.org/jira/browse/MNG-5549
[MNG-5575]: https://issues.apache.org/jira/browse/MNG-5575
[MNG-5576]: https://issues.apache.org/jira/browse/MNG-5576
[MNG-5581]: https://issues.apache.org/jira/browse/MNG-5581
diff --git a/content/markdown/docs/3.2.2/release-notes.md b/content/markdown/docs/3.2.2/release-notes.md
index d5814845..a9db4484 100644
--- a/content/markdown/docs/3.2.2/release-notes.md
+++ b/content/markdown/docs/3.2.2/release-notes.md
@@ -71,7 +71,7 @@ Multiple profile activation conditions are now ANDed instead of ORed. We believe
### Support resolution of Import Scope POMs from Repo that contains a ${parameter} ([MNG-5639][MNG-5639])
-This feature helps support the pattern where many streams of development are setup with an individually sandboxed repository holding specific version of several shared components. A repository configuration might use the pattern ${nexus.baseurl}/content/groups/${stream.name} where the properties are set in settings.xml file.
+This feature helps support the pattern where many streams of development are setup with an individually sandboxed repository holding specific version of several shared components. A repository configuration might use the pattern ${nexus.baseurl}/content/groups/${stream.name} where the properties are set in settings.xml file.
### Update maven-plugin-plugin:descriptor default binding from generate-resources phase to process-classes ([MNG-5346][MNG-5346])
@@ -117,6 +117,7 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
+[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330186
[5]: ../../docs/history.html
[MNG-2199]: https://issues.apache.org/jira/browse/MNG-2199
diff --git a/content/markdown/docs/3.2.3/release-notes.md b/content/markdown/docs/3.2.3/release-notes.md
index abf5e38a..3518c412 100644
--- a/content/markdown/docs/3.2.3/release-notes.md
+++ b/content/markdown/docs/3.2.3/release-notes.md
@@ -53,6 +53,11 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
+[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330187
[5]: ../../docs/history.html
[MNG-5672]: https://issues.apache.org/jira/browse/MNG-5672
+[MNG-4565]: https://issues.apache.org/jira/browse/MNG-4565
+[MNG-5346]: https://issues.apache.org/jira/browse/MNG-5346
+[MNG-5452]: https://issues.apache.org/jira/browse/MNG-5452
+[MNG-5639]: https://issues.apache.org/jira/browse/MNG-5639
diff --git a/content/markdown/docs/3.2.5/release-notes.md b/content/markdown/docs/3.2.5/release-notes.md
index 2d987cc8..c4484194 100644
--- a/content/markdown/docs/3.2.5/release-notes.md
+++ b/content/markdown/docs/3.2.5/release-notes.md
@@ -47,5 +47,6 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
+[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330189
[5]: ../../docs/history.html
diff --git a/content/markdown/docs/3.3.1/release-notes.md b/content/markdown/docs/3.3.1/release-notes.md
index 918c407b..69950e46 100644
--- a/content/markdown/docs/3.3.1/release-notes.md
+++ b/content/markdown/docs/3.3.1/release-notes.md
@@ -21,7 +21,7 @@
## Overview
-The Apache Maven team would like to announce the release of Maven Version 3.3.1. The new
+The Apache Maven team would like to announce the release of Maven Version 3.3.1. The new
Maven Version is [available for download][0].
Maven is a software project management and comprehension tool. Based on the concept of a project object model
@@ -47,43 +47,43 @@ Maven project][5].
The new [Maven 3.3.1 Release is just out](http://mail-archives.apache.org/mod_mbox/maven-announce/201503.mbox/%3C1954448.IV3m89R0sE%40herve-desktop%3E). Let us take a deeper look into the new features/improvements:
-- The first and most important thing is that [Maven 3.3.1 needs JDK 1.7][MNG-5780].
+* The first and most important thing is that [Maven 3.3.1 needs JDK 1.7][MNG-5780].
### Toolchains
-- In our days it becomes more and more important to be able to use different JDK
+* In our days it becomes more and more important to be able to use different JDK
to be used by Maven itself and which is used to compile/test your production code.
- This concept is know under the name [Toolchains][0] which is unfortunately not very
+ This concept is know under the name [Toolchains][0] which is unfortunately not very
well-known.
-- The handling of the [`toolchains.xml`][MNG-3891] file has been adjusted with the
+* The handling of the [`toolchains.xml`][MNG-3891] file has been adjusted with the
handling of `settings.xml` which means it will be searched within the
`${maven.home}/conf/` directory and furthermore within the `${user.home}/.m2/` directory.
-- For a better understanding and as an example of the `toolchains.xml` file has been added
+* For a better understanding and as an example of the `toolchains.xml` file has been added
to the [Maven distribution][MNG-5745].
-- Maven has been improved to read the `toolchains.xml` file [during initialization][MNG-5754] instead
+* Maven has been improved to read the `toolchains.xml` file [during initialization][MNG-5754] instead
of waiting till [maven-toolchains-plugin][maven-toolchains-plugin] will read it.
-- Maven has a new option to handle global toolchains file `-gt file` or `--global-toolchains file`
+* Maven has a new option to handle global toolchains file `-gt file` or `--global-toolchains file`
in the spirit of global settings file[MNG-3891][MNG-3891].
### Core Extensions
-- Core Extension mechanism has [been improved][MNG-5771] to make
+* Core Extension mechanism has [been improved][MNG-5771] to make
it simpler to use.
-- The old way (up to Maven 3.2.5) was to create a jar (must be shaded if you have other dependencies)
- which contains the extension and put it manually into the `${MAVEN_HOME}/lib/ext` directory.
- This means you had to change the Maven installation. The consequence was that everyone who likes
- to use this needed to change it's installation and makes the on-boarding for a developer much
- more inconvenient. The other option was to give the path to the jar on command line via
+* The old way (up to Maven 3.2.5) was to create a jar (must be shaded if you have other dependencies)
+ which contains the extension and put it manually into the `${MAVEN_HOME}/lib/ext` directory.
+ This means you had to change the Maven installation. The consequence was that everyone who likes
+ to use this needed to change it's installation and makes the on-boarding for a developer much
+ more inconvenient. The other option was to give the path to the jar on command line via
`mvn -Dmaven.ext.class.path=extension.jar`. This has the drawback giving those
options to your Maven build every time you are calling Maven. Not very convenient as well.
-
-- From now on this can be done much more simpler and in a more Maven like way. So
- you can define an `${maven.projectBasedir}/.mvn/extensions.xml` file which looks
+
+* From now on this can be done much more simpler and in a more Maven like way. So
+ you can define an `${maven.projectBasedir}/.mvn/extensions.xml` file which looks
like the following:
``` xml
@@ -97,7 +97,7 @@ The new [Maven 3.3.1 Release is just out](http://mail-archives.apache.org/mod_mb
</extensions>
```
-- Now you can simply use an extension by defining the usual maven coordinates
+* Now you can simply use an extension by defining the usual maven coordinates
`groupId`, `artifactId`, `version` as any other artifact. Furthermore all
transitive dependencies of those extensions will automatically being downloaded
from your repository. So no need to create a shaded artifact anymore.
@@ -114,28 +114,28 @@ The new [Maven 3.3.1 Release is just out](http://mail-archives.apache.org/mod_mb
### JVM and Command Line Options
-- [Project specific jvm and command line otions][MNG-5767]
+* [Project specific jvm and command line otions][MNG-5767]
-- It's really hard to define a general set of options for calling the maven
+* It's really hard to define a general set of options for calling the maven
command line. Usually this will be solved by putting this options to a script
but this can now simple being done by defining
`${maven.projectBasedir}/.mvn/maven.config` file which contains the
configuration options for the command line. For example things like `-T3 -U
--fail-at-end`. So you only have to call maven just by using `mvn clean
package` instead of `mvn -T3 -U --fail-at-end clean package` and not to miss
- the `-T3 -U --fail-at-end` options. The `${maven.projectBasedir}/.mvn/maven.config`
- is located in the `${maven.projectBasedir}/.mvn/` directory which is in the root
- of a multi module build. This directory is part of the project and will be checked
- in into your version control. This results in being picked by everybody who
- checks out the project and no need to remember to call this project
+ the `-T3 -U --fail-at-end` options. The `${maven.projectBasedir}/.mvn/maven.config`
+ is located in the `${maven.projectBasedir}/.mvn/` directory which is in the root
+ of a multi module build. This directory is part of the project and will be checked
+ in into your version control. This results in being picked by everybody who
+ checks out the project and no need to remember to call this project
via `mvn -T3 -U --fail-at-end clean package` instead of `mvn clean package`.
-- In Maven it is not simple to define JVM configuration on a per project base.
+* In Maven it is not simple to define JVM configuration on a per project base.
The existing mechanism based on an environment variable `MAVEN_OPTS` and the
usage of `${user.home}/.mavenrc` is an other
option with the drawback of not being part of the project.
-- Starting with this release you can define JVM configuration via
+* Starting with this release you can define JVM configuration via
`${maven.projectBasedir}/.mvn/jvm.config` file which means you can define the
options for your build on a per project base. This file will become part of
your project and will be checked in along with your project. So no need anymore
@@ -146,19 +146,20 @@ The new [Maven 3.3.1 Release is just out](http://mail-archives.apache.org/mod_mb
-Xmx2048m -Xms1024m -XX:MaxPermSize=512m -Djava.awt.headless=true
```
-- you don't need to remember of using this options in `MAVEN_OPTS` or switching
+* you don't need to remember of using this options in `MAVEN_OPTS` or switching
between different configurations.
+
### Plugin Goal Invocation from Command Line
-- Improvement for [Plugin Goal Invocation from command line][MNG-5768]
+
+ * Improvement for [Plugin Goal Invocation from command line][MNG-5768]
If you call a plugin directly from command line like the following:
```
mvn exec:java
```
-
The configuration which is used here can be defined in your pom by using an execution id `default-cli`.
```
@@ -224,15 +225,18 @@ mvn exec:java@second-cli
```
So now you can define more than one configuration for command line executions.
-
-- The Maven team has decided to [drop support for Win9x in launch scripts](https://issues.apache.org/jira/browse/MNG-5776)
+
+ * The Maven team has decided to [drop support for Win9x in launch scripts](https://issues.apache.org/jira/browse/MNG-5776)
at long last. Yeah.
-The above release notes have [originally been written by Karl Heinz Marbaise
+
+The above release notes have [originally been written by Karl Heinz Marbaise
and migrated afterwards to the Apache Maven project](http://blog.soebes.de/blog/2015/03/17/apache-maven-3-dot-3-1-features/).
+
[0]: ../../download.html
[1]: ../../plugins/index.html
+[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330193
[5]: ../../docs/history.html
diff --git a/content/markdown/docs/3.3.3/release-notes.md b/content/markdown/docs/3.3.3/release-notes.md
index 52180e9d..4ed25601 100644
--- a/content/markdown/docs/3.3.3/release-notes.md
+++ b/content/markdown/docs/3.3.3/release-notes.md
@@ -47,5 +47,6 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
+[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12332054
[5]: ../../docs/history.html
diff --git a/content/markdown/docs/3.3.9/release-notes.md b/content/markdown/docs/3.3.9/release-notes.md
index 899e2aa1..d38486bd 100644
--- a/content/markdown/docs/3.3.9/release-notes.md
+++ b/content/markdown/docs/3.3.9/release-notes.md
@@ -35,138 +35,142 @@ We hope you enjoy using Maven! If you have any questions, please consult:
- the maven-user mailing list: [http://maven.apache.org/mailing-lists.html](/mailing-lists.html)
- the reference documentation: [http://maven.apache.org/ref/3.3.9/](/ref/3.3.9/)
+
Reporters and Contributors of this release
------------------------------------------
Bugs:
-- [MNG-5297] - contributor: Joseph Walton
-- [MNG-5721] - reporter/contributor Martin Schäf
-- [MNG-5786] - reporter Stephan Schroevers
-- [MNG-5787] - reporter Christian Schlichtherle
-- [MNG-5796] - reporter Brandon Enochs
-- [MNG-5812] - contributor tssp
-- [MNG-5816] - contributor tssp
-- [MNG-5858] - contributor Dave Syer
-- [MNG-5877] - contributor Joseph Walton; reporter Anders Forsell
-- [MNG-5882] - contributor Ben Caradoc-Davies
-- [MNG-5884] - contributor Stephen Kitt
-- [MNG-5886] - reporter Shubham Chaurasia
-- [MNG-5891] - reporter Keith Turner
-- [MNG-5898] - reporter Jonathan Radon
+ * [MNG-5297] - contributor: Joseph Walton
+ * [MNG-5721] - reporter/contributor Martin Schäf
+ * [MNG-5786] - reporter Stephan Schroevers
+ * [MNG-5787] - reporter Christian Schlichtherle
+ * [MNG-5796] - reporter Brandon Enochs
+ * [MNG-5812] - contributor tssp
+ * [MNG-5816] - contributor tssp
+ * [MNG-5858] - contributor Dave Syer
+ * [MNG-5877] - contributor Joseph Walton; reporter Anders Forsell
+ * [MNG-5882] - contributor Ben Caradoc-Davies
+ * [MNG-5884] - contributor Stephen Kitt
+ * [MNG-5886] - reporter Shubham Chaurasia
+ * [MNG-5891] - reporter Keith Turner
+ * [MNG-5898] - reporter Jonathan Radon
Improvements:
-- [MNG-5805] - contributor Anton Tanasenko
-- [MNG-5844] - contributor Tang Xinye
-- [MNG-5871] - make url inheritance algorithm more visible
-- [MNG-5923] - reporter/contributor: Stuart McCulloch
-- [MNG-5924] - reporter/contributor: Stuart McCulloch
+ * [MNG-5805] - contributor Anton Tanasenko
+ * [MNG-5844] - contributor Tang Xinye
+ * [MNG-5871] - make url inheritance algorithm more visible
+ * [MNG-5923] - reporter/contributor: Stuart McCulloch
+ * [MNG-5924] - reporter/contributor: Stuart McCulloch
Many thanks to all reporters and contributors and for their time and support.
Improvements
------------
-- The `par` lifecycle has been removed from the default life cycle bindings and the maven-ejb3-plugin
+ * The `par` lifecycle has been removed from the default life cycle bindings and the maven-ejb3-plugin
has been removed from default bindings, cause it does not exist [MNG-5892][MNG-5892], [MNG-5894][MNG-5894].
-- The default bindings defined two different versions for the [maven-resources-plugin][maven-resources-plugin]
+ * The default bindings defined two different versions for the [maven-resources-plugin][maven-resources-plugin]
which has been fixed by [MNG-5893][MNG-5893].
-- Switch to official [Guice](https://github.com/google/guice/wiki/Motivation) 4.0, upgrade to
+ * Switch to official [Guice](https://github.com/google/guice/wiki/Motivation) 4.0, upgrade to
[Eclipse/Sisu](https://www.eclipse.org/sisu/) 0.3.2 has been done with [MNG-5923][MNG-5923] and [MNG-5924][MNG-5924].
-
-- Several areas of Maven Core have been changed to use
- [Commons Lang](https://commons.apache.org/proper/commons-lang/)'s Validate to intercept invalid
+
+ * Several areas of Maven Core have been changed to use
+ [Commons Lang](https://commons.apache.org/proper/commons-lang/)'s Validate to intercept invalid
input [MNG-5649][MNG-5649].
-- Upgrade Java minimum version prerequisite from Java 6 to Java 7 [MNG-5780][MNG-5780].
+ * Upgrade Java minimum version prerequisite from Java 6 to Java 7 [MNG-5780][MNG-5780].
-- Custom packaging types: configuring DefaultLifecycleMapping mojo executions [MNG-5805][MNG-5805].
+ * Custom packaging types: configuring DefaultLifecycleMapping mojo executions [MNG-5805][MNG-5805].
-- Disallow the programmatic injection of project dependencies [MNG-5818][MNG-5818].
+ * Disallow the programmatic injection of project dependencies [MNG-5818][MNG-5818].
-- Close IO streams in finally or try-with-resource statement [MNG-5844][MNG-5844].
+ * Close IO streams in finally or try-with-resource statement [MNG-5844][MNG-5844].
-- Make url inheritance algorithm more visible [MNG-5871][MNG-5871].
+ * Make url inheritance algorithm more visible [MNG-5871][MNG-5871].
-- Update used [Modello](https://codehaus-plexus.github.io/modello/) version from 1.8.1 to 1.8.3 [MNG-5888][MNG-5888].
+ * Update used [Modello](https://codehaus-plexus.github.io/modello/) version from 1.8.1 to 1.8.3 [MNG-5888][MNG-5888].
-- Maven build does not work with Maven 2.2.1 [MNG-5905][MNG-5905].
+ * Maven build does not work with Maven 2.2.1 [MNG-5905][MNG-5905].
-- Use canonical name for UTC timezone [MNG-5906][MNG-5906].
+ * Use canonical name for UTC timezone [MNG-5906][MNG-5906].
-- Upgrade [maven-parent](/pom/maven/) to version 27 [MNG-5911][MNG-5911].
+ * Upgrade [maven-parent](/pom/maven/) to version 27 [MNG-5911][MNG-5911].
-- Upgrade [Wagon](/wagon/) version to 2.10 [MNG-5915][MNG-5915].
+ * Upgrade [Wagon](/wagon/) version to 2.10 [MNG-5915][MNG-5915].
-- Upgraded to [plexus-component-*](https://codehaus-plexus.github.io/plexus-containers/) 1.6 that uses
+ * Upgraded to [plexus-component-*](https://codehaus-plexus.github.io/plexus-containers/) 1.6 that uses
[asm](http://asm.ow2.org/) 5.x [MNG-5921][MNG-5921].
-- Upgrade [plexus-utils](https://codehaus-plexus.github.io/plexus-utils/) to 3.0.22 to support `combine.id` as configuration attribute for Map merging [MNG-5922][MNG-5922].
+ * Upgrade [plexus-utils](https://codehaus-plexus.github.io/plexus-utils/) to 3.0.22 to support `combine.id` as configuration attribute for Map merging [MNG-5922][MNG-5922].
+
+ * Update [animal-sniffer-maven-plugin](https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/) to 1.14. MANIMALSNIFFER-49 required when building with JDK9 [MNG-5925][MNG-5925].
-- Update [animal-sniffer-maven-plugin](https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/) to 1.14. MANIMALSNIFFER-49 required when building with JDK9 [MNG-5925][MNG-5925].
Bugs
----
-- Moving from Maven 3.0.5 to 3.3.3 breaks plugins with some dependencies on the classpath.
+ * Moving from Maven 3.0.5 to 3.3.3 breaks plugins with some dependencies on the classpath.
This has been fixed with [MNG-5787][MNG-5787].
-- The Cygwin Shell related handling of the `MAVEN_PROJECTBASEDIR` has been fixed
+ * The Cygwin Shell related handling of the `MAVEN_PROJECTBASEDIR` has been fixed
with [MNG-5812][MNG-5812].
-- The scripts to call Maven has introduced a bug related to the handling of the
+ * The scripts to call Maven has introduced a bug related to the handling of the
`MAVEN_OPTS` and debugging options which has been fixed by [MNG-5813][MNG-5813].
-- Since Maven 3.3.1 it is possible to have configurations stored on a per project base in the
- `${maven.projectBasedir}/.mvn` directory of the project. There you can use the `maven.config`
+ * Since Maven 3.3.1 it is possible to have configurations stored on a per project base in the
+ `${maven.projectBasedir}/.mvn` directory of the project. There you can use the `maven.config`
file to store command line options instead of repeating them every time you call Maven.
In cases where this file has been empty Maven ended with a failure. This has been fixed
with [MNG-5816][MNG-5816].
-- The handling of the relativePath in a parent has been fixed related to the case
+ * The handling of the relativePath in a parent has been fixed related to the case
that the parent has the same groupId:artifactId but a different version. In this
case the resolution must be done against the repository.
This has been fixed by [MNG-5840][MNG-5840].
-- In cases where you start Maven in the root of a windows drive Maven will fail.
- This has been fixed by [MNG-5796][MNG-5796].
+ * In cases where you start Maven in the root of a windows drive Maven will fail.
+ This has been fixed by [MNG-5796][MNG-5796].
-- The `<prerequisites>` elements is intended for [buildtime checking but not for runtime checks][MNG-4840]
- which should be left to [maven-enforcer-plugin][maven-enforcer-plugin].
+ * The `<prerequisites>` elements is intended for [buildtime checking but not for runtime checks][MNG-4840]
+ which should be left to [maven-enforcer-plugin][maven-enforcer-plugin].
This has not been documented accordingly. This has been done with [MNG-5297][MNG-5297].
-- In situations like this: `mvn -Dtest=\"anton\" clean package` the trailing quote
+ * In situations like this: `mvn -Dtest=\"anton\" clean package` the trailing quote
is stripped away which could cause problems. This has been fixed with [MNG-5681][MNG-5681].
-- Possible NullPointerException in org.apache.maven.repository.MetadataResolutionResult
+ * Possible NullPointerException in org.apache.maven.repository.MetadataResolutionResult
has been fixed with [MNG-5721].
-- There had been several issues with the `mvn` script which are for example
+ * There had been several issues with the `mvn` script which are for example
wrong locating the `.mvn` directory, nonportable shell constructs, wrongly setting
'maven.multiModuleProjectDirectory' variable or directories which contain spaces. Those
- issues have been fixed [MNG-5786][MNG-5786], [MNG-5858][MNG-5858],
+ issues have been fixed [MNG-5786][MNG-5786], [MNG-5858][MNG-5858],
[MNG-5882][MNG-5882] and [MNG-5884][MNG-5884].
-- Broken link of 'Building Maven' in README.md has been fixed by [MNG-5886][MNG-5886].
+ * Broken link of 'Building Maven' in README.md has been fixed by [MNG-5886][MNG-5886].
-- [maven-aether-provider][maven-aether-provider]/[maven-compat][maven-compat]
- does not always generate snapshot versions using Gregorian calendar year
- fixed in [MNG-5877][MNG-5877]
+ * [maven-aether-provider][maven-aether-provider]/[maven-compat][maven-compat]
+ does not always generate snapshot versions using Gregorian calendar year
+ fixed in [MNG-5877][MNG-5877]
-- Log file command line option description contains an extra word has been fixed by [MNG-5891][MNG-5891]
+ * Log file command line option description contains an extra word has been fixed by [MNG-5891][MNG-5891]
-- org.apache.maven.repository.internal.RemoteSnapshotMetadataTest fails to start at midnight fixed with
+ * org.apache.maven.repository.internal.RemoteSnapshotMetadataTest fails to start at midnight fixed with
[MNG-5907][MNG-5907].
-- Multi-module build with ear fails to resolve war in 3.3.3 fixed in [MNG-5898][MNG-5898].
+ * Multi-module build with ear fails to resolve war in 3.3.3 fixed in [MNG-5898][MNG-5898].
+
Task
----
-- Update [Modello site url](https://codehaus-plexus.github.io/modello/) [MNG-5887][MNG-5887].
+ * Update [Modello site url](https://codehaus-plexus.github.io/modello/) [MNG-5887][MNG-5887].
+
The full list of changes can be found in our [issue management system][4].
@@ -176,6 +180,7 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
+[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12333074
[5]: ../../docs/history.html
[maven-enforcer-plugin]: /enforcer/maven-enforcer-plugin/
diff --git a/content/markdown/docs/3.5.0-alpha-1/release-notes.md b/content/markdown/docs/3.5.0-alpha-1/release-notes.md
index 059ee4d8..dd5f4b01 100644
--- a/content/markdown/docs/3.5.0-alpha-1/release-notes.md
+++ b/content/markdown/docs/3.5.0-alpha-1/release-notes.md
@@ -24,7 +24,7 @@ The Apache Maven team would like to announce the release of Maven 3.5.0-alpha-1.
<div class="alert alert-error" role="alert">
<p><b>NOTE:</b></p>
<p>This is an <i>ALPHA</i> release. There is the potential that features may be added/removed between this release and the first GA release in the 3.5.x release line.</p>
-<p><i>Please consult the Known Issues section below before use</i></p>
+<p><i>Please consult the Known Issues section below before use</i></p>
</div>
Maven 3.5.0-alpha-1 is [available for download][0].
@@ -45,8 +45,8 @@ We hope you enjoy using Maven! If you have any questions, please consult:
The following issues were identified during release testing of this _ALPHA_ release but have not been deemed as release blockers:
-- [MNG-6177] The `--file` and `-f` option to specify a `pom.xml` to use does not work if the path includes characters that need quoting such as whitespace or `&`.
-- [MNG-6115] If Maven is installed in a writable location, every build will create a new `lib/ext/jansi-....` file.
+* [MNG-6177] The `--file` and `-f` option to specify a `pom.xml` to use does not work if the path includes characters that need quoting such as whitespace or `&`.
+* [MNG-6115] If Maven is installed in a writable location, every build will create a new `lib/ext/jansi-....` file.
## Why not Maven 3.4.0?
@@ -58,29 +58,29 @@ The migration of the code between the two foundations took longer than expected
In order to refocus on the original intent for 3.4.0, the decision was taken to revert the Maven core history to the point of the 3.3.9 release and merge in the desired changes one at a time.
-Because there had been a lot of communication about different features being delivered and bugs fixed in Maven 3.4.0 and the new history may not contain them in the first release, the decision was taken to forever burn the 3.4.x release line.
+Because there had been a lot of communication about different features being delivered and bugs fixed in Maven 3.4.0 and the new history may not contain them in the first release, the decision was taken to forever burn the 3.4.x release line.
More detail on this decision can be read in the [mailing list archive](http://www.mail-archive.com/dev@maven.apache.org/msg112103.html).
## Reporters and Contributors of this release
-Bugs:
+Bugs:
-- [MNG-5963] reporter: Larry Singer
-- [MNG-5962] reporter/contributor: Miriam Lee
-- [MNG-5961] reporter: Mike Drob
-- [MNG-5958] reporter: Meytal Genah, contributor: Anton Tanasenko
-- [MNG-5852] reporter: Jeffrey Alexander
-- [MNG-5823] reporter: Tobias Oberlies
-- [MNG-5815] reporter: Peter Kjær Guldbæk
-- [MNG-5368] reporter: Andrew Haines
+ * [MNG-5963] reporter: Larry Singer
+ * [MNG-5962] reporter/contributor: Miriam Lee
+ * [MNG-5961] reporter: Mike Drob
+ * [MNG-5958] reporter: Meytal Genah, contributor: Anton Tanasenko
+ * [MNG-5852] reporter: Jeffrey Alexander
+ * [MNG-5823] reporter: Tobias Oberlies
+ * [MNG-5815] reporter: Peter Kjær Guldbæk
+ * [MNG-5368] reporter: Andrew Haines
Improvements:
-- [MNG-6030] reporter: Andriy contributor: Andriy
-- [MNG-5934] reporter/contributor: Alex Henrie
-- [MNG-5883] reporter: Ben Caradoc-Davies
-- [MNG-3507] contributors: Jason Dillon, Sébastian Le Merdy
+ * [MNG-6030] reporter: Andriy contributor: Andriy
+ * [MNG-5934] reporter/contributor: Alex Henrie
+ * [MNG-5883] reporter: Ben Caradoc-Davies
+ * [MNG-3507] contributors: Jason Dillon, Sébastian Le Merdy
Many thanks to all reporters and contributors for their time and support.
@@ -90,45 +90,46 @@ Thank you also for your time and feedback.
## Overview about the changes
-- The most obvious change you may encounter is that the console output
+ * The most obvious change you may encounter is that the console output
has colors now [MNG-3507], [MNG-6093].
-- The new `project.directory` special property adds support in every calculated URLs (project, SCM, site)
+ * The new `project.directory` special property adds support in every calculated URLs (project, SCM, site)
for module directory name that does not match artifactId [MNG-5878]
-
-- The `JAVA_HOME` discovery has been reduced to simply check if `JAVA_HOME` is set
+
+ * The `JAVA_HOME` discovery has been reduced to simply check if `JAVA_HOME` is set
or not then trying to discover via `which java`, nothing more [MNG-6003].
-- The build bootstrapping support via Apache Ant has been removed. You can now only bootstrap Maven
+ * The build bootstrapping support via Apache Ant has been removed. You can now only bootstrap Maven
build with a previous version of Maven, but not with Ant any more [MNG-5904].
-- Based on problems in using `M2_HOME` related to different Maven versions installed and
+ * Based on problems in using `M2_HOME` related to different Maven versions installed and
to simplify things, the usage of `M2_HOME` has been removed and is not
supported any more [MNG-5823], [MNG-5836], [MNG-5607].
-- Important change for windows users: The usage of `%HOME%` has been replaced
+ * Important change for windows users: The usage of `%HOME%` has been replaced
with `%USERPROFILE%` [MNG-6001]
-- Several issues have been reported and fixed related to the `mvn` script either
+ * Several issues have been reported and fixed related to the `mvn` script either
for Unix/Linux/Cygwin/Solaris or for Windows
[MNG-5815], [MNG-5852], [MNG-5963], [MNG-6022].
-- In Maven 3.3.9, we have removed bindings for maven-ejb3-plugin because it
+ * In Maven 3.3.9, we have removed bindings for maven-ejb3-plugin because it
does not exist. We follow-up and removed the artifact handler for `ejb3`
and the `par` lifecycle [MNG-6014], [MNG-6017].
-- In previous Maven versions, there had been a larger problem related to
+ * In previous Maven versions, there had been a larger problem related to
memory usage in case of very large reactors (200-300 modules or more)
which caused failures with out of memeory exceptions or the need to increase
the memory settings. This problem has been fixed with [MNG-6030].
-- If you have defined a property within the `.mvn/maven.config` file,
+ * If you have defined a property within the `.mvn/maven.config` file,
it was not possible to overwrite the property via command line.
This has been fixed with [MNG-6078][MNG-6078].
-- If you have are using `<prerequisites>..</prerequisites>` for a non
+ * If you have are using `<prerequisites>..</prerequisites>` for a non
maven-plugin project, you will get a WARNING which looks like this:
+
```
[INFO] Scanning for projects...
[WARNING] The project org.apache.maven:maven:pom:3.5.0-SNAPSHOT uses prerequisites which is only intended for maven-plugin projects but not for non maven-plugin projects. For such purposes you should use the maven-enforcer-plugin. See https://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html
@@ -138,90 +139,94 @@ Thank you also for your time and feedback.
you are expecting to build your project with, instead of using `prerequisites`
[MNG-5297], [MNG-6092].
-- Replaced Eclipse Aether with [Maven Resolver][maven-resolver]
+ * Replaced Eclipse Aether with [Maven Resolver][maven-resolver]
[MNG-6110], [MNG-6140].
Improvements:
+
Bugs:
-- [MNG-5297] - Site should tell 'prerequisites.maven is deprecated'
-- [MNG-5368] - UnsupportedOperationException thrown when version range is not correct in dependencyManagement definitions
-- [MNG-5629] - ClosedChannelException from DefaultUpdateCheckManager.read
-- [MNG-5815] - "mvn.cmd" does not indicate failure properly when using "&&"
-- [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces - missing quotes
-- [MNG-5829] - mvn shell script fails with syntax error on Solaris 10
-- [MNG-5836] - logging config is overridden by $M2_HOME/lib/ext/*.jar
-- [MNG-5852] - mvn shell script invokes /bin/sh but requires Bash functions
-- [MNG-5958] - java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
-- [MNG-5961] - Maven possibly not aware of log4j2
-- [MNG-5962] - mvn.cmd fails when the current directory has spaces in between
-- [MNG-5963] - mvn.cmd does not return ERROR_CODE
-- [MNG-6022] - mvn.cmd fails if directory contains an ampersand (&)
-- [MNG-6053] - Unsafe System Properties copy in MavenRepositorySystemUtils, causing NPEs
-- [MNG-6105] - properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
-- [MNG-6109] - PluginDescriptor doesn't read since value of parameter
-- [MNG-6117] - ${session.parallel} not correctly set
-- [MNG-6144] - DefaultWagonManagerTest#testGetMissingJarForced() passed incorrect value
-- [MNG-6166] - mvn dependency:go-offline fails due to missing transitive dependency jdom:jdom:jar:1.1
-- [MNG-6171] - REGRESSION: WARNING about usage of a non threadsafe marked plugin is not showed anymore
-- [MNG-6172] - Precedence of command-line system property options has changed
+ * [MNG-5297] - Site should tell 'prerequisites.maven is deprecated'
+ * [MNG-5368] - UnsupportedOperationException thrown when version range is not correct in dependencyManagement definitions
+ * [MNG-5629] - ClosedChannelException from DefaultUpdateCheckManager.read
+ * [MNG-5815] - "mvn.cmd" does not indicate failure properly when using "&&"
+ * [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces - missing quotes
+ * [MNG-5829] - mvn shell script fails with syntax error on Solaris 10
+ * [MNG-5836] - logging config is overridden by $M2_HOME/lib/ext/*.jar
+ * [MNG-5852] - mvn shell script invokes /bin/sh but requires Bash functions
+ * [MNG-5958] - java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
+ * [MNG-5961] - Maven possibly not aware of log4j2
+ * [MNG-5962] - mvn.cmd fails when the current directory has spaces in between
+ * [MNG-5963] - mvn.cmd does not return ERROR_CODE
+ * [MNG-6022] - mvn.cmd fails if directory contains an ampersand (&)
+ * [MNG-6053] - Unsafe System Properties copy in MavenRepositorySystemUtils, causing NPEs
+ * [MNG-6105] - properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
+ * [MNG-6109] - PluginDescriptor doesn't read since value of parameter
+ * [MNG-6117] - ${session.parallel} not correctly set
+ * [MNG-6144] - DefaultWagonManagerTest#testGetMissingJarForced() passed incorrect value
+ * [MNG-6166] - mvn dependency:go-offline fails due to missing transitive dependency jdom:jdom:jar:1.1
+ * [MNG-6171] - REGRESSION: WARNING about usage of a non threadsafe marked plugin is not showed anymore
+ * [MNG-6172] - Precedence of command-line system property options has changed
Dependency upgrade:
-- [MNG-5967] - Dependency updates
-- [MNG-6110] - Upgrade Aether to Maven Resolver
+ * [MNG-5967] - Dependency updates
+ * [MNG-6110] - Upgrade Aether to Maven Resolver
Improvements:
-- [MNG-5579] - Unify error output/check logic from shell and batch scripts
-- [MNG-5607] - Don't use M2_HOME in mvn shell/command scripts anymore
-- [MNG-5883] - Silence unnecessary legacy local repository warning
-- [MNG-5889] - .mvn directory should be picked when using --file
-- [MNG-5904] - Remove the whole Ant build
-- [MNG-5931] - Fixing documentation
-- [MNG-5934] - String handling issues identified by PMD
-- [MNG-5946] - Fix links etc. in README.txt which is part of the delivery
-- [MNG-5968] - Default plugin version updates
-- [MNG-5975] - Use Java 7's SimpleDateFormat in CLIReportingUtils#formatTimestamp
-- [MNG-5977] - Improve output readability of our MavenTransferListener implementations
-- [MNG-5993] - Confusing error message in case of missing/empty artifactId and version in pluginManagement
-- [MNG-6001] - Replace %HOME% with %USERPROFILE% in mvn.cmd
-- [MNG-6003] - Drastically reduce JAVA_HOME discovery code
-- [MNG-6014] - Removing ArtifactHandler for ejb3
-- [MNG-6017] - Removing ArtifactHandler for par LifeCycle
-- [MNG-6030] - ReactorModelCache do not used effectively after maven version 3.0.5 which cause a large memory footprint
-- [MNG-6032] - WARNING during build based on absolute path in assembly-descriptor.
-- [MNG-6068] - Document default scope compile in pom XSD and reference documentation
-- [MNG-6078] - Can't overwrite properties which have been defined in .mvn/maven.config
-- [MNG-6081] - Log refactoring - Method Invocation Replaced By Variable
-- [MNG-6102] - Introduce ${maven.conf} in m2.conf
-- [MNG-6145] - Remove non-existent m2 include in component.xml
-- [MNG-6146] - Several small stylistic and spelling improvements to code and documentation
-- [MNG-6147] - MetadataResolutionResult#getGraph() contains duplicate if clause
-- [MNG-6150] - Javadoc improvements for 3.5.0
-- [MNG-6163] - Introduce CLASSWORLDS_JAR in shell startup scripts
-- [MNG-6165] - Deprecate and replace incorrectly spelled public API
+ * [MNG-5579] - Unify error output/check logic from shell and batch scripts
+ * [MNG-5607] - Don't use M2_HOME in mvn shell/command scripts anymore
+ * [MNG-5883] - Silence unnecessary legacy local repository warning
+ * [MNG-5889] - .mvn directory should be picked when using --file
+ * [MNG-5904] - Remove the whole Ant build
+ * [MNG-5931] - Fixing documentation
+ * [MNG-5934] - String handling issues identified by PMD
+ * [MNG-5946] - Fix links etc. in README.txt which is part of the delivery
+ * [MNG-5968] - Default plugin version updates
+ * [MNG-5975] - Use Java 7's SimpleDateFormat in CLIReportingUtils#formatTimestamp
+ * [MNG-5977] - Improve output readability of our MavenTransferListener implementations
+ * [MNG-5993] - Confusing error message in case of missing/empty artifactId and version in pluginManagement
+ * [MNG-6001] - Replace %HOME% with %USERPROFILE% in mvn.cmd
+ * [MNG-6003] - Drastically reduce JAVA_HOME discovery code
+ * [MNG-6014] - Removing ArtifactHandler for ejb3
+ * [MNG-6017] - Removing ArtifactHandler for par LifeCycle
+ * [MNG-6030] - ReactorModelCache do not used effectively after maven version 3.0.5 which cause a large memory footprint
+ * [MNG-6032] - WARNING during build based on absolute path in assembly-descriptor.
+ * [MNG-6068] - Document default scope compile in pom XSD and reference documentation
+ * [MNG-6078] - Can't overwrite properties which have been defined in .mvn/maven.config
+ * [MNG-6081] - Log refactoring - Method Invocation Replaced By Variable
+ * [MNG-6102] - Introduce ${maven.conf} in m2.conf
+ * [MNG-6145] - Remove non-existent m2 include in component.xml
+ * [MNG-6146] - Several small stylistic and spelling improvements to code and documentation
+ * [MNG-6147] - MetadataResolutionResult#getGraph() contains duplicate if clause
+ * [MNG-6150] - Javadoc improvements for 3.5.0
+ * [MNG-6163] - Introduce CLASSWORLDS_JAR in shell startup scripts
+ * [MNG-6165] - Deprecate and replace incorrectly spelled public API
New Feature:
-- [MNG-3507] - ANSI color logging for improved output visibility
-- [MNG-5878] - add support for module name != artifactId in every calculated URLs (project, SCM, site): special project.directory property
-- [MNG-6093] - create a slf4j-simple provider extension that supports level color rendering Task
-- [MNG-5954] - Remove outdated maven-embedder/src/main/resources/META-INF/MANIFEST.MF
-- [MNG-6106] - Remove maven.home default value setter from m2.conf
-- [MNG-6136] - Upgrade Maven Wagon from 2.10 to 2.12
-- [MNG-6137] - Clean up duplicate dependencies caused by incomplete Wagon HTTP Provider exclusions
-- [MNG-6138] - Remove obsolete message_*.properties form maven-core
-- [MNG-6140] - update documentation's dependency graph with resolver + resolver-provider + slf4j-provider
-- [MNG-6151] - Force Push master from 737de43e392fc15a0ce366db98d70aa18b3f6c03
-- [MNG-6152] - Add a Jenkinsfile so that builds.apache.org can use multibranch pipeline
+ * [MNG-3507] - ANSI color logging for improved output visibility
+ * [MNG-5878] - add support for module name != artifactId in every calculated URLs (project, SCM, site): special project.directory property
+ * [MNG-6093] - create a slf4j-simple provider extension that supports level color rendering Task
+ * [MNG-5954] - Remove outdated maven-embedder/src/main/resources/META-INF/MANIFEST.MF
+ * [MNG-6106] - Remove maven.home default value setter from m2.conf
+ * [MNG-6136] - Upgrade Maven Wagon from 2.10 to 2.12
+ * [MNG-6137] - Clean up duplicate dependencies caused by incomplete Wagon HTTP Provider exclusions
+ * [MNG-6138] - Remove obsolete message_*.properties form maven-core
+ * [MNG-6140] - update documentation's dependency graph with resolver + resolver-provider + slf4j-provider
+ * [MNG-6151] - Force Push master from 737de43e392fc15a0ce366db98d70aa18b3f6c03
+ * [MNG-6152] - Add a Jenkinsfile so that builds.apache.org can use multibranch pipeline
Wishes:
-- [MNG-2199] - Support version ranges in parent elements
-- [MNG-6088] - after forked execution success, add an empty line
-- [MNG-6092] - warn if prerequisites.maven is used for non-plugin projects
+ * [MNG-2199] - Support version ranges in parent elements
+ * [MNG-6088] - after forked execution success, add an empty line
+ * [MNG-6092] - warn if prerequisites.maven is used for non-plugin projects
+
+
+
The full list of changes can be found in our [issue management system][4].
@@ -231,8 +236,13 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
+[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12339664&styleName=Text
[5]: ../../docs/history.html
+[maven-enforcer-plugin]: /enforcer/maven-enforcer-plugin/
+[maven-resources-plugin]: /enforcer/maven-resources-plugin/
+[maven-aether-provider]: /ref/3.5.0-alpha-1/maven-aether-provider/
+[maven-compat]: /ref/3.5.0-alpha-1/maven-compat/
[maven-resolver]: /resolver/
[MNG-2199]: https://issues.apache.org/jira/browse/MNG-2199
diff --git a/content/markdown/docs/3.5.0-beta-1/release-notes.md b/content/markdown/docs/3.5.0-beta-1/release-notes.md
index 95954465..5ad1b536 100644
--- a/content/markdown/docs/3.5.0-beta-1/release-notes.md
+++ b/content/markdown/docs/3.5.0-beta-1/release-notes.md
@@ -45,9 +45,10 @@ We hope you enjoy using Maven! If you have any questions, please consult:
The following issues were identified during release testing of this _BETA_ release but have not been deemed as release blockers:
-- [MNG-6190] maven-resolver-provider's `DefaultArtifactDescriptorReader` has mismatched constructor and initService methods (this issue does not affect normal usage of Maven)
-- [MNG-6191] `mvn -f` complains about illegal `readlink` option under macOS
-- [MNG-6192] The distribution zip file has unordered entries and some tools - most notably Maven wrapper - will fail to unzip the distribution
+* [MNG-6190] maven-resolver-provider's `DefaultArtifactDescriptorReader` has mismatched constructor and initService methods (this issue does not affect normal usage of Maven)
+* [MNG-6191] `mvn -f` complains about illegal `readlink` option under macOS
+* [MNG-6192] The distribution zip file has unordered entries and some tools - most notably Maven wrapper - will fail to unzip the distribution
+
## Why not Maven 3.4.0?
@@ -67,8 +68,8 @@ More detail on this decision can be read in the [mailing list archive](http://ww
Bugs:
-- [MNG-6090] reporter: Harald Wellmann
-- [MNG-6173] reporter/contributor: Christoph Böhme
+ * [MNG-6090] reporter: Harald Wellmann
+ * [MNG-6173] reporter/contributor: Christoph Böhme
Many thanks to all reporters and contributors for their time and support.
@@ -78,43 +79,43 @@ Thank you also for your time and feedback.
## Overview about the changes
-- The most obvious change you may encounter is that the console output
+ * The most obvious change you may encounter is that the console output
has colors now [MNG-3507], [MNG-6093].
-- The new `project.directory` special property adds support in every calculated URLs (project, SCM, site)
+ * The new `project.directory` special property adds support in every calculated URLs (project, SCM, site)
for module directory name that does not match artifactId [MNG-5878]
-- The `JAVA_HOME` discovery has been reduced to simply check if `JAVA_HOME` is set
+ * The `JAVA_HOME` discovery has been reduced to simply check if `JAVA_HOME` is set
or not then trying to discover via `which java`, nothing more [MNG-6003].
-- The build bootstrapping support via Apache Ant has been removed. You can now only bootstrap Maven
+ * The build bootstrapping support via Apache Ant has been removed. You can now only bootstrap Maven
build with a previous version of Maven, but not with Ant any more [MNG-5904].
-- Based on problems in using `M2_HOME` related to different Maven versions installed and
+ * Based on problems in using `M2_HOME` related to different Maven versions installed and
to simplify things, the usage of `M2_HOME` has been removed and is not
supported any more [MNG-5823], [MNG-5836], [MNG-5607].
-- Important change for windows users: The usage of `%HOME%` has been replaced
+ * Important change for windows users: The usage of `%HOME%` has been replaced
with `%USERPROFILE%` [MNG-6001]
-- Several issues have been reported and fixed related to the `mvn` script either
+ * Several issues have been reported and fixed related to the `mvn` script either
for Unix/Linux/Cygwin/Solaris or for Windows
[MNG-5815], [MNG-5852], [MNG-5963], [MNG-6022].
-- In Maven 3.3.9, we have removed bindings for maven-ejb3-plugin because it
+ * In Maven 3.3.9, we have removed bindings for maven-ejb3-plugin because it
does not exist. We follow-up and removed the artifact handler for `ejb3`
and the `par` lifecycle [MNG-6014], [MNG-6017].
-- In previous Maven versions, there had been a larger problem related to
+ * In previous Maven versions, there had been a larger problem related to
memory usage in case of very large reactors (200-300 modules or more)
which caused failures with out of memory exceptions or the need to increase
the memory settings. This problem has been fixed with [MNG-6030].
-- If you have defined a property within the `.mvn/maven.config` file,
+ * If you have defined a property within the `.mvn/maven.config` file,
it was not possible to overwrite the property via command line.
This has been fixed with [MNG-6078][MNG-6078].
-- If you have are using `<prerequisites>..</prerequisites>` for a non
+ * If you have are using `<prerequisites>..</prerequisites>` for a non
maven-plugin project, you will get a WARNING which looks like this:
```
@@ -126,42 +127,42 @@ Thank you also for your time and feedback.
you are expecting to build your project with, instead of using `prerequisites`
[MNG-5297], [MNG-6092].
-- Replaced Eclipse Aether with [Maven Resolver][maven-resolver]
+ * Replaced Eclipse Aether with [Maven Resolver][maven-resolver]
[MNG-6110], [MNG-6140].
-- Using of CI friendly versions via `${revision}`, `${sha1}` and/or `${changelist}`
+ * Using of CI friendly versions via `${revision}`, `${sha1}` and/or `${changelist}`
has been fixed [MNG-6057], [MNG-6090] and [MNG-5895]. It is very important to
know if you are using the previously named properties for a version in your
pom you have to use [flatten-maven-plugin] if you like to do an `mvn install`
or `mvn deploy` more details can be found at [Maven CI Friendly](/maven-ci-friendly.html).
-- The two known issues from 3.5.0-alpha-1 have been fixed [MNG-6177], [MNG-6115]
+ * The two known issues from 3.5.0-alpha-1 have been fixed [MNG-6177], [MNG-6115]
Improvements:
Bugs:
-- [MNG-5895] - Problem with CI friendly usage of ${..} which is already defined via property in pom file.
-- [MNG-6057] - Problem with CI friendly usage of ${..} reactor order is changed
-- [MNG-6090] - CI friendly properties break submodule builds
-- [MNG-6170] - NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
-- [MNG-6173] - MavenSession.getAllProjects() should return all projects in the reactor
-- [MNG-6176] - Javadoc errors prevent release with Java 8
-- [MNG-6177] - The --file command line option of the Windows and Unix launchers does not work for directory names like "Spaces & Special Char"
-- [MNG-6180] - groupId has plain color when goal fails
-- [MNG-6181] - HttpClient produces a lot of noise at debug loglevel
-- [MNG-6183] - Dependency management debug message corrections.
+* [MNG-5895] - Problem with CI friendly usage of ${..} which is already defined via property in pom file.
+* [MNG-6057] - Problem with CI friendly usage of ${..} reactor order is changed
+* [MNG-6090] - CI friendly properties break submodule builds
+* [MNG-6170] - NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
+* [MNG-6173] - MavenSession.getAllProjects() should return all projects in the reactor
+* [MNG-6176] - Javadoc errors prevent release with Java 8
+* [MNG-6177] - The --file command line option of the Windows and Unix launchers does not work for directory names like "Spaces & Special Char"
+* [MNG-6180] - groupId has plain color when goal fails
+* [MNG-6181] - HttpClient produces a lot of noise at debug loglevel
+* [MNG-6183] - Dependency management debug message corrections.
Improvements:
-- [MNG-6078] - Can't overwrite properties which have been defined in .mvn/maven.config
-- [MNG-6115] - Add Jansi native library search path to our start scripts to avoid extraction to temp file on each run
-- [MNG-6179] - Remove unused prerequisites
-- [MNG-6189] - WARN if maven-site-plugin configuration contains reportPlugins element
+* [MNG-6078] - Can't overwrite properties which have been defined in .mvn/maven.config
+* [MNG-6115] - Add Jansi native library search path to our start scripts to avoid extraction to temp file on each run
+* [MNG-6179] - Remove unused prerequisites
+* [MNG-6189] - WARN if maven-site-plugin configuration contains reportPlugins element
New Feature:
-- [MNG-6182] - ModelResolver interface enhancement: addition of resolveModel( Dependency ) supporting version ranges
+* [MNG-6182] - ModelResolver interface enhancement: addition of resolveModel( Dependency ) supporting version ranges
The full list of changes can be found in our [issue management system][4].
@@ -171,8 +172,13 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
+[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12339664&styleName=Text
[5]: ../../docs/history.html
+[maven-enforcer-plugin]: /enforcer/maven-enforcer-plugin/
+[maven-resources-plugin]: /enforcer/maven-resources-plugin/
+[maven-aether-provider]: /ref/3.5.0-alpha-1/maven-aether-provider/
+[maven-compat]: /ref/3.5.0-alpha-1/maven-compat/
[maven-resolver]: /resolver/
[MNG-3507]: https://issues.apache.org/jira/browse/MNG-3507
diff --git a/content/markdown/docs/3.5.0/release-notes.md b/content/markdown/docs/3.5.0/release-notes.md
index 4fbf31e6..93e72f20 100644
--- a/content/markdown/docs/3.5.0/release-notes.md
+++ b/content/markdown/docs/3.5.0/release-notes.md
@@ -75,16 +75,16 @@ Many thanks to all reporters and contributors for their time and support.
The following members of the Maven community provided valuable feedback during the release process:
-- Grzegorz Grzybek
-- Petr Široký
-- Mark Derricutt,
-- Dejan Stojadinović
-- Thomas Collignon
-- Fred Cooke
-- Raphael Ackermann
-- Elliot Metsger
-- Chas Honton
-- Dennis Kieselhorst
+* Grzegorz Grzybek
+* Petr Široký
+* Mark Derricutt,
+* Dejan Stojadinović
+* Thomas Collignon
+* Fred Cooke
+* Raphael Ackermann
+* Elliot Metsger
+* Chas Honton
+* Dennis Kieselhorst
Thank you for your time and feedback.
@@ -242,8 +242,11 @@ See [complete release notes for all versions][7]
[6]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12336084&styleName=Text
[7]: ../../docs/history.html
[flatten-maven-plugin]: https://www.mojohaus.org/flatten-maven-plugin/
+[maven-aether-provider]: /ref/3.5.0/maven-aether-provider/
+[maven-compat]: /ref/3.5.0/maven-compat/
[maven-enforcer-plugin]: /enforcer/maven-enforcer-plugin/
[maven-resolver]: /resolver/
+[MNG-2199]: https://issues.apache.org/jira/browse/MNG-2199
[MNG-3507]: https://issues.apache.org/jira/browse/MNG-3507
[MNG-5297]: https://issues.apache.org/jira/browse/MNG-5297
[MNG-5368]: https://issues.apache.org/jira/browse/MNG-5368
@@ -263,6 +266,7 @@ See [complete release notes for all versions][7]
[MNG-5931]: https://issues.apache.org/jira/browse/MNG-5931
[MNG-5934]: https://issues.apache.org/jira/browse/MNG-5934
[MNG-5946]: https://issues.apache.org/jira/browse/MNG-5946
+[MNG-5954]: https://issues.apache.org/jira/browse/MNG-5954
[MNG-5958]: https://issues.apache.org/jira/browse/MNG-5958
[MNG-5961]: https://issues.apache.org/jira/browse/MNG-5961
[MNG-5962]: https://issues.apache.org/jira/browse/MNG-5962
@@ -279,24 +283,35 @@ See [complete release notes for all versions][7]
[MNG-6022]: https://issues.apache.org/jira/browse/MNG-6022
[MNG-6030]: https://issues.apache.org/jira/browse/MNG-6030
[MNG-6032]: https://issues.apache.org/jira/browse/MNG-6032
+[MNG-6053]: https://issues.apache.org/jira/browse/MNG-6053
[MNG-6057]: https://issues.apache.org/jira/browse/MNG-6057
[MNG-6068]: https://issues.apache.org/jira/browse/MNG-6068
[MNG-6078]: https://issues.apache.org/jira/browse/MNG-6078
[MNG-6081]: https://issues.apache.org/jira/browse/MNG-6081
+[MNG-6088]: https://issues.apache.org/jira/browse/MNG-6088
[MNG-6090]: https://issues.apache.org/jira/browse/MNG-6090
[MNG-6092]: https://issues.apache.org/jira/browse/MNG-6092
[MNG-6093]: https://issues.apache.org/jira/browse/MNG-6093
[MNG-6102]: https://issues.apache.org/jira/browse/MNG-6102
[MNG-6105]: https://issues.apache.org/jira/browse/MNG-6105
+[MNG-6106]: https://issues.apache.org/jira/browse/MNG-6106
[MNG-6109]: https://issues.apache.org/jira/browse/MNG-6109
[MNG-6110]: https://issues.apache.org/jira/browse/MNG-6110
[MNG-6115]: https://issues.apache.org/jira/browse/MNG-6115
[MNG-6117]: https://issues.apache.org/jira/browse/MNG-6117
+[MNG-6136]: https://issues.apache.org/jira/browse/MNG-6136
+[MNG-6137]: https://issues.apache.org/jira/browse/MNG-6137
+[MNG-6138]: https://issues.apache.org/jira/browse/MNG-6138
[MNG-6140]: https://issues.apache.org/jira/browse/MNG-6140
[MNG-6144]: https://issues.apache.org/jira/browse/MNG-6144
[MNG-6145]: https://issues.apache.org/jira/browse/MNG-6145
[MNG-6146]: https://issues.apache.org/jira/browse/MNG-6146
[MNG-6147]: https://issues.apache.org/jira/browse/MNG-6147
+[MNG-6150]: https://issues.apache.org/jira/browse/MNG-6150
+[MNG-6151]: https://issues.apache.org/jira/browse/MNG-6151
+[MNG-6152]: https://issues.apache.org/jira/browse/MNG-6152
+[MNG-6163]: https://issues.apache.org/jira/browse/MNG-6163
+[MNG-6165]: https://issues.apache.org/jira/browse/MNG-6165
[MNG-6166]: https://issues.apache.org/jira/browse/MNG-6166
[MNG-6168]: https://issues.apache.org/jira/browse/MNG-6168
[MNG-6170]: https://issues.apache.org/jira/browse/MNG-6170
@@ -305,9 +320,13 @@ See [complete release notes for all versions][7]
[MNG-6173]: https://issues.apache.org/jira/browse/MNG-6173
[MNG-6176]: https://issues.apache.org/jira/browse/MNG-6176
[MNG-6177]: https://issues.apache.org/jira/browse/MNG-6177
+[MNG-6179]: https://issues.apache.org/jira/browse/MNG-6179
[MNG-6180]: https://issues.apache.org/jira/browse/MNG-6180
[MNG-6181]: https://issues.apache.org/jira/browse/MNG-6181
+[MNG-6182]: https://issues.apache.org/jira/browse/MNG-6182
[MNG-6183]: https://issues.apache.org/jira/browse/MNG-6183
+[MNG-6185]: https://issues.apache.org/jira/browse/MNG-6185
+[MNG-6189]: https://issues.apache.org/jira/browse/MNG-6189
[MNG-6190]: https://issues.apache.org/jira/browse/MNG-6190
[MNG-6191]: https://issues.apache.org/jira/browse/MNG-6191
[MNG-6192]: https://issues.apache.org/jira/browse/MNG-6192
diff --git a/content/markdown/docs/3.5.2/release-notes.md b/content/markdown/docs/3.5.2/release-notes.md
index 911923cf..11632a81 100644
--- a/content/markdown/docs/3.5.2/release-notes.md
+++ b/content/markdown/docs/3.5.2/release-notes.md
@@ -37,19 +37,19 @@ We hope you enjoy using Maven! If you have any questions, please consult:
Bugs:
-- Marcel Schutte (reporter)
-- Mario Krizmanic (reporter, contributor)
-- Charles Gould (reporter)
-- Brian Oxley (reporter)
-- Dejan Stojadinovic (contributor)
+* Marcel Schutte (reporter)
+* Mario Krizmanic (reporter, contributor)
+* Charles Gould (reporter)
+* Brian Oxley (reporter)
+* Dejan Stojadinovic (contributor)
Improvements:
-- Anton Tanasenko (reporter, contributor)
-- Gregor B. Rosenauer (reporter)
-- Sylwester Lachiewicz (reporter)
-- Stefan Eicher (reporter, contributor)
-- Manuel Ryan (reporter)
+* Anton Tanasenko (reporter, contributor)
+* Gregor B. Rosenauer (reporter)
+* Sylwester Lachiewicz (reporter)
+* Stefan Eicher (reporter, contributor)
+* Manuel Ryan (reporter)
Many thanks to all reporters and contributors and for their time and support.
@@ -57,13 +57,13 @@ Many thanks to all reporters and contributors and for their time and support.
The following members of the Maven community provided valuable feedback during the release process:
-- Mark Derricutt
-- Dejan Stojadinovic
-- Thomas Collignon
-- Grzegorz Grzybek
-- Petar Tahchiev
-- jieryn
-- Petr Široký
+* Mark Derricutt
+* Dejan Stojadinovic
+* Thomas Collignon
+* Grzegorz Grzybek
+* Petar Tahchiev
+* jieryn
+* Petr Široký
Thank you for your time and feedback.
@@ -86,12 +86,10 @@ The full list of changes as well as detailed descriptions of same can be found i
- [MNG-6242][] - No color for maven on Cygwin
### Sub-tasks
-
- [MNG-6186][] - switch to improved HawtJNI
- [MNG-6280][] - ArrayIndexOutOfBoundsException caused by pom.xml with process instructions
### Improvements
-
- [MNG-5457][] - Show repository id when downloading or uploading from/to a remote repository
- [MNG-6025][] - Add a ProjectArtifactsCache similar to PluginArtifactsCache
- [MNG-6123][] - detect self references in POM and fail fast
@@ -103,12 +101,10 @@ The full list of changes as well as detailed descriptions of same can be found i
- [MNG-6228][] - Optionality not displayed in dependency tree when run in debug mode
### New Features
-
- [MNG-6084][] - Support JSR 250 annotations
- [MNG-6220][] - Add CLI options to control color output
### Tasks
-
- [MNG-6167][] - Clean up dependency mess (reported by dependency:analyze)
- [MNG-6258][] - Upgrade to Maven Resolver 1.1.0
diff --git a/content/markdown/docs/3.5.3/release-notes.md b/content/markdown/docs/3.5.3/release-notes.md
index 51b735f6..45275985 100644
--- a/content/markdown/docs/3.5.3/release-notes.md
+++ b/content/markdown/docs/3.5.3/release-notes.md
@@ -179,6 +179,7 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
[2]: https://maven.apache.org/
+[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12341428
[5]: ../../docs/history.html
[MNG-5992]: https://issues.apache.org/jira/browse/MNG-5992
[MNG-6188]: https://issues.apache.org/jira/browse/MNG-6188
diff --git a/content/markdown/docs/3.5.4/release-notes.md b/content/markdown/docs/3.5.4/release-notes.md
index e0d53219..5b2fbf90 100644
--- a/content/markdown/docs/3.5.4/release-notes.md
+++ b/content/markdown/docs/3.5.4/release-notes.md
@@ -39,7 +39,7 @@ We really value the contributions of these non committers, so this section is fo
Bugs:
-- [MNG-6370][] reporter and contributor: Sylwester Lachiewicz
+- [MNG-6370][] reporter and contributor: Sylwester Lachiewicz
- [MNG-6382][] reporter: Falko Modler
- [MNG-6388][] reporter: Mike Kelly
- [MNG-6410][] reporter and contributor: Łukasz Dywicki
@@ -75,7 +75,6 @@ There are some additional minor improvements, the most notable of which is:
## [The detailed issue list](#details)
### Bugs
-
- [MNG-6370][] `ConcurrencyDependencyGraph#getNumberOfBuilds()` does not remove finished projects from unfinished ones
- [MNG-6372][] On Windows Maven can output spurious ANSI escapes such as `[0m [0m`
- [MNG-6382][] JANSI fails frequently with `NumberFormatException` when building in parallel
@@ -85,7 +84,6 @@ There are some additional minor improvements, the most notable of which is:
- [MNG-6410][] Add `groupId` to `--resume-from` suggestion if `artifactId` is not unique in reactor
### Improvements
-
- [MNG-5756][] Java home output in `mvn -v` is misleading
- [MNG-5940][] Change the `maven-source-plugin` `jar` goal into `jar-no-fork` in Maven Super POM
- [MNG-6362][] Add documentation information for GitHub
@@ -94,11 +92,9 @@ There are some additional minor improvements, the most notable of which is:
- [MNG-6411][] Improve readability of project list returned when `--resume-from` option value is invalid
### Tasks
-
- [MNG-6377][] switch from Git-WIP to Gitbox
### Dependency upgrades
-
- [MNG-6344][] Upgrade Guice to 4.2.0
- [MNG-6423][] Upgrade to Wagon 3.1.0
diff --git a/content/markdown/docs/3.6.0/release-notes.md b/content/markdown/docs/3.6.0/release-notes.md
index 3e5437b7..a9d034cd 100644
--- a/content/markdown/docs/3.6.0/release-notes.md
+++ b/content/markdown/docs/3.6.0/release-notes.md
@@ -41,22 +41,22 @@ the [end of these release notes](#details).
Code Contributors of this release:
-- [MNG-6383] Christoph Kunze
-- [MNG-6311] David Churcher
+ * [MNG-6383] Christoph Kunze
+ * [MNG-6311] David Churcher
Issue Reporters of this release:
-- [MNG-4508] Richard van der Hoff
-- [MNG-5951] Jörg Sesterhenn
-- [MNG-6311] David Churcher
-- [MNG-6358] Adam John Burley
-- [MNG-6383] Christoph Kunze
-- [MNG-6391] Alexander Griesbaum
-- [MNG-6412] Christoph Amshoff
-- [MNG-6415] Seckin Onur Selamet
-- [MNG-6475] Phillip Webb
-- [MNG-6490] John Canny
-- [MNG-6492] Hoa Phan
+ * [MNG-4508] Richard van der Hoff
+ * [MNG-5951] Jörg Sesterhenn
+ * [MNG-6311] David Churcher
+ * [MNG-6358] Adam John Burley
+ * [MNG-6383] Christoph Kunze
+ * [MNG-6391] Alexander Griesbaum
+ * [MNG-6412] Christoph Amshoff
+ * [MNG-6415] Seckin Onur Selamet
+ * [MNG-6475] Phillip Webb
+ * [MNG-6490] John Canny
+ * [MNG-6492] Hoa Phan
Many thanks to all reporters and contributors for their time and support.
@@ -64,7 +64,7 @@ Many thanks to all reporters and contributors for their time and support.
Thanks to the following preliminary testers:
-- Filipe Sousa
+- Filipe Sousa
- Eric Lilja
- Enrico Olivelli
- Gary Gregory
@@ -80,7 +80,7 @@ At the time of release, there are no known regressions introduced by this releas
been increased in previous version which influenced some of our users.
This should have been fixed [MNG-6311], [MNG-6383] and [MNG-6412].
-- The output in the reactor summary has been improved [MNG-6391]
+- The output in the reactor summary has been improved [MNG-6391]
cause it confused people. In Maven 3.6.0 the reactor summary now
looks like the following:
@@ -105,13 +105,12 @@ At the time of release, there are no known regressions introduced by this releas
[INFO] ------------------------------------------------------------------------
```
- The `parent` in the above output is the artifact name of the root module and
+ The `parent` in the above output is the artifact name of the root module and
the `5.0.4-SNAPSHOT` is the versions number for all modules in this
reactor build.
If you have an aggregator pom which contains different modules with different
versions each line will contain the appropriate versions which looks like this:
-
```
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
@@ -129,12 +128,12 @@ At the time of release, there are no known regressions introduced by this releas
...
```
-- There was an issue related to the classpath ordering [MNG-6415] in Maven which
+- There was an issue related to the classpath ordering [MNG-6415] in Maven which
can cause issues which has been fixed.
## [The detailed issue list](#details)
-### Bugs
+### Bugs:
- [MNG-6311] - Maven intolerably slow when import scope used heavily in large project
- [MNG-6358] - Maven build should not require access to apache.org
@@ -144,7 +143,7 @@ At the time of release, there are no known regressions introduced by this releas
- [MNG-6472] - Mockito cannot mock this class: interface org.eclipse.aether.impl.RepositoryEventDispatcher
- [MNG-6490] - Maven shall not fail reporting circular dependency when the dependency is a classified secondary artifact
-### Improvements
+### Improvements:
- [MNG-4508] - No way to avoid adding artifactId to site urls
- [MNG-5951] - add an option to avoid path addition to inherited URLs
diff --git a/content/markdown/docs/3.6.1/release-notes.md b/content/markdown/docs/3.6.1/release-notes.md
index f7bce3be..7d32def7 100644
--- a/content/markdown/docs/3.6.1/release-notes.md
+++ b/content/markdown/docs/3.6.1/release-notes.md
@@ -41,37 +41,38 @@ the [end of these release notes](#details).
Issue Reporters of this release:
-- [MNG-5705] Ondra Žižka
-- [MNG-5965] Matthias Schmalz
-- [MNG-6059] Andreas Sewe
-- [MNG-6159] Christian Aistleitner
-- [MNG-6213] Jin Kwon
-- [MNG-6256] Christoph Etzel
-- [MNG-6261] Dawid Weiss
-- [MNG-6262] Gene Smith
-- [MNG-6346] Patrik Jetzer
-- [MNG-6374] Rohan Padhye
-- [MNG-6495] Elliotte Rusty Harold
-- [MNG-6506] Andreas Veithen
-- [MNG-6526] Olaf Otto
-- [MNG-6529] Michael Istria
-- [MNG-6530] Michael Istria
-- [MNG-6533] Michael Istria
-- [MNG-6543] Romain Manni-Bucau
-- [MNG-6558] Guy Brand
-- [MNG-6577] Rohan Padhye
-- [MNG-6591] Olaf Otto
-- [MNG-6605] Gunnar Wagenknecht
-- [MNG-6618] Viacheslav Yakunin
+ * [MNG-5705] Ondra Žižka
+ * [MNG-5965] Matthias Schmalz
+ * [MNG-6059] Andreas Sewe
+ * [MNG-6159] Christian Aistleitner
+ * [MNG-6213] Jin Kwon
+ * [MNG-6256] Christoph Etzel
+ * [MNG-6261] Dawid Weiss
+ * [MNG-6262] Gene Smith
+ * [MNG-6346] Patrik Jetzer
+ * [MNG-6374] Rohan Padhye
+ * [MNG-6495] Elliotte Rusty Harold
+ * [MNG-6506] Andreas Veithen
+ * [MNG-6526] Olaf Otto
+ * [MNG-6529] Michael Istria
+ * [MNG-6530] Michael Istria
+ * [MNG-6533] Michael Istria
+ * [MNG-6543] Romain Manni-Bucau
+ * [MNG-6558] Guy Brand
+ * [MNG-6577] Rohan Padhye
+ * [MNG-6591] Olaf Otto
+ * [MNG-6605] Gunnar Wagenknecht
+ * [MNG-6618] Viacheslav Yakunin
Code Contributors of this release:
-- [MNG-6374] Gabriel Belingueres (indirectly via plexus-utils PR)
-- [MNG-6529] Michael Istria
-- [MNG-6530] Michael Istria
-- [MNG-6558] Guy Brand
-- [MNG-6261] Fabiano C. de Oliveira
-- [MNG-6533] Michael Istria
+ * [MNG-6374] Gabriel Belingueres (indirectly via plexus-utils PR)
+ * [MNG-6529] Michael Istria
+ * [MNG-6530] Michael Istria
+ * [MNG-6558] Guy Brand
+ * [MNG-6261] Fabiano C. de Oliveira
+ * [MNG-6533] Michael Istria
+
Many thanks to all reporters and contributors for their time and support.
@@ -81,16 +82,16 @@ Many thanks to all reporters and contributors for their time and support.
Thanks to the following preliminary testers:
-- Gabriel Belingueres
-- Francois Papon
-- Eric Lilja
+ * Gabriel Belingueres
+ * Francois Papon
+ * Eric Lilja
## Known Issues
-- New attributes for URLs inheritance (see [User Visible Changes](./release-notes.html#User_visible_Changes)) are not yet
+ * New attributes for URLs inheritance (see [User Visible Changes](./release-notes.html#User_visible_Changes)) are not yet
accepted during POM structure control on [upload to the Central Repository](/repository/guide-central-repository-upload.html):
see [MVNCENTRAL-4841](https://issues.sonatype.org/browse/MVNCENTRAL-4841) to track progress
-- If you are using Maven reporting, it might happen that you will get an exception which looks like this:
+ * If you are using Maven reporting, it might happen that you will get an exception which looks like this:
```
[INFO] Scanning for projects...
@@ -103,7 +104,7 @@ Caused by: java.lang.NullPointerException
...
```
-This is caused by using a `<reportSet>..</reportSet>` which does not contain
+This is caused by using a `<reportSet>..</reportSet>` which does not contain
a `<report></report>` element.
Temporarily this issue can circumvented by adding an empty `<report></report>` element
@@ -120,17 +121,18 @@ inside the `<reportSet></reportSet>`.
executions of phases. This has been fixed with [MNG-5965].
- NullPointerException related to call in parallel build like `mvn -T 1C clean javadoc:aggregate`
- [MNG-5705]
+ [MNG-5705]
-- A performance issue related to artifact transfer has been found related to [WAGON-537]. It
+- A performance issue related to artifact transfer has been found related to [WAGON-537]. It
has been solved via the update to [Maven Wagon 3.3.1][MNG-6526].
- There had been issues related calling Maven script like this: `mvn -f ..`
- - Having parentheses within the path, which has been fixed with [MNG-6346].
- - Script can break having special characters as part of the path, which has
+ - Having parentheses within the path, which has been fixed with [MNG-6346].
+ - Script can break having special characters as part of the path, which has
been solved with [MNG-6256].
-- Issue related to the Maven Resolver API which broke some IDEs (for example <https://youtrack.jetbrains.com/issue/IDEA-201282>);
+
+- Issue related to the Maven Resolver API which broke some IDEs (for example https://youtrack.jetbrains.com/issue/IDEA-201282);
this has been fixed by [MNG-6538].
- Issue related to missing event for ToolchainsBuildingResult on EventSpy [MNG-6558].
@@ -145,22 +147,22 @@ inside the `<reportSet></reportSet>`.
- Missing export for org.slf4j.event.Level has been done with [MNG-6618]
+
## User visible Changes
-- Maven has now a an option to suppress the transfer progress when downloading/uploading
+ - Maven has now a an option to suppress the transfer progress when downloading/uploading
in interactive mode.
```
mvn --no-transfer-progress ....
```
-
or in short:
```
mvn -ntp ... ....
```
-- There had been an issues like [MNG-6505] and [MNG-6059] related to the construction of
+ - There had been an issues like [MNG-6505] and [MNG-6059] related to the construction of
URL's etc. within `project`, `distributionManagement` and `scm` part in the pom for multi module
builds like this:
@@ -186,66 +188,68 @@ builds like this:
Detailed explanations can be found in [Inheritance Assembly][inheritance-assembly] and in [MNG-6059]
+
[inheritance-assembly]: https://maven.apache.org/ref/3.6.1/maven-model-builder/index.html#Inheritance_Assembly
## The detailed issue list[](#details)
-### Bugs
-
-- [MNG-5705] - NPE on parallel build in BuilderCommon.handleBuildError(BuilderCommon.java:147)
-- [MNG-5965] - Parallel build multiplies work if multiple goals are given
-- [MNG-5995] - Maven itself cannot run without maven-compat
-- [MNG-6256] - Maven script can break if "-f" path contains special characters
-- [MNG-6261] - Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
-- [MNG-6262] - getCanonicalFile() is not used consistently during project resolution
-- [MNG-6346] - ... was unexpected at this time when using -f option and path contains brackets
-- [MNG-6374] - ModelBuilder hangs with malformed pom.xml
-- [MNG-6429] - Integration Test site publishing requires Java 7 (or javadoc errors ignored)
-- [MNG-6495] - ModelResolver cannot be null
-- [MNG-6505] - child.(x.y).inherit.append.path value should be inherited
-- [MNG-6506] - Mojos are unable to load package annotations on Java >= 9
-- [MNG-6529] - `ProjectBuilder.build(List<File> projects, boolean, ProjectBuildingRequest)` doesn't honor `ProjectBuildingRequest.isResolveDependencies()`
-- [MNG-6530] - Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
-- [MNG-6533] - `ProjectBuilder.build(list_of_projects,...)` does not contain MavenProject in exception report
-- [MNG-6543] - Upgrade plexus classworld to support java 9+ `ClassLoader.findClass(String moduleName, String name)` in Mojos
-- [MNG-6558] - ToolchainsBuildingResult event is not sent on EventSpy
-- [MNG-6577] - pom.xml: Uncaught IllegalArgumentException when parsing unicode entity ref
-- [MNG-6590] - DefaultProjectArtifactsCache java.lang.IllegalStateException: Duplicate artifact resolution result
-- [MNG-6599] - unknown version in model id when version is defined from parent
+### Bugs:
+
+ - [MNG-5705] - NPE on parallel build in BuilderCommon.handleBuildError(BuilderCommon.java:147)
+ - [MNG-5965] - Parallel build multiplies work if multiple goals are given
+ - [MNG-5995] - Maven itself cannot run without maven-compat
+ - [MNG-6256] - Maven script can break if "-f" path contains special characters
+ - [MNG-6261] - Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
+ - [MNG-6262] - getCanonicalFile() is not used consistently during project resolution
+ - [MNG-6346] - ... was unexpected at this time when using -f option and path contains brackets
+ - [MNG-6374] - ModelBuilder hangs with malformed pom.xml
+ - [MNG-6429] - Integration Test site publishing requires Java 7 (or javadoc errors ignored)
+ - [MNG-6495] - ModelResolver cannot be null
+ - [MNG-6505] - child.(x.y).inherit.append.path value should be inherited
+ - [MNG-6506] - Mojos are unable to load package annotations on Java >= 9
+ - [MNG-6529] - `ProjectBuilder.build(List<File> projects, boolean, ProjectBuildingRequest)` doesn't honor `ProjectBuildingRequest.isResolveDependencies()`
+ - [MNG-6530] - Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
+ - [MNG-6533] - `ProjectBuilder.build(list_of_projects,...)` does not contain MavenProject in exception report
+ - [MNG-6543] - Upgrade plexus classworld to support java 9+ `ClassLoader.findClass(String moduleName, String name)` in Mojos
+ - [MNG-6558] - ToolchainsBuildingResult event is not sent on EventSpy
+ - [MNG-6577] - pom.xml: Uncaught IllegalArgumentException when parsing unicode entity ref
+ - [MNG-6590] - DefaultProjectArtifactsCache java.lang.IllegalStateException: Duplicate artifact resolution result
+ - [MNG-6599] - unknown version in model id when version is defined from parent
### Improvements
-- [MNG-6059] - Important use cases not covered, as child.inherit.append.path affects all children
-- [MNG-6159] - Child path adjustments break git scm urls
-- [MNG-6213] - Maven doesn't check the validity of scope value
-- [MNG-6481] - Allow to compile and test Maven with Java 11
-- [MNG-6513] - Replace depreated Plexus javadoc tags with annotations in ITs
-- [MNG-6515] - Fix javadoc build errors under Java 8 and 11
-- [MNG-6520] - Update assembly descriptors to 2.0.0
-- [MNG-6522] - Prepare Maven's Core Integration Test Suite to test with Java 12 and 13-ea
-- [MNG-6572] - use int or long instead of BigIntegers for little numbers in ComparableVersion
-- [MNG-6593] - track input location for super-pom
-- [MNG-6597] - add input location tracking for plugins configuration
-- [MNG-6600] - add input location tracking for default lifecycle bindings executions
-- [MNG-6601] - add input location tracking for site's reportPlugins injected by reports conversion
-- [MNG-6605] - Allow to suppress download messages in interactive mode
-- [MNG-6611] - Update animal-sniffer-maven-plugin to 1.17
+ - [MNG-6059] - Important use cases not covered, as child.inherit.append.path affects all children
+ - [MNG-6159] - Child path adjustments break git scm urls
+ - [MNG-6213] - Maven doesn't check the validity of scope value
+ - [MNG-6481] - Allow to compile and test Maven with Java 11
+ - [MNG-6513] - Replace depreated Plexus javadoc tags with annotations in ITs
+ - [MNG-6515] - Fix javadoc build errors under Java 8 and 11
+ - [MNG-6520] - Update assembly descriptors to 2.0.0
+ - [MNG-6522] - Prepare Maven's Core Integration Test Suite to test with Java 12 and 13-ea
+ - [MNG-6572] - use int or long instead of BigIntegers for little numbers in ComparableVersion
+ - [MNG-6593] - track input location for super-pom
+ - [MNG-6597] - add input location tracking for plugins configuration
+ - [MNG-6600] - add input location tracking for default lifecycle bindings executions
+ - [MNG-6601] - add input location tracking for site's reportPlugins injected by reports conversion
+ - [MNG-6605] - Allow to suppress download messages in interactive mode
+ - [MNG-6611] - Update animal-sniffer-maven-plugin to 1.17
### Wish
-- [MNG-6571] - Maven memory consumption issue
+ - [MNG-6571] - Maven memory consumption issue
### Task
-- [MNG-6538] - Upgrade Maven Artifact Resolver to 1.3.3 to restore API
-- [MNG-6544] - Replace CacheUtils#{eq,hash} with Objects
-- [MNG-6573] - Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI
-- [MNG-6618] - Maven doesn't export org.slf4j.event.Level
+ - [MNG-6538] - Upgrade Maven Artifact Resolver to 1.3.3 to restore API
+ - [MNG-6544] - Replace CacheUtils#{eq,hash} with Objects
+ - [MNG-6573] - Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI
+ - [MNG-6618] - Maven doesn't export org.slf4j.event.Level
### Dependency upgrade
-- [MNG-6526] - Upgrade to Wagon 3.3.1 (from 3.2.0)
-- [MNG-6591] - Upgrade to Wagon 3.3.2
+ - [MNG-6526] - Upgrade to Wagon 3.3.1 (from 3.2.0)
+ - [MNG-6591] - Upgrade to Wagon 3.3.2
+
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/3.6.2/release-notes.md b/content/markdown/docs/3.6.2/release-notes.md
index 18db3673..3a70e194 100644
--- a/content/markdown/docs/3.6.2/release-notes.md
+++ b/content/markdown/docs/3.6.2/release-notes.md
@@ -43,11 +43,12 @@ Issue Reporters of this release: Benoit GUERIN, Christian Schulte, Elliotte Rust
Code Contributors of this release: Guillaume Nodet, Mickael Istria, Ray Tsang, Stefan Oehme, Joseph Walton, Bo Zhang, AElMehdi, Christian Schulte, Mao Shuai, MartinKanters, Sergey Chernov, Jesse Glick.
+
Many thanks to all reporters and contributors for their time and support.
(Please send an email to the dev list if we missed anyone).
-## Overview about the changes
+## Overview about the changes
- This release focuses mostly performance improvements, better memory footprint, and less CPU usage.
@@ -129,6 +130,7 @@ Dependency upgrade
[MNG-6674] - Upgrade Wagon to 3.3.3
[MNG-6738] - Upgrade maven-resolver to 1.4.1
+
The full list of changes can be found in our [issue management system][4].
## Complete Release Notes
@@ -140,3 +142,4 @@ See [complete release notes for all versions][5]
[2]: https://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12345234
[5]: ../../docs/history.html
+
diff --git a/content/markdown/docs/3.6.3/release-notes.md b/content/markdown/docs/3.6.3/release-notes.md
index 42064d4e..9980fd54 100644
--- a/content/markdown/docs/3.6.3/release-notes.md
+++ b/content/markdown/docs/3.6.3/release-notes.md
@@ -41,24 +41,22 @@ the [end of these release notes](#details).
Issue Reporters of this release: Jonathan Chen, Charles Oliver Nutter, Lucas Ludueño, Stig Rohde Døssing, Vladimir Sitnikov
-Contributors of this release: Stuart McCulloch, Mickael Istria, Peter Lynch, Christian Wansart, Dezhi Cai, Anatoly Zaretsky, Stig Rohde Døssing
-
+Contributors of this release: Stuart McCulloch, Mickael Istria, Peter Lynch, Christian Wansart, Dezhi Cai, Anatoly Zaretsky, Stig Rohde Døssing
+
Many thanks to all reporters and contributors for their time and support.
(Please send an email to the dev list if we missed anyone).
-## Overview about the changes
+## Overview about the changes
- This is a regression release to fix some critical issues shipped with 3.6.2.
- Some license issues on binary distribution have been fixed.
- This Maven distribution is now Reproducible: if you [download Maven source archive](/download.cgi) (`apache-maven-3.6.3-src.zip` or `.tar.gz`), build it on Windows with JDK 8 using following command:
-
```
mvn -DbuildNumber=cecedd343002696d0abb50b32b541b8a6ba2883f package
```
-
you'll get bit-by-bit identical output (`apache-maven-3.6.3-bin.zip` and `.tar.gz` in `apache-maven/target/`) that you can check with sha512 fingerprints against official release.
If you're building on any Unix system, you'll need to add "`-Dline.separator=$'\r\n'`".
See the [Maven - Guide to Configuring for Reproducible Builds](/guides/mini/guide-reproducible-builds.html) for more details.
@@ -98,3 +96,4 @@ See [complete release notes for all versions][5]
[2]: https://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12346152
[5]: ../../docs/history.html
+
diff --git a/content/markdown/docs/3.8.1/release-notes.md b/content/markdown/docs/3.8.1/release-notes.md
index 17218a84..b4045bef 100644
--- a/content/markdown/docs/3.8.1/release-notes.md
+++ b/content/markdown/docs/3.8.1/release-notes.md
@@ -33,7 +33,7 @@ If you have any questions, please consult:
- the maven-user mailing list: [https://maven.apache.org/mailing-lists.html](/mailing-lists.html)
- the reference documentation: [https://maven.apache.org/ref/3.8.1/](/ref/3.8.1/)
-## Overview about the changes
+## Overview about the changes
This release covers two CVEs:
@@ -42,19 +42,19 @@ This release covers two CVEs:
We received a report from Jonathan Leitschuh about a vulnerability of custom repositories in dependency POMs.
We've split this up into three separate issues:
-- Possible Man-In-The-Middle-Attack due to custom repositories using HTTP\
+ - Possible Man-In-The-Middle-Attack due to custom repositories using HTTP\
More and more repositories use HTTPS nowadays, but this hasn't always been the case. This means that Maven Central contains POMs with custom repositories that refer to a URL over HTTP.
- This makes downloads via such repository a target for a MITM attack.
- At the same time, developers are probably not aware that for some downloads an insecure URL is being used.
+ This makes downloads via such repository a target for a MITM attack.
+ At the same time, developers are probably not aware that for some downloads an insecure URL is being used.
Because uploaded POMs to Maven Central are immutable, a change for Maven was required.
To solve this, we extended the mirror configuration with `<blocked>` parameter,
and we added a new `external:http:*` mirror selector (like existing `external:*`), meaning "any external URL using HTTP".\
The decision was made to block such external HTTP repositories by default: this is done by providing a mirror in the `conf/settings.xml` blocking insecure HTTP external URLs.
-- Possible Domain Hijacking due to custom repositories using abandoned domains\
- Sonatype has analyzed which domains were abandoned and has claimed these domains.
+ - Possible Domain Hijacking due to custom repositories using abandoned domains\
+ Sonatype has analyzed which domains were abandoned and has claimed these domains.
-- Possible hijacking of downloads by redirecting to custom repositories\
+ - Possible hijacking of downloads by redirecting to custom repositories\
This one was the hardest to analyze and explain. The short story is: you're safe, dependencies are only downloaded from repositories within their context.
So there are two main questions: what is the context and what is the order?
The order is described on the [Repository Order](/guides/mini/guide-multiple-repositories.html#repository-order) page.
@@ -70,19 +70,20 @@ This release covers two CVEs:
## Why does this version have the value 3.8.1?
-- Why not 3.6.4?\
+ - Why not 3.6.4?\
This is not just a bugfix as it contains three features that **cause a change of default behavior** (external HTTP insecure URLs are now blocked by default):
your builds may fail when using this new Maven release, if you use now blocked repositories. Please check and eventually fix before upgrading.
-- Why not 3.7.0?\
+ - Why not 3.7.0?\
Apache Maven 3.7.0 has been advertised in the past that it would be the first release where you could optionally activate the build/consumer feature:
the version containing this feature has been renamed to 4.0.0.
Reusing 3.7.0 might lead to confusion, hence we picked the next available minor version.
-- Why not 3.8.0?\
+ - Why not 3.8.0?\
With every release there's a 72h+ voting period. During the vote of 3.8.0 a bug was discovered, one that was important enough to cancel the vote.
With Maven we burn versions, to ensure we're always talking about the same "version". This way there will be never confusion about which Maven 3.8.0 one was using.
+
## How to fix when I get a HTTP repository blocked?
If the repository is defined in your `pom.xml`, please fix it in your source code.
@@ -95,16 +96,16 @@ This release covers two CVEs:
Options to fix are:
-- upgrade the dependency version to a newer version that replaced the obsolete HTTP repository URL with a HTTPS one,
+ - upgrade the dependency version to a newer version that replaced the obsolete HTTP repository URL with a HTTPS one,
-- keep the dependency version but [define a mirror in your settings](/guides/mini/guide-mirror-settings.html).
+ - keep the dependency version but [define a mirror in your settings](/guides/mini/guide-mirror-settings.html).
## The detailed issue list[](#details)
Bug
[MNG-7128] - improve error message when blocked repository defined in build POM
-
+
New Feature
[MNG-7116] - Add support for mirror selector on external:http:*
@@ -115,7 +116,7 @@ Dependency upgrade
[MNG-7119] - Upgrade Maven Wagon to 3.4.3
[MNG-7123] - Upgrade Maven Resolver to 1.6.2
-
+
The full list of changes can be found in our [issue management system][4].
## Complete Release Notes
@@ -127,3 +128,4 @@ See [complete release notes for all versions][5]
[2]: https://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12350032
[5]: ../../docs/history.html
+
diff --git a/content/markdown/docs/3.8.3/release-notes.md b/content/markdown/docs/3.8.3/release-notes.md
index baf4cfd4..0c414008 100644
--- a/content/markdown/docs/3.8.3/release-notes.md
+++ b/content/markdown/docs/3.8.3/release-notes.md
@@ -35,9 +35,9 @@ If you have any questions, please consult:
## Overview About the Changes
-- Regression fixes from Maven 3.8.2
-- [Drop CDI API][6] to avoid leakage into code
-- Speed improvements with [MNG-7235][7] and [MNG-7236][8]
+* Regression fixes from Maven 3.8.2
+* [Drop CDI API][6] to avoid leakage into code
+* Speed improvements with [MNG-7235][7] and [MNG-7236][8]
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/3.8.4/release-notes.md b/content/markdown/docs/3.8.4/release-notes.md
index 6057c3ba..a52f945a 100644
--- a/content/markdown/docs/3.8.4/release-notes.md
+++ b/content/markdown/docs/3.8.4/release-notes.md
@@ -35,8 +35,8 @@ If you have any questions, please consult:
## Overview About the Changes
-- Regression fixes from Maven 3.8.3
-- Upgrade to Jansi 2.4.0 which supports macOS on ARM natively
+* Regression fixes from Maven 3.8.3
+* Upgrade to Jansi 2.4.0 which supports macOS on ARM natively
The full list of changes can be found in our [issue management system][4].
@@ -55,3 +55,4 @@ See [complete release notes for all versions][5]
[5]: ../../docs/history.html
[6]: https://issues.apache.org/jira/browse/MNG-6843
[7]: https://issues.apache.org/jira/browse/MNG-7335
+
diff --git a/content/markdown/docs/3.8.5/release-notes.md b/content/markdown/docs/3.8.5/release-notes.md
index 76c2f688..2616dccf 100644
--- a/content/markdown/docs/3.8.5/release-notes.md
+++ b/content/markdown/docs/3.8.5/release-notes.md
@@ -35,7 +35,7 @@ If you have any questions, please consult:
## Overview About the Changes
-- Regression fixes from Maven 3.8.4
+* Regression fixes from Maven 3.8.4
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/3.8.6/release-notes.md b/content/markdown/docs/3.8.6/release-notes.md
index f1243ea0..618e5e19 100644
--- a/content/markdown/docs/3.8.6/release-notes.md
+++ b/content/markdown/docs/3.8.6/release-notes.md
@@ -35,8 +35,8 @@ If you have any questions, please consult:
## Overview About the Changes
-- Regression fixes from Maven 3.8.5
-- Improve locking for multithreaded builds
+* Regression fixes from Maven 3.8.5
+* Improve locking for multithreaded builds
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/3.8.7/release-notes.md b/content/markdown/docs/3.8.7/release-notes.md
index ad6416bd..0cfe6bc0 100644
--- a/content/markdown/docs/3.8.7/release-notes.md
+++ b/content/markdown/docs/3.8.7/release-notes.md
@@ -35,9 +35,9 @@ If you have any questions, please consult:
## Overview About the Changes
-- Regression fixes from Maven 3.8.6
-- General fixes
-- Maven Wagon upgrade
+* Regression fixes from Maven 3.8.6
+* General fixes
+* Maven Wagon upgrade
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/3.9.0/release-notes.md b/content/markdown/docs/3.9.0/release-notes.md
index 8a6531bc..f24f6256 100644
--- a/content/markdown/docs/3.9.0/release-notes.md
+++ b/content/markdown/docs/3.9.0/release-notes.md
@@ -35,44 +35,44 @@ If you have any questions, please consult:
## Overview About the Changes
-- Minimum Java version to use with Maven 3.9.0 is raised to Java 8.
-- With Java 8, upgrade of several key dependencies became possible as well.
-- Several backports from Maven 4.x line.
-- Long outstanding issue fixes from Maven 3.x line.
-- Cutting ties with Maven 2 backward compatibility, preparing grounds for Maven 4.
-- General fixes and improvements.
+* Minimum Java version to use with Maven 3.9.0 is raised to Java 8.
+* With Java 8, upgrade of several key dependencies became possible as well.
+* Several backports from Maven 4.x line.
+* Long outstanding issue fixes from Maven 3.x line.
+* Cutting ties with Maven 2 backward compatibility, preparing grounds for Maven 4.
+* General fixes and improvements.
### Potentially Breaking Core Changes
-- Maven 2.x was auto-injecting an ancient version of `plexus-utils` dependency into the plugin classpath, and Maven 3.x continued doing this to preserve backward compatibility. Starting with Maven 3.9, it does not happen anymore. This change may lead to plugin breakage. The fix for affected plugin maintainers is to explicitly declare a dependency on `plexus-utils`. The workaround for affected plugin users is to add this dependency to plugin dependencies until issue is fixed by the affect [...]
-- Mojos are prevented to boostrap new instance of `RepositorySystem` (for example by using deprecated `ServiceLocator`), they should reuse `RepositorySystem` instance provided by Maven instead. See [MNG-7471](https://issues.apache.org/jira/browse/MNG-7471).
-- Each line in `.mvn/maven.config` is now interpreted as a single argument. That is, if the file contains multiple arguments, these must now be placed on separate lines, see [MNG-7684](https://issues.apache.org/jira/browse/MNG-7684).
+* Maven 2.x was auto-injecting an ancient version of `plexus-utils` dependency into the plugin classpath, and Maven 3.x continued doing this to preserve backward compatibility. Starting with Maven 3.9, it does not happen anymore. This change may lead to plugin breakage. The fix for affected plugin maintainers is to explicitly declare a dependency on `plexus-utils`. The workaround for affected plugin users is to add this dependency to plugin dependencies until issue is fixed by the affect [...]
+* Mojos are prevented to boostrap new instance of `RepositorySystem` (for example by using deprecated `ServiceLocator`), they should reuse `RepositorySystem` instance provided by Maven instead. See [MNG-7471](https://issues.apache.org/jira/browse/MNG-7471).
+* Each line in `.mvn/maven.config` is now interpreted as a single argument. That is, if the file contains multiple arguments, these must now be placed on separate lines, see [MNG-7684](https://issues.apache.org/jira/browse/MNG-7684).
### Notable Core Improvements
-- Help with projects maintenance: Maven now warns about use of deprecated plugins, goals, parameters, etc.
-- Add support for "mvn pluginPrefix:version:goal" invocation, and align console logging as well (make it copy-paste-able).
-- Add profile activation by packaging.
-- Maven 3.9.0 is now fully compatible with new 3.x line of install and deploy plugins (previous versions warns about this).
+* Help with projects maintenance: Maven now warns about use of deprecated plugins, goals, parameters, etc.
+* Add support for "mvn pluginPrefix:version:goal" invocation, and align console logging as well (make it copy-paste-able).
+* Add profile activation by packaging.
+* Maven 3.9.0 is now fully compatible with new 3.x line of install and deploy plugins (previous versions warns about this).
### Notable Resolver 1.9.x Improvements
-- Shared local repository (advisory file locking, Hazelcast or Redis, see [documentation](https://maven.apache.org/resolver/local-repository.html#shared-access-to-local-repository)).
-- Split local repository, plus "workspace" support for branched development (see [documentation](https://maven.apache.org/resolver/local-repository.html#split-local-repository)).
-- Switchable and alternative resolver transports included, with default switched to native transport.
-- Pluggable checksum algorithms API (is not tied to MessageDigest anymore, see [documentation](https://maven.apache.org/resolver/about-checksums.html)).
-- Choice of resolver collectors: a new BF collector (with parallel POM downloads) has been added along the existing DF one.
-- Remote repository filtering (see [documentation](https://maven.apache.org/resolver/remote-repository-filtering.html)).
-- Trusted checksum sources (ability to provide some or all artifact checksums ahead of time).
-- Pluggable artifact resolver post-processor, with "trustedChecksums" implementation.
-- Chained local repository (for IT isolation between "outer" and "inner" builds).
-- Recording reverse dependency tree tracking information into local repository.
+* Shared local repository (advisory file locking, Hazelcast or Redis, see [documentation](https://maven.apache.org/resolver/local-repository.html#shared-access-to-local-repository)).
+* Split local repository, plus "workspace" support for branched development (see [documentation](https://maven.apache.org/resolver/local-repository.html#split-local-repository)).
+* Switchable and alternative resolver transports included, with default switched to native transport.
+* Pluggable checksum algorithms API (is not tied to MessageDigest anymore, see [documentation](https://maven.apache.org/resolver/about-checksums.html)).
+* Choice of resolver collectors: a new BF collector (with parallel POM downloads) has been added along the existing DF one.
+* Remote repository filtering (see [documentation](https://maven.apache.org/resolver/remote-repository-filtering.html)).
+* Trusted checksum sources (ability to provide some or all artifact checksums ahead of time).
+* Pluggable artifact resolver post-processor, with "trustedChecksums" implementation.
+* Chained local repository (for IT isolation between "outer" and "inner" builds).
+* Recording reverse dependency tree tracking information into local repository.
The full list of changes can be found in our [issue management system][4].
## Known Issues
-- Observed roughly 10% slow-down on large builds when compared to Maven 3.8.7, tracked on [MNG-7677](https://issues.apache.org/jira/browse/MNG-7677).
+* Observed roughly 10% slow-down on large builds when compared to Maven 3.8.7, tracked on [MNG-7677](https://issues.apache.org/jira/browse/MNG-7677).
## Complete Release Notes
diff --git a/content/markdown/docs/4.0.0-alpha-2/release-notes.md b/content/markdown/docs/4.0.0-alpha-2/release-notes.md
index 33c7b9d1..632f0d5d 100644
--- a/content/markdown/docs/4.0.0-alpha-2/release-notes.md
+++ b/content/markdown/docs/4.0.0-alpha-2/release-notes.md
@@ -37,10 +37,10 @@ If you have any questions, please consult:
## Overview About the Changes
-- cli improvement: `--also-make` , `--resume`, `--non-recursive`, `--fail-on-severity`
-- consistent timestamps
-- build/consumer POMs (automatic parent versioning, automatic versioning of reactor dependencies, automatic detection of child modules)
-- new maven 4 api
+* cli improvement: `--also-make` , `--resume`, `--non-recursive`, `--fail-on-severity`
+* consistent timestamps
+* build/consumer POMs (automatic parent versioning, automatic versioning of reactor dependencies, automatic detection of child modules)
+* new maven 4 api
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/4.0.0-alpha-3/release-notes.md b/content/markdown/docs/4.0.0-alpha-3/release-notes.md
index 7236f755..5cbd242a 100644
--- a/content/markdown/docs/4.0.0-alpha-3/release-notes.md
+++ b/content/markdown/docs/4.0.0-alpha-3/release-notes.md
@@ -37,9 +37,9 @@ If you have any questions, please consult:
## Overview About the Changes
-- upgrade maven resolver 1.9.2
-- chained local repository
-- profile activation by packaging
+* upgrade maven resolver 1.9.2
+* chained local repository
+* profile activation by packaging
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/4.0.0-alpha-4/release-notes.md b/content/markdown/docs/4.0.0-alpha-4/release-notes.md
index 1a981a81..81ac7419 100644
--- a/content/markdown/docs/4.0.0-alpha-4/release-notes.md
+++ b/content/markdown/docs/4.0.0-alpha-4/release-notes.md
@@ -37,11 +37,11 @@ If you have any questions, please consult:
## Overview About the Changes
-- upgrade maven resolver 1.9.4
-- improved resolution of modules within a multi-module build
-- do not parse all projects in the reactor when building a subtree
-- fix some compatibility issues (with flatten-maven-plugin)
-- re-implement the consumer pom feature to support the maven-gpg-plugin
+* upgrade maven resolver 1.9.4
+* improved resolution of modules within a multi-module build
+* do not parse all projects in the reactor when building a subtree
+* fix some compatibility issues (with flatten-maven-plugin)
+* re-implement the consumer pom feature to support the maven-gpg-plugin
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/examples/index.md b/content/markdown/examples/index.md
index a7995fb8..4fec2827 100644
--- a/content/markdown/examples/index.md
+++ b/content/markdown/examples/index.md
@@ -23,6 +23,8 @@ under the License.
## Examples
-- [Injecting POM Properties via settings.xml](./injecting-properties-via-settings.html)
+ - [Injecting POM Properties via settings.xml](./injecting-properties-via-settings.html)
+
+ - [Maven 3 lifecycle extensions](./maven-3-lifecycle-extensions.html)
+
-- [Maven 3 lifecycle extensions](./maven-3-lifecycle-extensions.html)
diff --git a/content/markdown/examples/injecting-properties-via-settings.md b/content/markdown/examples/injecting-properties-via-settings.md
index 51aef3de..f884dcc0 100644
--- a/content/markdown/examples/injecting-properties-via-settings.md
+++ b/content/markdown/examples/injecting-properties-via-settings.md
@@ -22,12 +22,18 @@ under the License.
-->
## Example: Injecting POM Properties via Settings.xml
+
### Impetus
+
You have a plugin parameter that should contain a user-specific value. This parameter has a common format (relative directory structure), but depends on knowing the directory of the installed application or something.
+
+
### Plugin Configuration
+
+
```
<project>
[...]
@@ -45,8 +51,11 @@ under the License.
</build>
```
+
### `settings.xml`
+
+
```
<settings>
[...]
@@ -65,6 +74,11 @@ under the License.
</settings>
```
+
### Explanation
+
When Maven loads the project's POM, it will pickup the activated profiles from the `activeProfiles` section of the `settings.xml` file, and inject the properties declared within the profile. When the POM is interpolated, the `application-home` property will already have been injected, so will allow the plugin's parameter value to be resolved.
+
+
+
diff --git a/content/markdown/faq-unoffical.md b/content/markdown/faq-unoffical.md
index 4fd4dbc1..bfaafe59 100644
--- a/content/markdown/faq-unoffical.md
+++ b/content/markdown/faq-unoffical.md
@@ -17,14 +17,13 @@ specific language governing permissions and limitations
under the License.
-->
-*NOTE:* *This page contains drafts of user contributed FAQ entries. The content you see here might not be fully fool-proof or might not comply with the best practices promoted by Maven. What is only guaranteed is that they have worked once for some members. It is best to treat these items as "works in progress" until they have been reviewed and promoted to the main Maven documentation site.*
+*NOTE:* _This page contains drafts of user contributed FAQ entries. The content you see here might not be fully fool-proof or might not comply with the best practices promoted by Maven. What is only guaranteed is that they have worked once for some members. It is best to treat these items as "works in progress" until they have been reviewed and promoted to the main Maven documentation site._
Please follow the format that is being used because it will help in our automated extraction of material which can then be incorporated into the main site.
This page serves as a collection of questions *with* answers. If you have a frequently asked question that doesn't yet have an answer, please list that question on [the other page](FAQs].
# Answered Questions (Index)
-
### Reports & Site Docs
[How do I merge a list of configuration items in a parent POM with those in a child POM?](#How do I merge a list of configuration items in a parent POM with those in a child POM?)
@@ -235,7 +234,6 @@ NOTE: I fixed this behavior in Maven's trunk; previously, it had been putting th
So, to recap:
parent:
-
```xml
<configuration>
<items>
@@ -244,9 +242,7 @@ parent:
</items>
</configuration>
```
-
child:
-
```
<configuration>
<items combine.children="append">
@@ -254,9 +250,7 @@ child:
</items>
</configuration>
```
-
result:
-
```
<configuration>
<items>
@@ -266,7 +260,6 @@ result:
</items>
</configuration>
```
-
(If you're using an earlier version of Maven than trunk (revId 545315), the order above will be three, one, two.)
### Why do I not get an index.html page generated for my project website?
@@ -296,13 +289,12 @@ The usual cause of this is configuring maven-project-info-reports plugin and lea
This error indicates that Maven is either unable to access the required plug-in from your local repository, or unable to access the official or `central` Maven plug-in repository.
To resolve this error:
-
- If you are behind a http proxy, please check the Maven2 [proxy settings guide](http://maven.apache.org/guides/mini/guide-proxies.html).
- If you are upgrading Maven from an older version, try running with \-U. This will force an update check on all plug-ins.
If the error persists, browse [archived discussions](http://www.mail-archive.com/users@maven.apache.org/), post to the Maven user list, or log a [ticket](http://jira.codehaus.org/browse/MNG) describing your problem, if you think it is a bug. Tickets may also be issued for feature enhancement requests, and other tasks.
-*Errors, Dependencies, Plugins*
+_Errors, Dependencies, Plugins_
### How do I install a file in my local repository along with a generic POM?
@@ -321,12 +313,11 @@ mvn install:install-file
This command installs the jar in your local repository with the generated generic pom.
{{Well, this doesn't work in Maven 2.0.2. It just gives the message "Cannot execute mojo: install-file. It requires a project with an existing pom.xml, but the build is not using one." \--kreiger@imcode.com}}
- *Repositories*
+ _Repositories_
### How do I install a file in my local repository along with my customized POM?
The solution requires the `-DpomFile=<path-to-pom>` parameter just like the sample below.
-
```
mvn install:install-file
-DgroupId=<group-id>
@@ -336,24 +327,23 @@ mvn install:install-file
-Dpackaging=<packaging> (i.e. jar)
-DpomFile=<path-to-pom>
```
-
This command will install the file in your local repository along with your customed pom.
-*Repositories*
+_Repositories_
### How do I include/exclude the other modules in the navigation menu in the parent site?
[MNG-661](http://jira.codehaus.org/browse/MNG-661), provides a simple patch which provides parent and module links using the project URLs which as you
correctly point out only work when the site is deployed.
-*Plugins & Lifecycle*
+_Plugins & Lifecycle_
-*General*
+_General_
### What is the difference between Maven and Ivy?
For a comparison of Maven's features vs Ivy's you can refer to our [feature comparison](http://docs.codehaus.org/display/MAVEN/Feature+Comparisons)
-*General*
+_General_
### How do I get a plug-in's dependencies from a Mojo?
@@ -404,7 +394,7 @@ public class MyMojo
}
}
}
-```
+```
### Does the v4.0.0 POM include a < versions/ > element?
@@ -412,20 +402,19 @@ The POM does not inlcude a `<versions/>` element. The POM reflects the current s
However, if the SCM tag of the `<scm>` section of the POM is populated, the repository records build versions, enabling developers to reconstruct the information for each released build.
-*POM, General*
+_POM, General_
### How do I create a report that does not require Doxia's Sink interface?
Make it a report and override the `isExternalReport()` method to return true.
-*Sites & Reporting*
+_Sites & Reporting_
### How do I prevent verification warnings with custom repositories?
Warnings from custom repositories (usually located within the organization's network, or even on the same workstation) are triggered when Maven tries to verify the integrity of the files in the repository. This verification is done via the SHA1 or MD5 sum of the file. If these sum files do not exist, then a warning appears.
Support for downloading the security sum files is not yet included in the Maven2 distribution. There are free command-line utilities on the Internet that generate these sums. Below is an example of a bash script (use [Cygwin](http://cygwin.com) if you are using a windows machine) that generates sha1sum for all jar, xml and pom files contained in the directory where it is executed:
-
```
#!/usr/bin/bash
@@ -466,24 +455,23 @@ rm "$tmpFile"
```
The script above has been tested on [Cygwin](http://cygwin.com) and is provided "as-is" and with no guarantee.
-*Errors, Repositories*
+_Errors, Repositories_
### What does the "ERROR: Cannot override read-only parameter: `<parameter_name>` " message, when running <plugin_name>: mean?
This means that the parameter being overriden in the pom.xml is read-only. Hence, it is not possible to override this parameter.
-*Errors, POM*
+_Errors, POM_
### How do I generate Maven plug-in sites, with pages that include an overview of the goals and parameters for each plug-in?
Include maven-plugin-plugin as a report.
-*Plugin Requests, Sites & Reporting*
+_Plugin Requests, Sites & Reporting_
### Can I define the antrun plugin to be executed on demand like "mvn antrun:run"?
The antrun plugin can be executed on demand only if:
-
- the top level configuration of the plugin contains all the information
- a variable is passed from the command line, eg `-Dtarget=foo antrun:run`
- the appropriate target in the script is executed based on the variable
@@ -491,7 +479,7 @@ The antrun plugin can be executed on demand only if:
However, it is recommended that developers write plugins for their goals (Ant support for
plugins will be available soon, currently you must write them in java or beanshell).
-*Plugins and Lifecycle, Ant-related*
+_Plugins and Lifecycle, Ant-related_
### How do I properly populate variables, when extending a mojo from another plugin?
@@ -499,7 +487,7 @@ When creating plugins, the field metadata is read from source files, so it is no
It is currently recommended that plug-ins be built using composition, instead of inheritence.
-*Plugin Requests, Design, Patterns & Best Practices*
+_Plugin Requests, Design, Patterns & Best Practices_
### How do I access artifacts if Ibiblio is down?
@@ -507,11 +495,11 @@ To access artifacts if Ibiblio is down, use any of its mirror sites.
[Guide mirror settings](http://maven.apache.org/guides/mini/guide-mirror-settings.html)
-*Repositories, General*
+_Repositories, General_
### How do I get a list of archetypes?
-To get a list of archetypes, refer to the following page [<http://svn.apache.org/viewcvs.cgi/maven/archetype/trunk/maven-archetypes)>
+To get a list of archetypes, refer to the following page [http://svn.apache.org/viewcvs.cgi/maven/archetype/trunk/maven-archetypes)
### How do I specify my remote repo in Maven?
@@ -526,9 +514,8 @@ To specify a remote repo in Maven, add the `<repositories>` element to the POM:
</repository>
</repositories>
```
-
-Or, refer to the following page [<http://maven.apache.org/guides/mini/guide-multiple-repositories.html)>
-*Repositories*
+Or, refer to the following page [http://maven.apache.org/guides/mini/guide-multiple-repositories.html)
+_Repositories_
### How do I specify which output directories the Eclipse plugin puts into the .classpath file?
@@ -549,15 +536,15 @@ Or, refer to the following page [<http://maven.apache.org/guides/mini/guide-mult
...
</build>
```
-*Plugins and Lifecycle, IDEs*
+_Plugins and Lifecycle, IDEs_
-*General, Plugins and Lifecycle*
+_General, Plugins and Lifecycle_
### Can a profile inherit the configuration of a "sibling" profile?
No. Profiles merge when their ID's match - so you can inherit them from a parent POM (but you can't inherit profiles from the same POM).
-*Inheritence and Interpolation, Plugins and Lifecycle, POM*
+_Inheritence and Interpolation, Plugins and Lifecycle, POM_
### How do I run an ant task twice, against two different phases?
@@ -596,12 +583,11 @@ You can specify multiple execution elements under the executions tag, giving eac
</plugin>
```
-*Ant-related*
+_Ant-related_
### How do I prevent tests from running twice, after adding a configuration for the surefire plugin?
Declare the configuration outside of the executions tag of the plugin.
-
```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -617,14 +603,13 @@ Declare the configuration outside of the executions tag of the plugin.
</configuration>
</plugin>
```
-*Plugins and Lifecycle, Sites & Reporting*
+_Plugins and Lifecycle, Sites & Reporting_
### How do I integrate static (x)html into my Maven site?
You can integrate your static pages in this several steps,
-- Put your static pages in the resources directory, ${basedir}/src/site/resources.
-- Create your site.xml and put it in `${basedir}/src/site`. An example below:
-
+* Put your static pages in the resources directory, ${basedir}/src/site/resources.
+* Create your site.xml and put it in `${basedir}/src/site`. An example below:
```
<project name="Maven War Plugin">
<bannerLeft>
@@ -649,7 +634,7 @@ You can integrate your static pages in this several steps,
</project>
```
-- Link the static pages by modifying the `<menu>` section, create items and map it with the filename of the static pages.
+* Link the static pages by modifying the `<menu>` section, create items and map it with the filename of the static pages.
```
<menu name="Overview">
@@ -658,29 +643,27 @@ You can integrate your static pages in this several steps,
<item name="<put-name-here>" xhref="<filename-of-the-static-page>"/>
</menu>
```
-
- *Sites & Reporting*
+ _Sites & Reporting_
### How do I specify that all web modules will inherit the group's common files from a parent web module?
maven-war-plugin 2.0-beta-3 and later supports merging of wars. Just reference the common WAR project from another WAR project as a dependency of `<type>war</type>` and it will automatically be merged.
-See [<http://jira.codehaus.org/browse/MWAR-8)>
+See [http://jira.codehaus.org/browse/MWAR-8)
-*Inheritence and Interpolation*
+_Inheritence and Interpolation_
### How do I determine which POM contains missing transitive dependency?
run `mvn -X`
-*POM, Dependencies*
+_POM, Dependencies_
-*General, POM, Plugins and Lifecycle, Command Line*
+_General, POM, Plugins and Lifecycle, Command Line_
### How do I determine the stale resources in a Mojo to avoid reprocessing them?
This can be done using the following piece of code:
-
```
// Imports needed
import org.codehaus.plexus.compiler.util.scan.InclusionScanException;
@@ -692,10 +675,8 @@ import org.codehaus.plexus.compiler.util.scan.mapping.SuffixMapping;
scanner.addSourceMapping( new SuffixMapping( ".xml", ".html" ) );
Set<File> staleFiles = (Set<File>) scanner.getIncludedSources( this.sourceDirectory, this.targetDirectory );
```
-
The second parameter to the StaleSourceScanner is the set of includes, while the third parameter is the set of excludes. You must add a source mapping to the scanner (second line). In this case we're telling the scanner what is the extension of the result file (.html) for each source file extension (.xml). Finally we get the stale files as a `Set<File>` calling the `getIncludedSources` method, passing as parameters the source and target directories (of type File). The Maven API doesn't s [...]
In order to use this API you must include the following dependency in your pom:
-
```
<dependencies>
<dependency>
@@ -706,21 +687,18 @@ In order to use this API you must include the following dependency in your pom:
</dependencies>
```
-*POM, Plugin API*
+_POM, Plugin API_
### What does the FATAL ERROR with the message *"Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log"* when using the maven-checkstyle-plugin mean?
Checkstyle uses commons-logging, which has classloader problems when initialized within a Maven plugin's container. This results in the above message - if you run with '-e', you'll see something like the following:
---
-
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log
---
-
buried deep in the stacktrace.
The only workaround we currently have for this problem is to include another commons-logging Log implementation in the plugin itself. So, you can solve the problem by adding the following to your plugin declaration in your POM:
-
```
<project>
...
@@ -749,12 +727,11 @@ The only workaround we currently have for this problem is to include another com
</reporting>
</project>
```
-
While this may seem a counter-intuitive way of configuring a report, it's important to remember that Maven plugins can have a mix of reports and normal mojos. When a POM has to configure extra dependencies for a plugin, it should do so in the normal plugins section.
We will probably try to fix this problem before the next release of the checkstyle plugin.
*UPDATE:* This problem has been fixed in the SVN trunk version of the checkstyle plugin, which should be released very soon.
- *Plugins and Lifecycle, Sites & Reporting, Errors*
+ _Plugins and Lifecycle, Sites & Reporting, Errors_
### Where do I configure report plug-ins, like javadoc?
@@ -764,7 +741,7 @@ Configuration in the build section is only used during the normal lifecycle or t
Configuration should go there if you do not want the report on the site, or the configuration differs from what is on the site (eg, some plugins have a fail build option).
-*Sites & Reporting, Plugins and Lifecycle, Command Line*
+_Sites & Reporting, Plugins and Lifecycle, Command Line_
### How do I deploy my binary during the deploy phase?
@@ -785,14 +762,12 @@ Configuration should go there if you do not want the report on the site, or the
</executions>
</plugin>
```
-
Then run `mvn deploy`.
-*Deployment*
+_Deployment_
### How do I add main class in a generated jar's manifest?
Configure the maven-jar-plugin and add your main class.
-
```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -805,7 +780,7 @@ Configure the maven-jar-plugin and add your main class.
</archive>
</configuration>
</plugin>
-```
+```
### How do I install artifacts to a remote repository?
@@ -822,13 +797,13 @@ mvn deploy:deploy-file
-Durl=<url-of-remote-repo>
```
-*Repositories, Command Line*
+_Repositories, Command Line_
### Does a POM inherit its resources?
Yes, resources are inherited, but only if the child pom does not define any resources. If it does, then the project just uses those resources defined in its pom and the parents resources are overridden.
-*POM, Inheritence and Interpolation*
+_POM, Inheritence and Interpolation_
### How do I use SNAPSHOT versions of plug-ins?
@@ -843,7 +818,6 @@ Also refer to [How do I skip unit tests when building a project?](How do I skip
### How do I execute the assembly plugin with different configurations?
Add this to your pom,
-
```
<build>
...
@@ -882,9 +856,9 @@ Add this to your pom,
</build>
```
-
and run `mvn install`, this will execute the assembly plugin twice with different config.
+
### What is Maven's order of inheritance?
- parent pom
@@ -894,7 +868,7 @@ and run `mvn install`, this will execute the assembly plugin twice with differen
where the last overrides the previous.
-*General, Inheritence and Interpolation, Design, Patterns & Best Practices*
+_General, Inheritence and Interpolation, Design, Patterns & Best Practices_
### How do I add my generated sources to the compile path of Maven, when using modello?
@@ -902,7 +876,7 @@ Modello generate the sources in the generate-sources phase and automatically add
You have to declare the modello-plugin in the build of your plugin for source generation (in that way the sources are generated each time).
-*Plugins and Lifecycle*
+_Plugins and Lifecycle_
### Can I add a java source to my war package?
@@ -912,20 +886,19 @@ Please refer to these sites for more info
[http://maven.apache.org/guides/mini/guide-assemblies.html]
[http://maven.apache.org/plugins/maven-assembly-plugin/howto.html]
-*Deployments, Plugins and Lifecycle*
+_Deployments, Plugins and Lifecycle_
### What does the "You cannot have two plugin executions with the same (or missing) `<id/>` elements" message mean?
It means that you have executed a plugin multiple times with the same `<id>`. Provide each `<execution>` with a unique `<id>` then it would be ok.
-*Errors, Plugins and Lifecycle*
+_Errors, Plugins and Lifecycle_
### Can I disable transitive dependencies?
No you can't, but you may exclude the dependencies you dont want to include in your project.
Following is a sample on how to exclude transitive dependencies.
-
```
<project>
...
@@ -944,13 +917,13 @@ Following is a sample on how to exclude transitive dependencies.
</project>
```
-*Dependencies, Design, Patterns & Best Practices*
+_Dependencies, Design, Patterns & Best Practices_
### Where can I get offline documentation for Maven?
Check it out from [http://svn.apache.org/repos/asf/maven/site/trunk] and run mvn site:site
-*General, Sites & Reporting*
+_General, Sites & Reporting_
### How do I skip unit tests when building a project?
@@ -958,7 +931,7 @@ Run the mvn command with `-Dmaven.test.skip=true` argument.
Also see [How do I run a build/package/deploy process without waiting for reports or unit tests, so that I can quickly deploy to an integration box?]
-*Sites & Reporting, General*
+_Sites & Reporting, General_
### How do I create a command line parameter (i.e., \-Dname=value ) in my mojo?
@@ -970,16 +943,14 @@ In your mojo, put `expression=${<exp>}` in your parameter field
*/
private String exp;
```
-
You may now able to pass parameter values to the command line.
`mvn \-Dexpression.name=value install`
-*Command Line*
+_Command Line_
### What is the purpose of displaying read-only, plug-in fields in user documentation, if they are not configurable in the project descriptor?
Often, parameters are specified as read-only to indicate that its value should be changed indirectly, rather than in the plugins `<configuration/>` section. For instance, I may have a plugin that declares a parameter as such:
-
```
/**
* @parameter default-value="${project.build.directory}"
@@ -988,14 +959,14 @@ Often, parameters are specified as read-only to indicate that its value should b
*/
private File buildDir;
```
-
In this case, my plugin wants to output something to the project's build directory. If this were configured directly on the plugin, it might not be cleaned up when the user issued *'mvn clean'*, so instead I mark it as `@readonly`. This tells the user that she should modify the structure referenced by *default-value*(i.e. `<project><build><directory/>` in the POM) instead, which will allow this plugin to be a good citizen in the build process.
+
### I've just created a maven plugin. Is there a sample plugin integration test I can use?
Each integration test is a separate project. For a plugin, you may want to create a project that will use your plugin and probably put it inside src/test/projects like maven-antrun-plugin, maven-eclipse-plugin, maven-javadoc-plugin and several others. These plugins can be found here: [https://svn.apache.org/repos/asf/maven/plugins/trunk]
-*Plugins and Lifecycle, Sites & Reporting, Integration tests*
+_Plugins and Lifecycle, Sites & Reporting, Integration tests_
### The snapshot version of the plugin is not updated in the snapshot repo, What should I do to update my copy of the plugin?
@@ -1005,13 +976,13 @@ If the plugin in the snapshot repo ([http://snapshots.maven.codehaus.org/maven2]
Currently, this type of summary information is not built into the compiler plugin, but it would be possible to add. If this feature is important to you, add your vote to [MNG-1854](http://jira.codehaus.org/browse/MNG-1854).
-*Sites & Reporting*
+_Sites & Reporting_
### In a multi-module project, is there any way for Maven to build only those modules that have changed from the previous build and leave the unchanged modules alone (i.e. not build them)?
Currently, this is not possible. The main reason is that it's non-trivial to determine whether an entire project's build is stale (the project here being one of the modules). It will be dependent on the phase being called, and the packaging of the particular module.
-*Design, Patterns & Best Practices*
+_Design, Patterns & Best Practices_
### Where can I get the Maven plugin for Eclipse?
@@ -1019,7 +990,7 @@ Currently, this is not possible. The main reason is that it's non-trivial to det
There are some flash demos to show the user how to use the plugin.
-*IDEs*
+_IDEs_
### Handle special characters in site
@@ -1033,7 +1004,6 @@ Honor encoding
Default to ISO-8859-1
Configuration in pom
-
```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -1043,18 +1013,16 @@ Configuration in pom
</configuration>
</plugin>
```
-
On the solaris machine
In `$HOME/.profile`
`MAVEN_OPTS="-Xmx512m -Xms512m -Dfile.encoding=ISO-8859-1` (mx/ms not mandatory for m2 but for m1).
`LANG=en_US.ISO8859-15`
- *Sites & Reporting, IDEs*
+ _Sites & Reporting, IDEs_
### How do I generate sources with the antrun plug-in?
For instance to generate sources add the following to your plugins section
NOTE: this may only work in the latest plugin version in SVN
-
```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -1085,21 +1053,20 @@ NOTE: this may only work in the latest plugin version in SVN
</executions>
</plugin>
```
+ _Ant-related_
- *Ant-related*
### Where is the plugin-registry.xml?
From the settings.xml, you may enable it by setting `<usePluginRegistry/>` to true and the file will be in `~/.m2/plugin-registry.xml`
-*General, Plugins and Lifecycle*
+_General, Plugins and Lifecycle_
### Is there a way to specify a different output directory without having to edit the pom or configuration file each time I do a build?
Yes. You can make use of the pom's `<properties>` element to accomplish this.
To do so, simply add the following fragment to your pom:
-
```
<project>
...
@@ -1114,10 +1081,8 @@ To do so, simply add the following fragment to your pom:
...
</project>
```
-
Now, to specify a different output directory at runtime simply use the directory property as a mvn command line parameter;
{code}mvn -Ddirectory=tmp package
-
```
This will send the build's output files to the ${basedir}/tmp directory.
@@ -1146,7 +1111,7 @@ i.e.
</build>
...
</project>
-```
+```
### How do I change the default remote repository?
@@ -1164,12 +1129,11 @@ Define in your POM a repository with "central" as the repository id.
</repositories>
```
- *Repositories*
+ _Repositories_
### I have my web.xml in my customed directory layout for my webapp, but why am I getting the error "Deployment descriptor `<Path>\WEB-INF\web.xml` does not exist"?
You may specify the path of your web.xml in your webapp by configuring maven-war-plugin.
-
```
<build>
...
@@ -1184,7 +1148,8 @@ You may specify the path of your web.xml in your webapp by configuring maven-war
</plugins>
</build>
```
-*Errors, Deployment*
+_Errors, Deployment_
+
### Is it possible to specify multiple `<module>`(s) in a POM at a greater depth than 1 level?
@@ -1206,55 +1171,45 @@ Add the following at the top level POM:
...
<modules>
```
-
For the second solution:
Add the following at the top level POM:
-
```
<modules>
<module>B</module>
<modules>
```
-
And in directory A/B/, add an extra parent POM and add the following:
-
```
<modules>
<module>C</module>
<modules>
```
-
Both ways are effectively the same, but if you have that inheritance structure, the second gives a more natural grouping (eg, you can cd
into "B" and build all its subprojects only).
If you do the first solution, the children poms should have the following hint in the parent element:
-
```<parent>
...
<artifactId>A</artifactId>
<relativePath>../../pom.xml</relativePath>
</parent>
```
-
The repository is still used if ../../pom.xml is not found or the versions don't match, but the hint makes it easier to use local modifications without installing the parent.
-*POM*
+_POM_
### How to list all goals available for a certain plugin?
We can use the describe goal of maven-projecthelp-plugin to list the goals available, see sample syntax below.
-
```
mvn projecthelp:describe -Dplugin=org.apache.maven.plugins:maven-eclipse-plugin -Dfull=true
```
-
This would display all the goals and descriptions of the parameters used by maven-eclipse-plugin.
\\
To get a quick overview about available mojos you can use the 'help' mojo which automatically gets generated in newer plugins.
-
```
mvn [pluginname]:help
e.g. mvn eclipse:help
```
-*Plugins and Lifecycle, IDEs*
+_Plugins and Lifecycle, IDEs_
### What does aggregator mean in mojo?
@@ -1288,8 +1243,8 @@ You can use the Maven Help Plugin's describe goal. For example, to find out the
### How can I use Ant tasks in Maven?
There are currently 2 alternatives:
-- For use in a plugin written in Java, Beanshell or other Java-like scripting language, you can construct the Ant tasks [using the instructions given in the Ant documentation](http://ant.apache.org/manual/antexternal.html)
-- If you have very small amounts of Ant script specific to your project, you can use the [AntRun plugin](http://maven.apache.org/plugins/maven-antrun-plugin/index.html).
+* For use in a plugin written in Java, Beanshell or other Java-like scripting language, you can construct the Ant tasks [using the instructions given in the Ant documentation](http://ant.apache.org/manual/antexternal.html)
+* If you have very small amounts of Ant script specific to your project, you can use the [AntRun plugin](http://maven.apache.org/plugins/maven-antrun-plugin/index.html).
### Is it possible to create my own directory structure?
@@ -1299,7 +1254,7 @@ By configuring `<sourceDirectory>`, `<resources>` and other elements of the `<bu
In addition, you may need to change the plugin configuration if you are not using plugin defaults for their files/directories.
-### Where is the source code? I couldn't seem to find a link anywhere on the Maven site
+### Where is the source code? I couldn't seem to find a link anywhere on the Maven site.
The source code can be found in subversion: [http://svn.apache.org/repos/asf/maven/components/trunk].
@@ -1309,7 +1264,6 @@ For more information, see [Building Maven](http://maven.apache.org/guides/develo
Tests are run by the surefire plugin. The surefire plugin can be configured to run certain test classes and you may have unintentionally done so by specifying a value to $
{test}. Check your settings.xml and pom.xml for a property named "test" which would like this:
-
```
...
<properties>
@@ -1320,9 +1274,7 @@ Tests are run by the surefire plugin. The surefire plugin can be configured to r
</properties>
...
```
-
or
-
```
...
<properties>
@@ -1330,19 +1282,16 @@ or
</properties>
...
```
-
### Where are the Maven XSD schemas?
The Maven XSD is located here and the Maven Settings XSD is located here.
Your favorite IDE probably supports XSD schema's for pom.xml and settings.xml editing. You need to specify the following:
-
```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
...
</project>
```
-
```
<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 https://maven.apache.org/xsd/settings-1.0.0.xsd">
@@ -1360,7 +1309,7 @@ We have compiled a list of available resources on the [getting help page](http:/
The source for the model package is generated by modello. From your maven-model source, build it and you should able to see tha java files inside /target/generated-sources directory.
-### List of available Maven mirrors
+### List of available Maven mirrors.
Here is the list of available mirrors you can use, just use one of the following mirror entries in your settings.xml
@@ -1421,7 +1370,6 @@ Place also the commons-net jar to %M2_HOME%/lib.
### How can I have a child project not inherit a goal (like install) from the parent?
Use the `inherited` property. Set it to `false` in the plugin configuration. So for example, if you want your parent project to be installed but not your child, configure the install plugin like so:
-
```
<plugin>
<artifactId>maven-install-plugin</artifactId>
@@ -1448,7 +1396,6 @@ There are no tools.jar on a mac. The classes are included in the normal java run
Refer to this link [http://lists.apple.com/archives/java-dev/2002/Jun/msg00901.html] )
You only have to modify the `<systemPath>` pointing to your classes.jar on MacOSX.
-
```
<dependency>
<groupId>sun.jdk</groupId>
@@ -1462,7 +1409,6 @@ You only have to modify the `<systemPath>` pointing to your classes.jar on MacOS
### How do I include tools.jar in my dependencies?
The following code includes tools.jar on Sun JDKs (it is already included in the runtime for Mac OS X and some free JDKs).
-
```
...
<profiles>
@@ -1499,7 +1445,6 @@ there is already some discussion about this, Please refer to this links for more
### How to make a war artifact as a dependency?
When specifying a war as dependency, make sure that you have set the `<type>` to war.
-
```
<dependency>
<groupId><!-- groupId of the war --></groupId>
@@ -1513,7 +1458,6 @@ When specifying a war as dependency, make sure that you have set the `<type>` to
By default, the location of the generated jar is in `${project.build.directory}` or in your target directory.
We can change this by configuring the outputDirectory of maven-jar-plugin.
-
```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -1550,13 +1494,10 @@ Use `$project.artifact.resolvedVersion`.
### How do I get the top line of a table to be "headers" for that column in APT?
With the snapshot you can do:
-
```
](]( header 1 ](]( header 2 ](]( header 3 ](](
```
-
Example:
-
```
*----------------+----------------*--------------------------+
](]( header 1 ](]( ]( ](]( header 2 ](]( ]( ](]( header 2 ](](
@@ -1570,7 +1511,6 @@ cell1 ]( cell1 ]( cell3
Wagon is really for repository interaction, though it could be used for this.
To get the wagon:
-
```
/* @component roleHint="http" */
Wagon wagon;
@@ -1579,7 +1519,6 @@ Wagon wagon;
### How do I set the base directory for creating the packages created by assembly?
The assembly plugin, by default, saves the packages to your project.build.directory from your pom or
-
```
<project>
...
@@ -1590,14 +1529,12 @@ The assembly plugin, by default, saves the packages to your project.build.direct
...
</project
```
-
Also, you can have assembly plugin use a different directory by setting the plugin parameter `outputDirectory` to your desired directory.
More info about the assembly plugin can be found here: [http://maven.apache.org/plugins/maven-assembly-plugin/introduction.html]
### How do I filter which classes should be put inside the packaged jar?
All compiled classes are always put into the packaged jar. However, you can configure the compiler plugin to exclude compiling some of the java sources using the compiler parameter `excludes` as follows:
-
```
<project>
...
@@ -1626,7 +1563,6 @@ Use the assembly plugin goal {{assembly:attach}} to install the generated packag
### Is it possible to use HashMap as configurable parameter in a plugin? How do I configure that in pom.xml?
Yes. Its possible to use a HashMap field as a parameter in your plugin. To use it, your pom configuration should look like this:
-
```
<myMap>
<yourkey>yourvalue</yourkey>
@@ -1668,7 +1604,6 @@ If you don't want to change your system JAVA_HOME, set it in maven script instea
### Why does release prepare goal requires the project to be released be a snapshot? Is it possible to do a release prepare from a parent project? What about from a sub-project?
The release:prepare requires the project to be released be a snapshot because it follows the maven development process where: - during development, everyone works on snapshots
-
- at release time, the snapshot got changed to release version, checked back into SCM, labelled and then built.
- the version is then incremented with snapshot and checked into SCM again.
@@ -1679,7 +1614,6 @@ When performing release:prepare in a sub project, the parent cannot be in snapsh
### How can I create an archetype with resources mapped to the class files directory?
Specify the resources to be sources as shown below:
-
```
<sources>
<source>src/main/resources/sampleXml.xml</source>
@@ -1688,9 +1622,7 @@ Specify the resources to be sources as shown below:
```
### How do I add a description to the welcome page of the generated site when I execute mvn site?
-
Fille up the `<description>` in the pom.xml as shown below:
-
```
<project>
...
@@ -1752,6 +1684,7 @@ For an example, let's say you have a Java source at src/main/java/com/junk/JunkB
</tags>
```
+
### I don't have a domain name and I don't want use my employer's domain name. What should I name my plugin package?
How will the plugin be licensed? Is it intended to just be a binary distribution or will the source be available? Where will be the documentation be? How will people find out about it?
@@ -1775,9 +1708,7 @@ I think your choice is probably influenced by these questions. One option, of co
</pluginManagement>
</build>
```
-
Make sure the generated .classpath actually contains sourcepath attributes, like this:
-
```
<classpathentry kind="var"
path="M2_REPO/javax/servlet/servlet-api/ 2.4/servlet-api-2.4.jar"
@@ -1805,15 +1736,16 @@ Make sure the generated .classpath actually contains sourcepath attributes, like
</testResources>
```
+
### How can I stop this "WARNING While downloading artifactId-artifactId-version This artifact has been relocated to groupId-artifactId-version"?
It's probably because some other dependency has specified the dependency on artifactId:artifactId. It will only go away when that declaration is fixed in that POM.
-### I would like clarification on what version of the JDK is required for m2 - particularly with respect to creating Plugins
+### I would like clarification on what version of the JDK is required for m2 - particularly with respect to creating Plugins.
1.4 is required to run m2 there're problems when using 1.5 features in plugins. People tried and failed because qdox (used for some mojo stuff doesn't support new 1.5 language)
-### i'm wondering what a "snapshot" actually is
+### i'm wondering what a "snapshot" actually is.
A snapshot is a development version. e.g, 2.0-SNAPSHOT is thestill-in-development future 2.0.If you want to use a snapshot, just use `<version>` , e.g. `<version>2.0-SNAPSHOT</version>` . But first you must ensure that you have access to the repository containing this version.
@@ -1832,12 +1764,10 @@ The best practice guideline between settings.xml and pom.xml is that configurati
For example, `<repositories>` in pom.xml would tell all users of the project to use the `<repositories>` specified in the pom.xml. However, some users may prefer to use a mirror instead, so they'll put `<mirrors>` in their settings.xml so they can choose a faster repository server.
so there you go:
-
```
settings.xml > user scope
pom.xml > project scope
```
-
### What is reactorProjects? executedProject?
`${reactorProjects}` are the projects that the current mvn command are going to be built. This will include the parent project and all its children while `${executedProject}` is the project where you typed your mvn command.
@@ -1847,7 +1777,6 @@ pom.xml > project scope
A snapshot is a development version. e.g, 2.0-SNAPSHOT is the still-in-development future 2.0.
If you want to use a snapshot, juste use `<version>` , e.g. `<version>2.0-SNAPSHOT</version>`. But first you must ensure that you have access to
the repository containing this version. For example, for Maven snapshots as stated below, you could use :
-
```
<repositories>
<repository>
@@ -1856,9 +1785,7 @@ the repository containing this version. For example, for Maven snapshots as stat
</repository>
</repositories>
```
-
or, for plugins :
-
```
<pluginRepositories>
<pluginRepository>
@@ -1867,7 +1794,6 @@ or, for plugins :
</pluginRepository>
</pluginRepositories>
```
-
Please refer to the following links
[http://maven.apache.org/guides/getting-started/index.html#How%20do%20I%20make%20my%20first%20Maven%20project?]
[http://maven.apache.org/maven-model/maven.html#class_repository]
@@ -1885,7 +1811,6 @@ post with some examples of exclusions:
### If two versions of the same dependency are at the same depth, how do you know or predict which version will be used?
The order in which dependencies are declared effectively becomes the tie-breaker when two dependency versions are declared at the same depth...so if:
-
```
A -> B, C
B -> D (v2)
@@ -1902,13 +1827,12 @@ and A declares the following:
</dependency>
</dependencies>
```
-
Maven should choose D (v2) because B is declared first in the POM.
+
### How do I configure a project to use a specific version of a JDK?
Use the following plugin:
-
```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -1925,7 +1849,6 @@ Use the following plugin:
### Is there a way to use the current date in the POM?
Take a look at the buildnumber plugin. It can be used to generate a build date each time I do a build, as follows:
-
```<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>maven-buildnumber-plugin</artifactId>
@@ -1948,9 +1871,9 @@ Take a look at the buildnumber plugin. It can be used to generate a build date e
</executions>
</plugin>
```
-
The build date is available as $buildNumber in my POMs and resource files.
+
### What is the purpose of remote repository (other than ibilbilo)?
To store stuff that is not in ibiblio. An example of this is your own stuff.
@@ -1964,11 +1887,11 @@ Using mvn deploy, after inserting proper `<distributionManagement>` section into
Actually, simply copying the artifact to the repository is not the same as using deploy. The deploy goal will update various metadata files, create the md5 and sha1 checksum files, and can optionally create missing POM files etc along with actually copying the artifact file.
So there is a significant difference between the copying the file and using deploy.
+
### When I run mvn release:prepare, I get a build failure saying "Unable to tag SCM, File (...) already exists". However, the tag does not exist. What is wrong?
The full failure will look something like this:
'/stuff/tags/example/pom.xml'
-
```
[INFO\] Tagging release with the label stuff-1.0.0...
[INFO\] Executing: svn \--non-interactive copy \--file C:\DOCUME~1\G980143\LOCALS~1\Temp\maven-scm-1259783654.commit . http://www.example.com/subversion/repo/example/tags/stuff-1.0.0
@@ -1983,7 +1906,6 @@ Command output:
svn: Commit failed (details follow):
svn: File 'subversion/repo/example/tags/stuff-1.0.0/pom.xml' already exists
```
-
This will only happen in Subversion 1.5.x, and is due to a "changed behavior" in Subversion 1.5.0 and upwards. Maven and Subversion people have at the time og writing not agreed upon who should fix it. A workaround is to downgrade Subversion to version 1.4.4 and use that. Another is to manually copy the trunk/release branch to the tags directory, commit the change and then edit the release.properties file to reflect the fact that tagging has been done.
### How do I filter resources in the war?
@@ -2003,16 +1925,15 @@ For information on this topic please visit: [http://maven.apache.org/guides/mini
If you want to read a pom file, you can use the MavenXpp3Reader#read(... ).
But if you simply want to get the version of your currently running maven project inside your pom ( which is usually the case ), you can simply do:
-
```
/**
* @parameter expression="${project.version}"
*/
private String version;
```
-
Also, if you have a maven project (similar to the contents of its pom except that inheritance is already applied ) and want to get its version, you can use MavenProject#getVersion().
+
### How can I add two different source-directories to a project?
You can do this by using the maven-buildhelper-plugin. It allows you to add additional source directories.
@@ -2024,7 +1945,6 @@ You can do this by using the maven-buildhelper-plugin. It allows you to add addi
<myproperty>propertyvalue</myproperty>
</properties>
```
-
Then `$myproperty=propertyvalue`
### How do replace `<attainGoal>` from m1 in m2?
diff --git a/content/markdown/glossary.md b/content/markdown/glossary.md
index 188e9452..fcb73cab 100644
--- a/content/markdown/glossary.md
+++ b/content/markdown/glossary.md
@@ -21,54 +21,54 @@ This document describes some of the most common terms encountered while
using Maven. These terms, that have an explicit meaning for Maven, can
sometimes be confusing for newcomers.
-- **Project**: Maven thinks in terms of projects. Everything that you
+- **Project**: Maven thinks in terms of projects. Everything that you
will build are projects. Those projects follow a well defined
"Project Object Model". Projects can depend on other projects, in
which case the latter are called "dependencies". A project may
consist of several subprojects, however these subprojects are
still treated equally as projects.
-- **Project Object Model (POM)**: The Project Object Model, almost
+- **Project Object Model (POM)**: The Project Object Model, almost
always referred as the POM for brevity, is the metadata that Maven
needs to work with your project. Its name is "project.xml" and it is
located in the root directory of each project.
-- **Artifact**: An artifact is something that is either produced or
+- **Artifact**: An artifact is something that is either produced or
used by a project. Examples of artifacts produced by Maven for a
project include: JARs, source and binary distributions, WARs. Each
artifact is identified by a `group id`, an
artifact ID, a version, an extension and a classifier
(extension+classifier may be named by a [type](/ref/current/maven-core/artifact-handlers.html)).
-- **GroupId**: A group ID is a universally unique identifier for a
+- **GroupId**: A group ID is a universally unique identifier for a
project. While this is often just the project name (eg.
`commons-collections`), it is helpful to use a fully-qualified
package name to distinguish it from other projects with a similar
name (eg. `org.apache.maven`).
-- **Dependency**: A typical Java project relies on libraries to build
+- **Dependency**: A typical Java project relies on libraries to build
and/or run. Those are called "dependencies" inside Maven. Those
dependencies are usually other projects' JAR artifacts, but are
referenced by the POM that describes them.
-- **Plug-in**: Maven is organized in plugins. Every piece of
+- **Plug-in**: Maven is organized in plugins. Every piece of
functionality in Maven is provided by a plugin. Plugins provide
goals and use the metadata found in the POM to perform their task.
Examples of plugins are: jar, eclipse, war. Plugins are primarily
written in Java, but Maven also supports writing plug-ins in
Beanshell and Ant Scripting.
-- **Mojo**: A plugin written in Java consists of one or more mojos. A
+- **Mojo**: A plugin written in Java consists of one or more mojos. A
mojo is a Java class that implements the
org.apache.maven.plugin.Mojo interface. This means that a mojo is
the implementation for a **goal** in a plugin.
-- **Repository**:
+- **Repository**:
Refer to [Introduction to
Repositories](./guides/introduction/introduction-to-repositories.html)
-- **Snapshots**: Projects can (and should) have a special version
+- **Snapshots**: Projects can (and should) have a special version
including `SNAPSHOT` to indicate that they are a "work in progress",
and are not yet released. When a snapshot dependency is encountered,
it is always looked for in all remote repositories, and downloaded
@@ -79,15 +79,17 @@ sometimes be confusing for newcomers.
`1.1-SNAPSHOT`, indicating development that will be released as 1.1
(i.e. newer than 1.0, but not yet 1.1).
-- **APT**: APT is a wiki-like format of documentation that Maven
+- **APT**: APT is a wiki-like format of documentation that Maven
currently understands.
For information on how to create APT files, refer to the [Guide to
creating a site](./guides/mini/guide-site.html) document.
-- **XDoc**: XDoc is the format of documentation that Maven currently
+- **XDoc**: XDoc is the format of documentation that Maven currently
understands. It is quite simple, and allows embedding XHTML within a
simple layout that is transformed into a uniform site.
For information on how to create XDoc files, refer to the [Guide to
creating a site](./guides/mini/guide-site.html) document.
+
+
diff --git a/content/markdown/guides/development/guide-building-maven.md b/content/markdown/guides/development/guide-building-maven.md
index c1819f9d..b1d38bc3 100644
--- a/content/markdown/guides/development/guide-building-maven.md
+++ b/content/markdown/guides/development/guide-building-maven.md
@@ -23,60 +23,93 @@ under the License.
## Building Maven
+
### Why would I want to build Maven?
+
Building Maven (or a plugin, or any component) yourself is for one of two reasons:
-- to try out a bleeding edge feature or bugfix (issues can be found in [JIRA](/issue-management.html)),
-- to fix a problem you are having and submit a patch to the developers team.
+
+ - to try out a bleeding edge feature or bugfix (issues can be found in [ JIRA](/issue-management.html)),
+
+ - to fix a problem you are having and submit a patch to the developers team.
+
+
### Checking out the sources
+
All of the source code for Maven and its related libraries is in managed in the ASF source code repositories: for details, see [https://maven.apache.org/scm.html](/scm.html).
+
+
### Building Maven
+
#### Building a Maven Plugin or Component
+
Building a Maven plugin or component is like any Maven build:
+
+
```
mvn install
```
##### Running Integration Tests
+
Before submitting a patch, it is advised to run the integration tests, which are available in the `run-its` profile:
+
+
```
mvn -Prun-its install
```
+
+
#### Building Maven core
+
Until Maven 3.3, Maven core build could be boostrapped with an Ant build. This bootstrap has been removed in Maven 3.5: you need a pre-built Maven to build Maven from source.
+
To do this, run from the source directory:
+
+
```
mvn install
```
The assemblies will be created in `apache-maven`, and can be manually unzipped to the location where you'd like the resulting Maven installed.
+
If you want to have the resulting Maven directly copied to a directory, you can use the `distributionTargetDir` property:
+
+
```
mvn -DdistributionTargetDir="$HOME/app/maven/apache-maven-SNAPSHOT" install
```
##### Running the full Maven core integration tests
+
Before checking in a change or submitting a patch to Maven core, it is required to run the core integration tests. Using your local build of Maven, run:
+
+
```
mvn test -Prun-its
```
Consult [Core ITs documentation](/core-its/) for more options.
+
+
+
+
+
diff --git a/content/markdown/guides/development/guide-committer-school.md b/content/markdown/guides/development/guide-committer-school.md
index 227a7abd..507f92dd 100644
--- a/content/markdown/guides/development/guide-committer-school.md
+++ b/content/markdown/guides/development/guide-committer-school.md
@@ -24,36 +24,52 @@ under the License.
<!-- Original post: http://javaadventure.blogspot.nl/2012/07/do-you-want-to-become-maven-committer.html -->
## Do you want to become a Maven Committer?
+
The Apache Software Foundation is a meritocracy. By this we mean that you gain status based on the merit of your work and actions. In fact the status that you gain is a recognition of the merit of your work and actions.
+
Maven is an Apache project, that means that we have to follow the Apache rules and way. One of those rules is that we cannot hand out commit access to anyone who asks for it.
+
To gain commit access you must establish your merit by submitting patches that get picked up by existing committers.
+
After you have contributed enough patches to establish merit, the project management committee decides whether you can be trusted with commit access.
+
_The reality is that "It is what it is"TL;DR To become a Maven committer write good patches and get them applied._
+
+
## What makes a good patch?
+
A good patch is a patch that applies cleanly and includes tests that cover both the positive and negative case and has documentation where relevant.
+
For example, if you were implementing a patch to fix [MNG-4612](http://issues.apache.org/jira/browse/MNG-4612) you would first need to write a test case that is failing when trying to encrypt
+
+
```
{DESede}y+qq...==
```
and a second test case that is passing when trying to encrypt
+
+
```
password
```
This is in order to be sure that you have written an effective test case that can pass for good data. Then you implement the fix and all the tests should pass. You then take a Subversion compatible† diff of the source code and attach that to the issue in question.
+
To understand how your patch gets evaluated, here is how I apply patches:
+
+
1 I look at the actual diff, if there is a whole lot of formatting changes irrelevant to the issue being fixed => **Patch is no good, ask on JIRA for a clean patch**
1 I look at the list of files in the diff, if there are no tests => **Patch is no good, ask on JIRA for test cases**
@@ -68,24 +84,37 @@ password
1 I apply the patch a second time and run the tests. If the tests all pass => **Patch is good, I commit the patch and mark the JIRA as resolved**
+
So there you have it, my guide to writing good patches... now the next step is getting your patches noticed...
+
+
## How to get your patches noticed
+
The simplest way to get your patches noticed is to submit them to the JIRA issue that they fix.
- Remember that the Maven project is run by volunteers in their spare time, so very often we may not notice your patch for a few days.
+
+ Remember that the Maven project is run by volunteers in their spare time, so very often we may not notice your patch for a few days.
+
If you are certain that your patch is a good patch, and a week has passed with no comments on JIRA, then you should send _one and only one_ email to the [dev@maven.apache.org](mailto:dev@maven.apache.org) mailing list to see if your patch can get noticed.
+
**Note:** you need to be fairly confident that your patch is a good patch, because if you keep on pestering the Maven developers looking to have non-good patches applied, your merit will become negative and people will be less inclined to help you get your patches applied... also this is why you should send one and _only one_ email about your patch on any specific JIRA issue.
+
+
## Stephen, Arnaud & Barrie's school for potential Maven committers
- To help people who are interested in becoming Maven committers fulfill their goals, myself, Arnaud Heritier and Barrie Treloar (along with any other current Maven committers who decide to help) will be running an assignment based class to help people become committers.
+
+ To help people who are interested in becoming Maven committers fulfill their goals, myself, Arnaud Heritier and Barrie Treloar (along with any other current Maven committers who decide to help) will be running an assignment based class to help people become committers.
+
To register for the class you need to complete the following steps:
+
+
1 Read the [Apache Individual Contributor License Agreement](http://www.apache.org/licenses/icla.txt). When you graduate from the class you will be required to sign this in order to become a committer.
1 Subscribe to the [dev@maven.apache.org](mailto:dev@maven.apache.org) mailing list.
@@ -100,8 +129,12 @@ If anyone knows any issues that I could take a look at I would be very much appr
Thanks
```
+
+
Once you have registered your class assignments are basically to find JIRA issues that you want to fix. The issues can be in any part of Maven, but it is best to start with the areas you have the most interest in. Once you have found a JIRA issue that you are interested in fixing, the process will work a little something like this:
+
+
1 Make sure that nobody else is working on the issue and that the issue is one that should be fixed by sending an email to the list with a Subject line something like: `\[Committer School\] Should I fix MNG-4612?` The Message body should be something like:
```
@@ -114,6 +147,7 @@ Is that the correct way to go about fixing it and is it a real issue at all
Thanks
```
+
1 Wait a couple of days. Arnaud, Barrie and I will do our best to respond quickly to all such emails, but please keep in mind that we are doing this in our spare time.
1 If you get the all clear, develop your patch and upload it to the JIRA, after it is uploaded, send an email to the list with a subject line something like: `\[Committer School\] Patch for review: MNG-4612` The Message body should be something like:
@@ -124,10 +158,17 @@ I have tested that this is a good patch and I would appreciate if a committer co
Thanks
```
- Keep in mind that the Committer School is just a way for us to identify people who are committed to developing patches with a view to eventually becoming committers.
+
+
+ Keep in mind that the Committer School is just a way for us to identify people who are committed to developing patches with a view to eventually becoming committers.
+
When we have enough evidence that we think we can get you accepted as a committer we will nominate you and hopefully your nomination will be accepted.
+
Personally, if I see somebody averaging a good patch a week for 2-3 months and being active helping out on the [users@maven.apache.org](mailto:users@maven.apache.org) and [dev@maven.apache.org](mailto:dev@maven.apache.org) mailing lists then I think I could make a strong case for such a person being given commit access.
+
So if you think you have the right stuff and want to become a Maven committer... class enrollment is open!
+
+
diff --git a/content/markdown/guides/development/guide-documentation-style.md b/content/markdown/guides/development/guide-documentation-style.md
index 62813733..8d83b9b6 100644
--- a/content/markdown/guides/development/guide-documentation-style.md
+++ b/content/markdown/guides/development/guide-documentation-style.md
@@ -23,24 +23,36 @@ under the License.
## Guide To Maven Documentation Style
+
### Where did the style came from?
+
The documentation style guide was created to make our documentation more consistent and also to apply best practices to the documentation as well. The standard has just been started and will expand over time based on the suggestions made on the Maven dev mailing list. It is a community consensus of how we should write our documentation.
+
Each rule in this guide should come with a motivation as to why it exists. References to external sources are encouraged.
+
+
### Date format
+
How people format a date varies around the world, sometimes making it hard for people to understand each other. The solution to this problem comes in the form of the ISO-8601 standard.
+
A date in our documentation must follow this standard:
+
**YYYY-MM-DD**
+
where **YYYY** is the year in the Gregorian calendar, **MM** is the month of the year between 01 (January) and 12 (December), and **DD** is the day of the month between 01 and 31.
+
**Note**: All documentation meta-data should respect this convention, for instance for this given APT document:
+
+
```
------
Guide To Maven Documentation Style
@@ -53,26 +65,37 @@ under the License.
#### References
-- [W3C Quality Web Tips](http://www.w3.org/QA/Tips/iso-date)
-- [ISO-8601](http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26780)
-- [Wikipedia](http://en.wikipedia.org/wiki/ISO_8601)
+ - [W3C Quality Web Tips](http://www.w3.org/QA/Tips/iso-date)
+
+ - [ISO-8601](http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26780)
+
+ - [Wikipedia](http://en.wikipedia.org/wiki/ISO_8601)
+
<!-- NOTE: Add more rules here. Follow the heading style of the rule above. -->
+
### POM Snippet
+
A POM file must use 2 spaces for each indentation. Because POM snippets are often used in documentation to show the user how to configure something, it is important that these snippets aren't too wide. If they are too wide, the page is difficult to read on a smaller screen.
+
When you use a snippet of XML from the POM as an example in documentation, make sure that the example is properly indented. A user should be able to copy and paste the example into their own POM without changing the indentation.
+
Also, you should declare all parent POM elements to improve the comprehension. You could use ellipsis (i.e. ...) if you don't want to specify elements.
+
#### Example
+
The following is an example of how the distribution management of the Maven site is configured.
+
+
```
<project>
...
@@ -88,20 +111,36 @@ under the License.
As you can see above the `<distributionManagement>` element is indented once (=2 spaces), the `<site>` element is indented twice (=4 spaces), and the `<id>` is indented three times (=6 spaces).
+
+
+
### Naming Documentation Files
+
All file names should replace space by a hyphen (-), for instance for this given APT document:
+
+
```
guide-documentation-style.apt
```
+
### Updating Documentation Files
+
A good practice is to update the date (with the correct date format) when you are updating documentation files.
+
+
### Write Thinking
+
Here are some pointers about English rules when typing material:
-- [Wikipedia:Manual of Style](https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style), specifically [Punctuation Part](https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Punctuation)
+
+
+ - [Wikipedia:Manual of Style](https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style), specifically [Punctuation Part](https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Punctuation)
+
+
+
diff --git a/content/markdown/guides/development/guide-helping.md b/content/markdown/guides/development/guide-helping.md
index 83734af5..4ffc01f9 100644
--- a/content/markdown/guides/development/guide-helping.md
+++ b/content/markdown/guides/development/guide-helping.md
@@ -23,61 +23,85 @@ under the License.
## Guide to helping with Maven
+
As with any open source project, there are several ways you can help:
-- Join the [mailing lists](../../mailing-lists.html) and answer other user's questions.
-- Report bugs, feature requests and other issues in the [issue management system](../../issue-management.html).
-- [Build Maven](./guide-building-maven.html) for yourself, in order to fix bugs.
+ - Join the [mailing lists](../../mailing-lists.html) and answer other user's questions.
+
+ - Report bugs, feature requests and other issues in the [issue management system](../../issue-management.html).
+
+ - [ Build Maven](./guide-building-maven.html) for yourself, in order to fix bugs.
-- [Submit patches](./guide-maven-development.html#Creating_and_submitting_a_patch) to reported issues (both those you find, or that others have filed)\
+ - [Submit patches](./guide-maven-development.html#Creating_and_submitting_a_patch) to reported issues (both those you find, or that others have filed)\
To ease your first contribution, we have a [list of "up for grabs" issues](https://s.apache.org/for-the-grabs_maven), meaning that they should be easy to work on.
-- [test releases](./guide-testing-releases.html) help test releases that are being voted on (see the dev@maven.apache.org [mailing list](../../mailing-lists.html) for release votes)
+ - [ test releases](./guide-testing-releases.html) help test releases that are being voted on (see the dev@maven.apache.org [ mailing list](../../mailing-lists.html) for release votes)
-- [test snapshot plugins](./guide-testing-development-plugins.html) help test the latest development versions of plugins and report issues
+ - [ test snapshot plugins](./guide-testing-development-plugins.html) help test the latest development versions of plugins and report issues
+
+ - Help with the documentation by pointing out areas that are lacking or unclear, and if you can, submitting Pull Requests to correct it: use the "edit" button in the breadcrumb, just after the page title. You can also create appropriate issues [by using the issue management system](https://issues.apache.org/jira/browse/MNGSITE).
-- Help with the documentation by pointing out areas that are lacking or unclear, and if you can, submitting Pull Requests to correct it: use the "edit" button in the breadcrumb, just after the page title. You can also create appropriate issues [by using the issue management system](https://issues.apache.org/jira/browse/MNGSITE).
Your participation in the community is much appreciated!
+
+
## Why Would I Want to Help?
+
There are several reasons these are good things.
-- By answering other people's questions, you can learn more for yourself
-- By submitting your own fixes, they get incorporated faster
-- By reporting issues, you ensure that bugs don't get missed, or forgotten
+ - By answering other people's questions, you can learn more for yourself
+
+ - By submitting your own fixes, they get incorporated faster
+
+ - By reporting issues, you ensure that bugs don't get missed, or forgotten
+
+ - You are giving back to a community that has given you software for free
+
-- You are giving back to a community that has given you software for free
## How do I Join the Project?
+
Projects at Apache operate under a meritocracy, meaning those that the developers notice participating to a high extent will be invited to join the project as a committer.
+
This is as much based on personality and ability to work with other developers and the community as it is with proven technical ability. Being unhelpful to other users, or obviously looking to become a committer for bragging rights and nothing else is frowned upon, as is asking to be made a committer without having contributed sufficiently to be invited.
+
+
## Developers Conventions
+
There are a number of conventions used in the project, which contributors and developers alike should follow for consistency's sake.
-- [Maven Code Style And Convention](../../developers/conventions/code.html)
-- [Maven Jira Convention](../../developers/conventions/jira.html)
-- [Maven Git Convention](../../developers/conventions/git.html)
+ - [Maven Code Style And Convention](../../developers/conventions/code.html)
+
+ - [Maven Jira Convention](../../developers/conventions/jira.html)
+
+ - [Maven Git Convention](../../developers/conventions/git.html)
+
+ - [Releasing a Maven project](../../developers/release/index.html)
+
+ - [Apache Maven Wiki](https://cwiki.apache.org/confluence/display/MAVEN/Index)
-- [Releasing a Maven project](../../developers/release/index.html)
-- [Apache Maven Wiki](https://cwiki.apache.org/confluence/display/MAVEN/Index)
## Resources for committers
-- [Developer Resources](http://www.apache.org/dev/)
-- [About the Apache Software Foundation](http://www.apache.org/foundation/)
-- [Committer FAQ](http://www.apache.org/dev/committers.html)
+ - [ Developer Resources](http://www.apache.org/dev/)
+
+ - [ About the Apache Software Foundation](http://www.apache.org/foundation/)
+
+ - [ Committer FAQ](http://www.apache.org/dev/committers.html)
+
+
diff --git a/content/markdown/guides/development/guide-maven-development.md b/content/markdown/guides/development/guide-maven-development.md
index fc79cb27..e9eb31b9 100644
--- a/content/markdown/guides/development/guide-maven-development.md
+++ b/content/markdown/guides/development/guide-maven-development.md
@@ -23,113 +23,184 @@ under the License.
## Developing Maven
+
This document describes how to get started developing Maven itself. There is a separate page describing how to [build Maven](./guide-building-maven.html).
+
### Finding some work to do
+
First of all you need something to work on! Issues can be found in [several JIRA projects](/issue-management.html).
- Another good place to look for work is the [Up for grabs](https://s.apache.org/up-for-grabs_maven) list. This list contains relatively simple issues that can be worked on without a lot of prerequisite knowledge.
+
+ Another good place to look for work is the [ Up for grabs](https://s.apache.org/up-for-grabs_maven) list. This list contains relatively simple issues that can be worked on without a lot of prerequisite knowledge.
+
When you find a issue you would like to work on, add a comment in the issue log so the core developers and other people looking for work know that someone is already working on it.
+
+
### Where's the source?
- See [https://maven.apache.org/scm.html](/scm.html) for information. The Maven project uses the Apache GitBox Repositories, and all of them are dual-mirrored to [GitHub](https://github.com/apache/).
-### Don't forget tests
+ See [https://maven.apache.org/scm.html](/scm.html) for information. The Maven project uses the Apache GitBox Repositories, and all of them are dual-mirrored to [ GitHub](https://github.com/apache/).
+
+
+
+### Don't forget tests!
+
<!-- TODO move details to guide-building-maven.apt, keep only principles here -->
You will find many unit tests. If at all possible, create or modify a unit test to demonstrate the problem, and then validate your fix.
+
If you need to mock a class to write a test, use the Mockito framework. Parts of the Maven codebase predate Mockito so you will encounter existing tests that use EasyMock, PowerMock, and JMock. However, all newly written mocks should use Mockito, even if this means a module or a single class uses multiple mocking frameworks. If an existing test class has complicated legacy mock setup, you can add new Mockito based tests in a new test class. There is no requirement that all tests for a s [...]
+
If the problem case can't be set up in the unit tests, add an integration test. Before submitting a patch, in any case, you should run all of the integration tests. The tests require an empty local repository. See [Core IT Suite documentation](/core-its/core-it-suite/) for more details.
+
+
### Creating and submitting a patch
+
The most convenient way is to create a GitHub fork from the Git repository you are working with. When you have either completed an issue or just want some feedback on the work you have done, create a pull request. We have a couple of guidelines when submitting contributions:
-- Verify the status of the `master` branch on [Maven CI](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-master-jobs.html). If it is not SUCCCESS, then first try to figure out the problem, don't start with your own issue yet! You can use `git bisect` to figure out the problematic commit and help with that committer to solve the problem.
-- Create your branch from `master`, not from a tag. Otherwise, your patch is outdated the moment you create it and might not be applicable to the development head.
-- If this was a new piece of work without a JIRA issue, create a JIRA issue for it now.
+ - Verify the status of the `master` branch on [Maven CI](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-master-jobs.html). If it is not SUCCCESS, then first try to figure out the problem, don't start with your own issue yet! You can use `git bisect` to figure out the problematic commit and help with that committer to solve the problem.
+
+ - Create your branch from `master`, not from a tag. Otherwise, your patch is outdated the moment you create it and might not be applicable to the development head.
+
+ - If this was a new piece of work without a JIRA issue, create a JIRA issue for it now.
-- Name the branch after the issue number; the branch name would start with `<jira-project-id>-<ticket-id>`.
+ - Name the branch after the issue number; the branch name would start with `<jira-project-id>-<ticket-id>`.
-- Push your branch with the commit(s) to your fork.
+ - Push your branch with the commit(s) to your fork.
+
+ - Create a [ pull request](https://help.github.com/en/articles/about-pull-requests) to submit your contribution. Shortly after, someone will review the pull request and give you feedback on it.
-- Create a [pull request](https://help.github.com/en/articles/about-pull-requests) to submit your contribution. Shortly after, someone will review the pull request and give you feedback on it.
A short note:
-- Make sure that you follow our code style, see [Further Links](#further-links).
+
+
+ - Make sure that you follow our code style, see [Further Links](#further-links).
+
+
### Pull request acceptance criteria
+
There are a number of criteria that a pull request will be judged on:
-- Whether it works and does what is intended. This one is probably obvious!
-- Whether it fits the spirit of the project. Some pull requests may be rejected as they take the project in a different direction than the current development community has chosen. This is usually discussed on an issue well before a pull request is contributed, so if you are unsure, discuss it there or on the mailing lists first. Feel free to continue discussing it (with new justification) if you disagree, or appeal to a wider audience on the mailing lists.
-- Whether it contains tests. It is expected that any pull request relating to functionality will be accompanied by unit tests and/or integration tests. It is strongly desired (and will be requested) for bug fixes too, but will not be the basis for not applying it. At a bare minimum, the change should not decrease the amount of automated test coverage. As a community, we are focusing on increasing the current coverage, as there are several areas that do not receive automated testing.
+ - Whether it works and does what is intended. This one is probably obvious!
+
+ - Whether it fits the spirit of the project. Some pull requests may be rejected as they take the project in a different direction than the current development community has chosen. This is usually discussed on an issue well before a pull request is contributed, so if you are unsure, discuss it there or on the mailing lists first. Feel free to continue discussing it (with new justification) if you disagree, or appeal to a wider audience on the mailing lists.
+
+ - Whether it contains tests. It is expected that any pull request relating to functionality will be accompanied by unit tests and/or integration tests. It is strongly desired (and will be requested) for bug fixes too, but will not be the basis for not applying it. At a bare minimum, the change should not decrease the amount of automated test coverage. As a community, we are focusing on increasing the current coverage, as there are several areas that do not receive automated testing.
+
+ - Whether it contains documentation. All new functionality needs to be documented for users, even if it is very rough for someone to expand on later. While rough is acceptable, incomplete is not. As with automated testing, as a community we are striving to increase the current coverage of documentation.
-- Whether it contains documentation. All new functionality needs to be documented for users, even if it is very rough for someone to expand on later. While rough is acceptable, incomplete is not. As with automated testing, as a community we are striving to increase the current coverage of documentation.
Above all, don't be discouraged. These are the same requirements the current committers should hold each other to as well. And remember, your contributions are always welcome!
+
+
### Related Projects
+
Maven has a few dependencies on other projects:
-- **Plexus**
+
+
+ - **Plexus**
Plexus is a full-fledged container supporting different kinds of component lifecycles. Its native lifecycle is like any other modern IoC container, using field injection of both requirements and configuration. All core Maven functionality are Plexus components.
+
+
You can [read more about Plexus](https://codehaus-plexus.github.io/).
-- **Modello**
+
+
+ - **Modello**
Modello is a simple tool for representing an object model and generating code and resources from the model. Maven uses Modello to generate all Java objects, XML readers and writers, XML Schema, and HTML documentation.
+
+
You can [read more about Modello](https://codehaus-plexus.github.io/modello/).
-- **Mojo**
+
+
+ - **Mojo**
"Mojo" is really two things when it comes to Maven: it is both [Maven's plug-in API](/ref/current/maven-plugin-api/) and also [a separate Mojohaus project](http://www.mojohaus.org) hosting a lot of plugins.
+
+
[The MojoHaus Project](http://www.mojohaus.org) is a plugin forge for non-core Maven plugins. There is also a lower bar for becoming a part of the project.
+
+
+
+
### Sub Projects
-- **Maven Surefire**
+
+
+ - **Maven Surefire**
Surefire is a testing framework. It can run regular JUnit tests so you won't have to change anything in your code to use it. It supports scripting tests in BeanShell and Jython and has special "batteries" for writing acceptance and functional tests for the web and for testing XML-RPC code.
+
+
You can [read more about Surefire](/surefire/).
-- **Maven Doxia**
+
+
+ - **Maven Doxia**
Doxia is Maven's documentation engine. It has a sink and parser API that can be used to plug in support for input and output documents.
+
+
You can read more about [Doxia](/doxia/) and the currently supported [document formats](/doxia/references/index.html).
-- **Maven SCM**
+
+
+ - **Maven SCM**
Maven SCM (Source Control Management) is a reusable API which is independent of Maven itself. It is used by the SCM related Maven Plugins. The core part of Maven doesn't depend on Maven SCM.
+
+
You can [read more about Scm](/scm/).
-- **Maven Wagon**
+
+
+ - **Maven Wagon**
Maven Wagon is a standalone API that dealt with transporting files and directories in Maven 2.x. Maven Core today uses the Resolver Transport API, that among other implementations, contains a wrapper for Wagon as well. Also, the site plug-in uses it to publish the site.
+
+
You can [read more about Wagon](/wagon/).
+
+
+
+
### Further Links
-- [Maven Code Style And Code Convention](../../developers/conventions/code.html)
-- [Maven JIRA Convention](../../developers/conventions/jira.html)
+
+ - [Maven Code Style And Code Convention](../../developers/conventions/code.html)
+
+ - [Maven JIRA Convention](../../developers/conventions/jira.html)
+
+
+
diff --git a/content/markdown/guides/development/guide-plugin-documentation.md b/content/markdown/guides/development/guide-plugin-documentation.md
index 8c3d1e7a..24d4b3d3 100644
--- a/content/markdown/guides/development/guide-plugin-documentation.md
+++ b/content/markdown/guides/development/guide-plugin-documentation.md
@@ -22,19 +22,31 @@ under the License.
-->
## Introduction
+
### Where did the standard come from?
- The plugin documentation standard was created to address the frequent complain of lack of documentation, specifically on the Maven plugins. The standard was based on the suggestions made on the Maven dev mailing list with some refinements. It is a community consensus of what basic documentation a Maven plugin should have.
+
+ The plugin documentation standard was created to address the frequent complain of lack of documentation, specifically on the Maven plugins. The standard was based on the suggestions made on the Maven dev mailing list with some refinements. It is a community consensus of what basic documentation a Maven plugin should have.
+
+
### Why do we need a documentation standard?
+
The standard is not a set of rules but a guide to help plugin developers document their plugins better, for the benefit of the users of the plugin. The standard also reminds the plugin developers of the important details that needs to be documented, to help speed up the adoption of the plugin.
-## Generated Documentation
- It is recommended that you let Maven generate the basic information for the plugin to make sure that that the basic information is always accurate and synchronized with the plugin implementation.
- Documentation is generated by running
+
+## Generated Documentation
+
+
+ It is recommended that you let Maven generate the basic information for the plugin to make sure that that the basic information is always accurate and synchronized with the plugin implementation.
+
+
+ Documentation is generated by running
+
+
```
mvn site
@@ -42,37 +54,48 @@ mvn site
It will generate a plugin site based on the information in the POM, `src/site` and other reporting plugins configured in the POM. The most important reporting plugin is the [Maven Plugin Plugin](/plugins/maven-plugin-plugin/) which will generate the documentation for each plugin goal based on the mojo annotations. But in order for the generated site to be usable, the required information should be available to the Maven Site Plugin.
+
### POM Elements
+
Maven extracts the information from the POM to generate the pages under Project Information. The first step in having a good documentation is to have an accurate and visible basic project information, Maven can provide this for the plugin as long as the information in the POM is complete, descriptive and accurate.
+
#### Required Elements
+
Minimum elements for a valid POM:
-- `<modelVersion>` - POM model version, currently 4.0.0
-- `<groupId>` - the package name
-- `<artifactId>` - artifact name
+ - `<modelVersion>` - POM model version, currently 4.0.0
+
+ - `<groupId>` - the package name
-- `<packaging>` - type of artifact produced by the POM
+ - `<artifactId>` - artifact name
-- `<version>` - the plugin version
+ - `<packaging>` - type of artifact produced by the POM
+
+ - `<version>` - the plugin version
+
+
+
+#### Optional Elements
-#### Optional Elements
These might be optional elements in a valid POM but they are important basic project information required by the users to effectively use the plugin:
-- `<name>` - plugin's name, _Maven NNN Plugin_ for plugins hosted at the Maven project or _NNN Maven Plugin_ for all others
-- `<description>` - project description, an overview of what the plugin can do
-- `<url>` - the site of the plugin, normally _maven.apache.org_ or _org.mojohaus_
+ - `<name>` - plugin's name, _Maven NNN Plugin_ for plugins hosted at the Maven project or _NNN Maven Plugin_ for all others
+
+ - `<description>` - project description, an overview of what the plugin can do
-- `<prerequisites>` - the minimum version of Maven required to use this plugin
+ - `<url>` - the site of the plugin, normally _maven.apache.org_ or _org.mojohaus_
-- `<issueManagement>` - describes the system used for reporting problems and modification requests
+ - `<prerequisites>` - the minimum version of Maven required to use this plugin
+
+ - `<issueManagement>` - describes the system used for reporting problems and modification requests
```
<project>
@@ -85,9 +108,10 @@ mvn site
</project>
```
-- `<inceptionYear>` - year the plugin was first created
-- `<mailingLists>` - lists where other users or the developers can be contacted for help and discussions
+ - `<inceptionYear>` - year the plugin was first created
+
+ - `<mailingLists>` - lists where other users or the developers can be contacted for help and discussions
```
<project>
@@ -108,7 +132,8 @@ mvn site
</project>
```
-- `<licenses>` - plugin license
+
+ - `<licenses>` - plugin license
```
<project>
@@ -124,7 +149,8 @@ mvn site
</project>
```
-- `<scm>` - the source code management configuration - a plugin without this would raise suspicion, might not be OSS
+
+ - `<scm>` - the source code management configuration - a plugin without this would raise suspicion, might not be OSS
```
<project>
@@ -138,7 +164,8 @@ mvn site
</project>
```
-- `<organization>` - the organization maintaining the plugin, just in case we need someone to blame
+
+ - `<organization>` - the organization maintaining the plugin, just in case we need someone to blame
```
<project>
@@ -151,10 +178,17 @@ mvn site
</project>
```
+
+
+
+
### Plugin Configuration Parameters
+
The Maven Plugin Plugin is responsible for generating the Plugin Info site and needs to be added to the `<reporting>` section unless it is already inherited from a parent POM:
+
+
```
<project>
[...]
@@ -173,7 +207,9 @@ mvn site
The comments, annotations and plugin parameter names are extracted from the plugin source and rendered in the Plugin Info page. In order for the generated site to be useful here are some guidelines you can follow when documenting your plugin.
-- all `@parameter` fields should have a descriptive comment, informative enough that even a regular user can understand
+
+
+ - all `@parameter` fields should have a descriptive comment, informative enough that even a regular user can understand
```
[...]
@@ -186,7 +222,8 @@ mvn site
[...]
```
-- class level comment should explain what the goal does
+
+ - class level comment should explain what the goal does
```
[...]
@@ -205,16 +242,24 @@ public class ExampleMojo
[...]
```
-- the `@component` and `@readonly` parameters are not required to have any comments but it's still a good practice to provide one
-### Site Organization
+ - the `@component` and `@readonly` parameters are not required to have any comments but it's still a good practice to provide one
+
+
- Visibility of the information is also crucial, having uniform navigation links will greatly improve the visibility of the documentations. The index page can also help emphasize important sections and pages of the plugin documentation.
+### Site Organization
+
+
+ Visibility of the information is also crucial, having uniform navigation links will greatly improve the visibility of the documentations. The index page can also help emphasize important sections and pages of the plugin documentation.
+
+
+#### Site Descriptor
-#### Site Descriptor
The site descriptor describes the navigation links and can be found in `src/site/site.xml`. Below is the suggested site descriptor template.
+
+
```
<?xml version="1.0" encoding="UTF-8"?>
<project>
@@ -236,10 +281,14 @@ public class ExampleMojo
##### Navigation Links
-- Introduction
+
+
+ - Introduction
The introduction is the front page of the plugin documentation. This is a good place to place any section and pages that needs to be emphasized. It is also suggested that the generated plugin parameter configuration be linked here. Below is the suggested `src/site/apt/index.apt` template
+
+
```
------
Introduction
@@ -291,18 +340,25 @@ Plugin Name
```
-- Goals
- `plugin-info.html` is generated by the Maven Plugin Plugin. Until the Maven Site Plugin is updated it would be better to pull it out to the main menu for greater visibility. This contains the goals and their descriptions with a link to the configuration parameters. The information is based on the comments and annotations of the plugin.
+ - Goals
+
+ `plugin-info.html` is generated by the Maven Plugin Plugin. Until the Maven Site Plugin is updated it would be better to pull it out to the main menu for greater visibility. This contains the goals and their descriptions with a link to the configuration parameters. The information is based on the comments and annotations of the plugin.
-- Usage (this was previously called Howto)
- The usage page describes the the basic use cases for the plugin goals which includes sample POM configurations and explanation of how the goals work.
-- FAQ
+ - Usage (this was previously called Howto)
+
+ The usage page describes the the basic use cases for the plugin goals which includes sample POM configurations and explanation of how the goals work.
+
+
+
+ - FAQ
A well documented project always collates frequently asked questions which are usually located in `src/site/fml/faq.fml`. The example below provides a template for your FAQ:
+
+
```
<?xml version="1.0" encoding="UTF-8"?>
<faqs id="FAQ" title="Frequently Asked Questions">
@@ -319,26 +375,44 @@ Plugin Name
</faqs>
```
-- Examples
+
+ - Examples
The advanced configurations and examples not covered in the usage page is located here. Advanced users who wants to maximize the use of a plugin can check the items here. Tips on how to use the plugin effectively is also a good thing to put here.
+
+
For examples of items under "Examples" check these plugin sites:
-- [Maven Javadoc Plugin Examples](/plugins/maven-javadoc-plugin/)
-- [Maven War Plugin Examples](/plugins/maven-war-plugin/)
+
+ - [Maven Javadoc Plugin Examples](/plugins/maven-javadoc-plugin/)
+
+ - [Maven War Plugin Examples](/plugins/maven-war-plugin/)
+
+
+
+
+
+
### Recommended Configured Reports
+
There are 2 recommended report plugins to enhance the plugin documentation, Javadoc and JXR.
-- Maven Javadoc Plugin
+
+
+ - Maven Javadoc Plugin
Javadocs provide documentation that makes it easier for developers to know how to use a particular class. Instead of reading and understanding the actual source code, the developer can use the Javadocs instead to lookup the class attributes and methods.
+
+
To enable javadoc for your plugin add the following to your `pom.xml`
+
+
```
<project>
[...]
@@ -364,14 +438,21 @@ Plugin Name
</project>
```
+
Check the documentation about the plugin's [`javadoc:javadoc`](/plugins/maven-javadoc-plugin/javadoc-mojo.html) goal for the advanced configurations.
-- Maven JXR Plugin
+
+
+ - Maven JXR Plugin
The Maven JXR Plugin generates a cross-reference of the project sources. The generated cross-references are also linked to the corresponding javadoc if javadoc is generated. The cross-references is great for those who wants to better understand the inner workings of the plugin.
+
+
To enable source code cross-references add the following to your `pom.xml`
+
+
```
<project>
[...]
@@ -391,4 +472,10 @@ Plugin Name
</project>
```
+
Check the [JXR configuration page](/plugins/maven-jxr-plugin/jxr-mojo.html) for the possible configuration parameters.
+
+
+
+
+
diff --git a/content/markdown/guides/development/guide-testing-development-plugins.md b/content/markdown/guides/development/guide-testing-development-plugins.md
index 3ec34daf..5dfe52be 100644
--- a/content/markdown/guides/development/guide-testing-development-plugins.md
+++ b/content/markdown/guides/development/guide-testing-development-plugins.md
@@ -22,24 +22,36 @@ under the License.
-->
## Guide to Testing Development Versions of Plugins
+
### Why would I want to do this?
+
If a bug you are encountering has been reported as fixed but not yet released, you can confirm that it has been fixed for you. Or perhaps you just like to live on the bleeding edge.
+
You are highly encouraged to join the development list for the project and provide your feedback, or help promote release of the plugin in question.
- _Note:_ This is **not** recommended as an everyday or in production practice! Snapshots are for testing purposes only and are not official releases. For more information, see [the Releases FAQ](http://www.apache.org/dev/release.html#what).
+
+ _Note:_ This is **not** recommended as an everyday or in production practice! Snapshots are for testing purposes only and are not official releases. For more information, see [ the Releases FAQ](http://www.apache.org/dev/release.html#what).
+
+
### How do I do this?
+
Development versions of Maven plugins are periodically published to the repository: [https://repository.apache.org/snapshots/](https://repository.apache.org/snapshots/).
+
_Note:_ Currently, this is not done automatically by our continuous integration setup. This is coming soon.
+
Other sites may publish there own - for example, the MojoHaus project hosts theirs at [https://oss.sonatype.org/content/repositories/snapshots/](https://oss.sonatype.org/content/repositories/snapshots/)
+
The first step is to include this in your project:
+
+
```
<project>
...
@@ -55,11 +67,13 @@ under the License.
After this is included, there are three ways to use the updated versions:
-- Set the appropriate version in the plugin, eg `2.0.1-SNAPSHOT`
-- If you have not specified a version, use the `-U` switch to update plugins for the given Maven run
-- You can have Maven automatically check for updates on a given interval, for example:
+ - Set the appropriate version in the plugin, eg `2.0.1-SNAPSHOT`
+
+ - If you have not specified a version, use the `-U` switch to update plugins for the given Maven run
+
+ - You can have Maven automatically check for updates on a given interval, for example:
```
<project>
@@ -74,16 +88,25 @@ under the License.
</project>
```
+
+
_Note:_ These last two techniques mean that _every_ plugin will be updated to the latest snapshot version.
+
The development version will stop being used if the `<pluginRepository>` element is removed from your POM and the version is set back to the release version. If you are using the command line or an unspecified version, you will also need to remove the version from the local repository.
+
+
### Using Settings without Modifying the Project
+
If you are using the goals from the command line on a number of projects, you should include this in your `settings.xml` file instead.
+
You need to modify your `${user.home}/.m2/settings.xml` file to include two new profiles and then when you need access to the plugin snapshots use `-Papache`. The profile only needs to be enabled once so that the plugins can be downloaded into you local repository. Once in your local repository Maven can successfully resolve the dependencies and the profile no longer needs to be activated.
+
+
```
<settings>
...
@@ -111,14 +134,24 @@ under the License.
When invoking Maven for Apache profile, do it like this:
+
+
```
mvn -Papache <phase|goal>
```
+
### Using a Repository Manager
- In addition to the above you may want to use a repository manager so that you can retain the builds you have been using. For information on this technique, see the [Guide to Testing Staged Releases](./guide-testing-releases.html).
+
+ In addition to the above you may want to use a repository manager so that you can retain the builds you have been using. For information on this technique, see the [ Guide to Testing Staged Releases](./guide-testing-releases.html).
+
+
### How do I make changes to the source and test development versions of the plugins?
+
For information on this, see the [Guide to Maven Development](./guide-maven-development.html).
+
+
+
diff --git a/content/markdown/guides/development/guide-testing-releases.md b/content/markdown/guides/development/guide-testing-releases.md
index 8273de10..beba1ccf 100644
--- a/content/markdown/guides/development/guide-testing-releases.md
+++ b/content/markdown/guides/development/guide-testing-releases.md
@@ -22,22 +22,29 @@ under the License.
-->
## Guide to Testing Staged Releases
+
As part of the release process, the artifacts are staged in a temporary repository for testing and evaluation before voting. Such repositories are not available by default, so to use them your project must be configured appropriately.
+
The steps are as follows:
-- add the repository or plugin repository to your POM or settings (see below)
-- ensure you are using the version being released of the artifacts in your project, e.g. by setting the `<version>` in the `<plugin>` tag.
-- test the release
+ - add the repository or plugin repository to your POM or settings (see below)
+
+ - ensure you are using the version being released of the artifacts in your project, e.g. by setting the `<version>` in the `<plugin>` tag.
+
+ - test the release
+
+ - remove the repository from your POM if it was specified there
-- remove the repository from your POM if it was specified there
+ - remove the artifacts from your local repository when you have completed testing
-- remove the artifacts from your local repository when you have completed testing
The repository configuration for testing a plugin will typically look something like this (it will be provided in the vote email):
+
+
```
...
<pluginRepositories>
@@ -51,48 +58,65 @@ under the License.
The important thing is that the staged release does not pollute your eventual environment as it may change if the vote fails and the release is made again. This is why clearing the local repository is necessary, but if you are using a repository manager this is also important to clear. The following provides instructions for setting Archiva up in such a way that the artifacts are isolated already.
+
### Setting up Archiva to Test Staged Releases
+
These steps will be similar for any repository manager - please refer to their individual documentation for instructions on how to configure remote proxies.
+
For Archiva, the first step is to create a new managed repository for the staged releases. This will ensure they remain isolated from your environment. On the repositories tab, add a new managed repository with the settings:
-- Identifier = `staged-releases`
-- Name = Staged Releases
-- Directory = `/path/to/repositories/staged-releases`
+ - Identifier = `staged-releases`
+
+ - Name = Staged Releases
+
+ - Directory = `/path/to/repositories/staged-releases`
+
+ - Uncheck 'Scannable'
-- Uncheck 'Scannable'
Next add a remote repository with settings similar to the following:
-- Identifier = `dfabulich.staged.releases`
-- Name = dfabulich Staged Releases
-- URL = `http://people.apache.org/\~dfabulich/staging-repo/`
+ - Identifier = `dfabulich.staged.releases`
+
+ - Name = dfabulich Staged Releases
+
+ - URL = `http://people.apache.org/\~dfabulich/staging-repo/`
+
Finally, add a proxy connector to connect the two repositories:
-- Managed repository = `staged-releases`
-- Remote repository = `dfabulich.staged`
-- Release policy = `once`
+ - Managed repository = `staged-releases`
+
+ - Remote repository = `dfabulich.staged`
-- Snapshot policy = `never`
+ - Release policy = `once`
+
+ - Snapshot policy = `never`
+
+ - White list = `org/apache/maven/\*\*`
-- White list = `org/apache/maven/\*\*`
You can then utilise this repository from your POM or settings in the same way, but with the alternate URL of `http://localhost:8080/archiva/repository/staged-releases/`.
+
The advantage of this approach is that you can usually remove your entire local repository afterwards and after removing the staged repository from your POM the artifacts will no longer be used. There is no need to remove the repository or artifacts from Archiva itself - unless a staged release is updated for further testing.
+
It is also quite easy to test another staged release at a later date by reusing the repository, or adding a proxy connector and remote repository for a different staging repository.
+
If you are using the repository mirroring technique to lock down to the repository manager in your environment, you would add an additional mirror to correspond to the additional repository in the POM, such as:
+
+
```
...
<mirror>
@@ -103,10 +127,14 @@ under the License.
...
```
+
### Using a Settings Profile
+
If you regularly test staged releases and want to have a more convenient way to add the repository to a build without modifying your POM, you may add a profile to your `\~/.m2/settings.xml`:
+
+
```
...
<profiles>
@@ -124,8 +152,13 @@ under the License.
With this in place, you can activate it by simply changing the plugin version to the one you are testing in the POM as above, then run the build with the following command:
+
+
```
mvn verify -Pstaged-releases
```
Note that the same conditions apply as above about cleaning out the local repository to prevent pollution of your local build environment.
+
+
+
diff --git a/content/markdown/guides/getting-started/index.md b/content/markdown/guides/getting-started/index.md
index fb0c5d20..3c472de6 100644
--- a/content/markdown/guides/getting-started/index.md
+++ b/content/markdown/guides/getting-started/index.md
@@ -22,86 +22,112 @@ under the License.
-->
## Maven Getting Started Guide
+
This guide is intended as a reference for those working with Maven for the first time, but is also intended to serve as a cookbook with self-contained references and solutions for common use cases. For first time users, it is recommended that you step through the material in a sequential fashion. For users more familiar with Maven, this guide endeavours to provide a quick solution for the need at hand. It is assumed at this point that you have downloaded Maven and installed Maven on you [...]
+
Ok, so you now have Maven installed and we're ready to go. Before we jump into our examples we'll very briefly go over what Maven is and how it can help you with your daily work and collaborative efforts with team members. Maven will, of course, work for small projects, but Maven shines in helping teams operate more effectively by allowing team members to focus on what the stakeholders of a project require. You can leave the build infrastructure to Maven!
+
+
## Sections
-- [What is Maven?](./index.html#what-is-maven)
-- [How can Maven benefit my development process?](./index.html#how-can-maven-benefit-my-development-process)
-- [How do I setup Maven?](./index.html#how-do---setup-maven)
+ - [What is Maven?](./index.html#what-is-maven)
+
+ - [How can Maven benefit my development process?](./index.html#how-can-maven-benefit-my-development-process)
+
+ - [How do I setup Maven?](./index.html#how-do---setup-maven)
-- [How do I make my first Maven project?](./index.html#how-do-i-make-my-first-maven-project)
+ - [How do I make my first Maven project?](./index.html#how-do-i-make-my-first-maven-project)
-- [How do I compile my application sources?](./index.html#how-do-i-compile-my-application-sources)
+ - [How do I compile my application sources?](./index.html#how-do-i-compile-my-application-sources)
-- [How do I compile my test sources and run my unit tests?](./index.html#how-do-i-compile-my-test-sources-and-run-my-unit-tests)
+ - [How do I compile my test sources and run my unit tests?](./index.html#how-do-i-compile-my-test-sources-and-run-my-unit-tests)
-- [How do I create a JAR and install it in my local repository?](./index.html#how-do-i-create-a-jar-and-install-it-in-my-local-repository)
+ - [How do I create a JAR and install it in my local repository?](./index.html#how-do-i-create-a-jar-and-install-it-in-my-local-repository)
-- [What is a SNAPSHOT version?](./index.html#what-is-a-snapshot-version)
+ - [What is a SNAPSHOT version?](./index.html#what-is-a-snapshot-version)
-- [How do I use plugins?](./index.html#how-do-i-use-plugins)
+ - [How do I use plugins?](./index.html#how-do-i-use-plugins)
-- [How do I add resources to my JAR?](./index.html#how-do-i-add-resources-to-my-jar)
+ - [How do I add resources to my JAR?](./index.html#how-do-i-add-resources-to-my-jar)
-- [How do I filter resource files?](./index.html#how-do-i-filter-resource-files)
+ - [How do I filter resource files?](./index.html#how-do-i-filter-resource-files)
-- [How do I use external dependencies?](./index.html#how-do-i-use-external-dependencies)
+ - [How do I use external dependencies?](./index.html#how-do-i-use-external-dependencies)
-- [How do I deploy my jar in my remote repository?](./index.html#how-do-i-deploy-my-jar-in-my-remote-repository)
+ - [How do I deploy my jar in my remote repository?](./index.html#how-do-i-deploy-my-jar-in-my-remote-repository)
-- [How do I create documentation?](./index.html#how-do-i-create-documentation)
+ - [How do I create documentation?](./index.html#how-do-i-create-documentation)
-- [How do I build other types of projects?](./index.html#how-do-i-build-other-types-of-projects)
+ - [How do I build other types of projects?](./index.html#how-do-i-build-other-types-of-projects)
+
+ - [How do I build more than one project at once?](./index.html#how-do-i-build-more-than-one-project-at-once)
-- [How do I build more than one project at once?](./index.html#how-do-i-build-more-than-one-project-at-once)
### What is Maven?
+
At first glance Maven can appear to be many things, but in a nutshell Maven is an attempt _to apply patterns to a project's build infrastructure in order to promote comprehension and productivity by providing a clear path in the use of best practices_. Maven is essentially a project management and comprehension tool and as such provides a way to help with managing:
-- Builds
-- Documentation
-- Reporting
+ - Builds
+
+ - Documentation
-- Dependencies
+ - Reporting
-- SCMs
+ - Dependencies
-- Releases
+ - SCMs
+
+ - Releases
+
+ - Distribution
-- Distribution
If you want more background information on Maven you can check out [The Philosophy of Maven](../../background/philosophy-of-maven.html) and [The History of Maven](../../background/history-of-maven.html). Now let's move on to how you, the user, can benefit from using Maven.
+
+
### How can Maven benefit my development process?
+
Maven can provide benefits for your build process by employing standard conventions and practices to accelerate your development cycle while at the same time helping you achieve a higher rate of success.
+
Now that we have covered a little bit of the history and purpose of Maven let's get into some real examples to get you up and running with Maven!
+
+
### How do I setup Maven?
- The defaults for Maven are often sufficient, but if you need to change the cache location or are behind a HTTP proxy, you will need to create configuration. See the [Guide to Configuring Maven](../mini/guide-configuring-maven.html) for more information.
+
+ The defaults for Maven are often sufficient, but if you need to change the cache location or are behind a HTTP proxy, you will need to create configuration. See the [ Guide to Configuring Maven](../mini/guide-configuring-maven.html) for more information.
+
+
### How do I make my first Maven project?
+
We are going to jump headlong into creating your first Maven project! To create our first Maven project we are going to use Maven's archetype mechanism. An archetype is defined as _an original pattern or model from which all other things of the same kind are made_. In Maven, an archetype is a template of a project which is combined with some user input to produce a working Maven project that has been tailored to the user's requirements. We are going to show you how the archetype mechani [...]
+
On to creating your first project! In order to create the simplest of Maven projects, execute the following from the command line:
+
+
```
mvn -B archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
```
Once you have executed this command, you will notice a few things have happened. First, you will notice that a directory named `my-app` has been created for the new project, and this directory contains a file named `pom.xml` that should look like this:
+
+
```
<project 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/maven-4.0.0.xsd">
@@ -140,32 +166,39 @@ mvn -B archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -Darch
`pom.xml` contains the Project Object Model (POM) for this project. The POM is the basic unit of work in Maven. This is important to remember because Maven is inherently project-centric in that everything revolves around the notion of a project. In short, the POM contains every important piece of information about your project and is essentially one-stop-shopping for finding anything related to your project. Understanding the POM is important and new users are encouraged to refer to the [...]
+
This is a very simple POM but still displays the key elements every POM contains, so let's walk through each of them to familiarize you with the POM essentials:
-- **project** This is the top-level element in all Maven pom.xml files.
-- **modelVersion** This element indicates what version of the object model this POM is using. The version of the model itself changes very infrequently but it is mandatory in order to ensure stability of use if and when the Maven developers deem it necessary to change the model.
-- **groupId** This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example `org.apache.maven.plugins` is the designated groupId for all Maven plugins.
+ - **project** This is the top-level element in all Maven pom.xml files.
+
+ - **modelVersion** This element indicates what version of the object model this POM is using. The version of the model itself changes very infrequently but it is mandatory in order to ensure stability of use if and when the Maven developers deem it necessary to change the model.
+
+ - **groupId** This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example `org.apache.maven.plugins` is the designated groupId for all Maven plugins.
+
+ - **artifactId** This element indicates the unique base name of the primary artifact being generated by this project. The primary artifact for a project is typically a JAR file. Secondary artifacts like source bundles also use the artifactId as part of their final name. A typical artifact produced by Maven would have the form `<artifactId>-<version>.<extension>` (for example, `myapp-1.0.jar`).
-- **artifactId** This element indicates the unique base name of the primary artifact being generated by this project. The primary artifact for a project is typically a JAR file. Secondary artifacts like source bundles also use the artifactId as part of their final name. A typical artifact produced by Maven would have the form `<artifactId>-<version>.<extension>` (for example, `myapp-1.0.jar`).
+ - **version** This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the `SNAPSHOT` designator in a version, which indicates that a project is in a state of development. We will discuss the use of [snapshots](./index.html#what-is-a-snapshot-version) and how they work further on in this guide.
-- **version** This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the `SNAPSHOT` designator in a version, which indicates that a project is in a state of development. We will discuss the use of [snapshots](./index.html#what-is-a-snapshot-version) and how they work further on in this guide.
+ - **name** This element indicates the display name used for the project. This is often used in Maven's generated documentation.
-- **name** This element indicates the display name used for the project. This is often used in Maven's generated documentation.
+ - **url** This element indicates where the project's site can be found. This is often used in Maven's generated documentation.
-- **url** This element indicates where the project's site can be found. This is often used in Maven's generated documentation.
+ - **properties** This element contains value placeholders accessible anywhere within a POM.
-- **properties** This element contains value placeholders accessible anywhere within a POM.
+ - **dependencies** This element's children list [dependencies](/pom.html#dependencies). The cornerstone of the POM.
-- **dependencies** This element's children list [dependencies](/pom.html#dependencies). The cornerstone of the POM.
+ - **build** This element handles things like declaring your project's directory structure and managing plugins.
-- **build** This element handles things like declaring your project's directory structure and managing plugins.
For a complete reference of what elements are available for use in the POM please refer to our [POM Reference](/ref/current/maven-model/maven.html). Now let's get back to the project at hand.
+
After the archetype generation of your first project you will also notice that the following directory structure has been created:
+
+
```
my-app
|-- pom.xml
@@ -186,20 +219,29 @@ my-app
As you can see, the project created from the archetype has a POM, a source tree for your application's sources and a source tree for your test sources. This is the standard layout for Maven projects (the application sources reside in `${basedir}/src/main/java` and test sources reside in `${basedir}/src/test/java`, where `${basedir}` represents the directory containing `pom.xml`).
+
If you were to create a Maven project by hand this is the directory structure that we recommend using. This is a Maven convention and to learn more about it you can read our [Introduction to the Standard Directory Layout](../introduction/introduction-to-the-standard-directory-layout.html).
+
Now that we have a POM, some application sources, and some test sources you are probably asking...
+
+
### How do I compile my application sources?
+
Change to the directory where pom.xml is created by archetype:generate and execute the following command to compile your application sources:
+
+
```
mvn compile
```
Upon executing this command you should see output like the following:
+
+
```
[INFO] Scanning for projects...
[INFO]
@@ -224,22 +266,32 @@ mvn compile
The first time you execute this (or any other) command, Maven will need to download all the plugins and related dependencies it needs to fulfill the command. From a clean installation of Maven, this can take quite a while (in the output above, it took almost 4 minutes). If you execute the command again, Maven will now have what it needs, so it won't need to download anything new and will be able to execute the command much more quickly.
+
As you can see from the output, the compiled classes were placed in `${basedir}/target/classes`, which is another standard convention employed by Maven. So, if you're a keen observer, you'll notice that by using the standard conventions, the POM above is very small and you haven't had to tell Maven explicitly where any of your sources are or where the output should go. By following the standard Maven conventions, you can get a lot done with very little effort! Just as a casual compariso [...]
+
Now, this is simply to compile a single tree of application sources and the Ant script shown is pretty much the same size as the POM shown above. But we'll see how much more we can do with just that simple POM!
+
+
### How do I compile my test sources and run my unit tests?
+
Now you're successfully compiling your application's sources and now you've got some unit tests that you want to compile and execute (because every programmer always writes and executes their unit tests \*nudge nudge wink wink\*).
+
Execute the following command:
+
+
```
mvn test
```
Upon executing this command you should see output like the following:
+
+
```
[INFO] Scanning for projects...
[INFO]
@@ -284,22 +336,31 @@ mvn test
Some things to notice about the output:
-- Maven downloads more dependencies this time. These are the dependencies and plugins necessary for executing the tests (it already has the dependencies it needs for compiling and won't download them again).
-- Before compiling and executing the tests Maven compiles the main code (all these classes are up to date because we haven't changed anything since we compiled last).
+
+ - Maven downloads more dependencies this time. These are the dependencies and plugins necessary for executing the tests (it already has the dependencies it needs for compiling and won't download them again).
+
+ - Before compiling and executing the tests Maven compiles the main code (all these classes are up to date because we haven't changed anything since we compiled last).
+
If you simply want to compile your test sources (but not execute the tests), you can execute the following:
+
+
```
mvn test-compile
```
Now that you can compile your application sources, compile your tests, and execute the tests, you'll want to move on to the next logical step so you'll be asking ...
+
+
### How do I create a JAR and install it in my local repository?
+
Making a JAR file is straight forward enough and can be accomplished by executing the following command:
+
<!-- How to skip tests ... jvz -->
```
@@ -308,14 +369,19 @@ mvn package
You can now take a look in the `${basedir}/target` directory and you will see the generated JAR file.
+
Now you'll want to install the artifact you've generated (the JAR file) in your local repository (`${user.home}/.m2/repository` is the default location). For more information on repositories you can refer to our [Introduction to Repositories](../introduction/introduction-to-repositories.html) but let's move on to installing our artifact! To do so execute the following command:
+
+
```
mvn install
```
Upon executing this command you should see the following output:
+
+
```
[INFO] Scanning for projects...
[INFO]
@@ -362,38 +428,54 @@ mvn install
Note that the surefire plugin (which executes the test) looks for tests contained in files with a particular naming convention. By default the tests included are:
-- `\*\*/\*Test.java`
-- `\*\*/Test\*.java`
-- `\*\*/\*TestCase.java`
+ - `\*\*/\*Test.java`
+
+ - `\*\*/Test\*.java`
+
+ - `\*\*/\*TestCase.java`
+
And the default excludes are:
-- `\*\*/Abstract\*Test.java`
-- `\*\*/Abstract\*TestCase.java`
+
+ - `\*\*/Abstract\*Test.java`
+
+ - `\*\*/Abstract\*TestCase.java`
+
You have walked through the process for setting up, building, testing, packaging, and installing a typical Maven project. This is likely the vast majority of what projects will be doing with Maven and if you've noticed, everything you've been able to do up to this point has been driven by an 18-line file, namely the project's model or POM. If you look at a typical Ant [build file](../../ant/build-a1.xml) that provides the same functionality that we've achieved thus far you'll notice it' [...]
+
So what else can you get for free? There are a great number of Maven plugins that work out of the box with even a simple POM like we have above. We'll mention one here specifically as it is one of the highly prized features of Maven: without any work on your part this POM has enough information to generate a web site for your project! You will most likely want to customize your Maven site but if you're pressed for time all you need to do to provide basic information about your project i [...]
+
+
```
mvn site
```
There are plenty of other standalone goals that can be executed as well, for example:
+
+
```
mvn clean
```
This will remove the `target` directory with all the build data before starting so that it is fresh.
+
+
### What is a SNAPSHOT version?
+
Notice the value of the **version** tag in the `pom.xml` file shown below has the suffix: `-SNAPSHOT`.
+
+
```
<project xmlns="http://maven.apache.org/POM/4.0.0"
...
@@ -407,16 +489,24 @@ mvn clean
The `SNAPSHOT` value refers to the 'latest' code along a development branch, and provides no guarantee the code is stable or unchanging. Conversely, the code in a 'release' version (any version value without the suffix `SNAPSHOT`) is unchanging.
+
In other words, a SNAPSHOT version is the 'development' version before the final 'release' version. The SNAPSHOT is "older" than its release.
+
During the [release](../../plugins/maven-release-plugin/) process, a version of **x.y-SNAPSHOT** changes to **x.y**. The release process also increments the development version to **x.(y+1)-SNAPSHOT**. For example, version **1.0-SNAPSHOT** is released as version **1.0**, and the new development version is version **1.1-SNAPSHOT**.
+
+
### How do I use plugins?
+
Whenever you want to customise the build for a Maven project, this is done by adding or reconfiguring plugins.
+
For this example, we will configure the Java compiler to allow JDK 5.0 sources. This is as simple as adding this to your POM:
+
+
```
...
<build>
@@ -437,16 +527,24 @@ mvn clean
You'll notice that all plugins in Maven look much like a dependency - and in some ways they are. This plugin will be automatically downloaded and used - including a specific version if you request it (the default is to use the latest available).
- The `configuration` element applies the given parameters to every goal from the compiler plugin. In the above case, the compiler plugin is already used as part of the build process and this just changes the configuration. It is also possible to add new goals to the process, and configure specific goals. For information on this, see the [Introduction to the Build Lifecycle](../introduction/introduction-to-the-lifecycle.html).
- To find out what configuration is available for a plugin, you can see the [Plugins List](../../plugins/) and navigate to the plugin and goal you are using. For general information about how to configure the available parameters of a plugin, have a look at the [Guide to Configuring Plugins](../mini/guide-configuring-plugins.html).
+ The `configuration` element applies the given parameters to every goal from the compiler plugin. In the above case, the compiler plugin is already used as part of the build process and this just changes the configuration. It is also possible to add new goals to the process, and configure specific goals. For information on this, see the [ Introduction to the Build Lifecycle](../introduction/introduction-to-the-lifecycle.html).
+
+
+ To find out what configuration is available for a plugin, you can see the [ Plugins List](../../plugins/) and navigate to the plugin and goal you are using. For general information about how to configure the available parameters of a plugin, have a look at the [Guide to Configuring Plugins](../mini/guide-configuring-plugins.html).
+
+
### How do I add resources to my JAR?
+
Another common use case that can be satisfied which requires no changes to the POM that we have above is packaging resources in the JAR file. For this common task, Maven again relies on the [Standard Directory Layout](../introduction/introduction-to-the-standard-directory-layout.html), which means by using standard Maven conventions you can package resources within JARs simply by placing those resources in a standard directory structure.
+
You see below in our example we have added the directory `${basedir}/src/main/resources` into which we place any resources we wish to package in our JAR. The simple rule employed by Maven is this: any directories or files placed within the `${basedir}/src/main/resources` directory are packaged in your JAR with the exact same structure starting at the base of the JAR.
+
+
```
my-app
|-- pom.xml
@@ -470,6 +568,8 @@ my-app
So you can see in our example that we have a `META-INF` directory with an `application.properties` file within that directory. If you unpacked the JAR that Maven created for you and took a look at it you would see the following:
+
+
```
|-- META-INF
| |-- MANIFEST.MF
@@ -487,6 +587,8 @@ my-app
As you can see, the contents of `${basedir}/src/main/resources` can be found starting at the base of the JAR and our `application.properties` file is there in the `META-INF` directory. You will also notice some other files there like `META-INF/MANIFEST.MF` as well as a `pom.xml` and `pom.properties` file. These come standard with generation of a JAR in Maven. You can create your own manifest if you choose, but Maven will generate one by default if you don't. (You can also modify the ent [...]
+
+
```
#Generated by Maven
#Tue Oct 04 15:43:21 GMT-05:00 2005
@@ -497,6 +599,8 @@ artifactId=my-app
To add resources to the classpath for your unit tests, you follow the same pattern as you do for adding resources to the JAR except the directory you place resources in is `${basedir}/src/test/resources`. At this point you would have a project directory structure that would look like the following:
+
+
```
my-app
|-- pom.xml
@@ -522,6 +626,8 @@ my-app
In a unit test you could use a simple snippet of code like the following to access the resource required for testing:
+
+
```
...
@@ -533,12 +639,17 @@ InputStream is = getClass().getResourceAsStream( "/test.properties" );
...
```
+
### How do I filter resource files?
+
Sometimes a resource file will need to contain a value that can only be supplied at build time. To accomplish this in Maven, put a reference to the property that will contain the value into your resource file using the syntax `${<property name>}`. The property can be one of the values defined in your pom.xml, a value defined in the user's settings.xml, a property defined in an external properties file, or a system property.
+
To have Maven filter resources when copying, simply set `filtering` to true for the resource directory in your `pom.xml`:
+
+
```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -574,10 +685,14 @@ InputStream is = getClass().getResourceAsStream( "/test.properties" );
You'll notice that we had to add the `build`, `resources`, and `resource` elements which weren't there before. In addition, we had to explicitly state that the resources are located in the src/main/resources directory. All of this information was provided as default values previously, but because the default value for `filtering` is false, we had to add this to our pom.xml in order to override that default value and set `filtering` to true.
+
To reference a property defined in your pom.xml, the property name uses the names of the XML elements that define the value, with "pom" being allowed as an alias for the project (root) element. So `${project.name}` refers to the name of the project, `${project.version}` refers to the version of the project, `${project.build.finalName}` refers to the final name of the file created when the built project is packaged, etc. Note that some elements of the POM have default values, so don't ne [...]
+
To continue our example, let's add a couple of properties to the `application.properties` file (which we put in the `src/main/resources` directory) whose values will be supplied when the resource is filtered:
+
+
```
# application.properties
application.name=${project.name}
@@ -586,12 +701,16 @@ application.version=${project.version}
With that in place, you can execute the following command (process-resources is the build lifecycle phase where the resources are copied and filtered):
+
+
```
mvn process-resources
```
and the `application.properties` file under `target/classes` (and will eventually go into the jar) looks like this:
+
+
```
# application.properties
application.name=Maven Quick Start Archetype
@@ -600,6 +719,8 @@ application.version=1.0-SNAPSHOT
To reference a property defined in an external file, all you need to do is add a reference to this external file in your pom.xml. First, let's create our external properties file and call it `src/main/filters/filter.properties`:
+
+
```
# filter.properties
my.filter.value=hello!
@@ -607,6 +728,8 @@ my.filter.value=hello!
Next, we'll add a reference to this new file in the `pom.xml`:
+
+
```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -645,6 +768,8 @@ my.filter.value=hello!
Then, if we add a reference to this property in the `application.properties` file:
+
+
```
# application.properties
application.name=${project.name}
@@ -654,6 +779,8 @@ message=${my.filter.value}
the next execution of the `mvn process-resources` command will put our new property value into `application.properties`. As an alternative to defining the my.filter.value property in an external file, you could also have defined it in the `properties` section of your `pom.xml` and you'd get the same effect (notice I don't need the references to `src/main/filters/filter.properties` either):
+
+
```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -693,6 +820,8 @@ message=${my.filter.value}
Filtering resources can also get values from system properties; either the system properties built into Java (like `java.version` or `user.home`) or properties defined on the command line using the standard Java -D parameter. To continue the example, let's change our `application.properties` file to look like this:
+
+
```
# application.properties
java.version=${java.version}
@@ -701,16 +830,23 @@ command.line.prop=${command.line.prop}
Now, when you execute the following command (note the definition of the command.line.prop property on the command line), the `application.properties` file will contain the values from the system properties.
+
+
```
mvn process-resources "-Dcommand.line.prop=hello again"
```
+
### How do I use external dependencies?
+
You've probably already noticed a `dependencies` element in the POM we've been using as an example. You have, in fact, been using an external dependency all this time, but here we'll talk about how this works in a bit more detail. For a more thorough introduction, please refer to our [Introduction to Dependency Mechanism](../introduction/introduction-to-dependency-mechanism.html).
+
The `dependencies` section of the pom.xml lists all of the external dependencies that our project needs in order to build (whether it needs that dependency at compile time, test time, run time, or whatever). Right now, our project is depending on JUnit only (I took out all of the resource filtering stuff for clarity):
+
+
```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -737,11 +873,15 @@ mvn process-resources "-Dcommand.line.prop=hello again"
For each external dependency, you'll need to define at least 4 things: groupId, artifactId, version, and scope. The groupId, artifactId, and version are the same as those given in the `pom.xml` for the project that built that dependency. The scope element indicates how your project uses that dependency, and can be values like `compile`, `test`, and `runtime`. For more information on everything you can specify for a dependency, see the [Project Descriptor Reference](/ref/current/maven-mo [...]
+
<!-- DJ: Does this link work? I can't find the document. -->
For more information about the dependency mechanism as a whole, see [Introduction to Dependency Mechanism](../introduction/introduction-to-dependency-mechanism.html).
+
With this information about a dependency, Maven will be able to reference the dependency when it builds the project. Where does Maven reference the dependency from? Maven looks in your local repository (`${user.home}/.m2/repository` is the default location) to find all dependencies. In a [previous section](#how-do-i-create-a-jar-and-install-it-in-my-local-repository), we installed the artifact from our project (my-app-1.0-SNAPSHOT.jar) into the local repository. Once it's installed ther [...]
+
+
```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -762,8 +902,11 @@ mvn process-resources "-Dcommand.line.prop=hello again"
What about dependencies built somewhere else? How do they get into my local repository? Whenever a project references a dependency that isn't available in the local repository, Maven will download the dependency from a remote repository into the local repository. You probably noticed Maven downloading a lot of things when you built your very first project (these downloads were dependencies for the various plugins used to build the project). By default, the remote repository Maven uses c [...]
+
Let's add another dependency to our project. Let's say we've added some logging to the code and need to add log4j as a dependency. First, we need to know what the groupId, artifactId, and version are for log4j. The appropriate directory on Maven Central is called [/maven2/log4j/log4j](https://repo.maven.apache.org/maven2/log4j/log4j/). In that directory is a file called maven-metadata.xml. Here's what the maven-metadata.xml for log4j looks like:
+
+
```
<metadata>
<groupId>log4j</groupId>
@@ -787,8 +930,11 @@ mvn process-resources "-Dcommand.line.prop=hello again"
From this file, we can see that the groupId we want is "log4j" and the artifactId is "log4j". We see lots of different version values to choose from; for now, we'll just use the latest version, 1.2.12 (some maven-metadata.xml files may also specify which version is the current release version: see [repository metadata reference](/ref/current/maven-repository-metadata/repository-metadata.html)). Alongside the maven-metadata.xml file, we can see a directory corresponding to each version o [...]
+
Now that we know the information we need, we can add the dependency to our pom.xml:
+
+
```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -821,14 +967,19 @@ mvn process-resources "-Dcommand.line.prop=hello again"
Now, when we compile the project (`mvn compile`), we'll see Maven download the log4j dependency for us.
+
<!-- DJ: Current -->
### How do I deploy my jar in my remote repository?
+
For deploying jars to an external repository, you have to configure the repository url in the pom.xml and the authentication information for connecting to the repository in the settings.xml.
+
Here is an example using scp and username/password authentication:
+
+
```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -882,6 +1033,7 @@ mvn process-resources "-Dcommand.line.prop=hello again"
</project>
```
+
```
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
@@ -901,12 +1053,18 @@ mvn process-resources "-Dcommand.line.prop=hello again"
Note that if you are connecting to an openssh ssh server which has the parameter "PasswordAuthentication" set to "no" in the sshd_confing, you will have to type your password each time for username/password authentication (although you can log in using another ssh client by typing in the username and password). You might want to switch to public key authentication in this case.
- Care should be taken if using passwords in `settings.xml`. For more information, see [Password Encryption](../mini/guide-encryption.html).
+
+ Care should be taken if using passwords in `settings.xml`. For more information, see [ Password Encryption](../mini/guide-encryption.html).
+
+
### How do I create documentation?
+
To get you jump started with Maven's documentation system you can use the archetype mechanism to generate a site for your existing project using the following command:
+
+
```
mvn archetype:generate \
-DarchetypeGroupId=org.apache.maven.archetypes \
@@ -917,10 +1075,15 @@ mvn archetype:generate \
Now head on over to the [Guide to creating a site](../mini/guide-site.html) to learn how to create the documentation for your project.
+
+
### How do I build other types of projects?
+
Note that the lifecycle applies to any project type. For example, back in the base directory we can create a simple web application:
+
+
```
mvn archetype:generate \
-DarchetypeGroupId=org.apache.maven.archetypes \
@@ -931,6 +1094,8 @@ mvn archetype:generate \
Note that these must all be on a single line. This will create a directory called `my-webapp` containing the following project descriptor:
+
+
```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -958,18 +1123,26 @@ mvn archetype:generate \
Note the `<packaging>` element - this tells Maven to build as a WAR. Change into the webapp project's directory and try:
+
+
```
mvn package
```
You'll see `target/my-webapp.war` is built, and that all the normal steps were executed.
+
+
### How do I build more than one project at once?
+
The concept of dealing with multiple modules is built in to Maven. In this section, we will show how to build the WAR above, and include the previous JAR as well in one step.
+
Firstly, we need to add a parent `pom.xml` file in the directory above the other two, so it should look like this:
+
+
```
+- pom.xml
+- my-app
@@ -986,6 +1159,8 @@ mvn package
The POM file you'll create should contain the following:
+
+
```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -1005,6 +1180,8 @@ mvn package
We'll need a dependency on the JAR from the webapp, so add this to `my-webapp/pom.xml`:
+
+
```
...
<dependencies>
@@ -1019,6 +1196,8 @@ mvn package
Finally, add the following `<parent>` element to both of the other `pom.xml` files in the subdirectories:
+
+
```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -1032,12 +1211,16 @@ mvn package
Now, try it... from the top level directory, run:
+
+
```
mvn verify
```
The WAR has now been created in `my-webapp/target/my-webapp.war`, and the JAR is included:
+
+
```
$ jar tvf my-webapp/target/my-webapp-1.0-SNAPSHOT.war
0 Fri Jun 24 10:59:56 EST 2005 META-INF/
@@ -1056,8 +1239,14 @@ $ jar tvf my-webapp/target/my-webapp-1.0-SNAPSHOT.war
How does this work? Firstly, the parent POM created (called `app`), has a packaging of `pom` and a list of modules defined. This tells Maven to run all operations over the set of projects instead of just the current one (to override this behaviour, you can use the `--non-recursive` command line option).
+
Next, we tell the WAR that it requires the `my-app` JAR. This does a few things: it makes it available on the classpath to any code in the WAR (none in this case), it makes sure the JAR is always built before the WAR, and it indicates to the WAR plugin to include the JAR in its library directory.
+
You may have noticed that `junit-4.11.jar` was a dependency, but didn't end up in the WAR. The reason for this is the `<scope>test</scope>` element - it is only required for testing, and so is not included in the web application as the compile time dependency `my-app` is.
+
The final step was to include a parent definition. This ensures that the POM can always be located even if the project is distributed separately from its parent by looking it up in the repository.
+
+
+
diff --git a/content/markdown/guides/getting-started/maven-in-five-minutes.md b/content/markdown/guides/getting-started/maven-in-five-minutes.md
index 2e2bc8ce..4413fd76 100644
--- a/content/markdown/guides/getting-started/maven-in-five-minutes.md
+++ b/content/markdown/guides/getting-started/maven-in-five-minutes.md
@@ -22,22 +22,32 @@ under the License.
-->
## Maven in 5 Minutes
+
### Prerequisites
+
You must understand how to install software on your computer. If you do not know how to do this, please ask someone at your office, school, etc. or pay someone to explain this to you. The Maven mailing lists are not the best place to ask for this advice.
+
+
### Installation
+
_Maven is a Java tool, so you must have [Java](https://www.oracle.com/technetwork/java/javase/downloads/index.html) installed in order to proceed._
+
First, [download Maven](../../download.html) and follow the [installation instructions](../../install.html). After that, type the following in a terminal or in a command prompt:
+
+
```
mvn --version
```
It should print out your installed version of Maven, for example:
+
+
```
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: D:\apache-maven-3.6.3\apache-maven\bin\..
@@ -48,26 +58,37 @@ OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Depending upon your network setup, you may require extra configuration. Check out the [Guide to Configuring Maven](../mini/guide-configuring-maven.html) if necessary.
+
**If you are using Windows, you should look at** [Windows Prerequisites](./windows-prerequisites.html) **to ensure that you are prepared to use Maven on Windows.**
+
+
### Creating a Project
+
You need somewhere for your project to reside. Create a directory somewhere and start a shell in that directory. On your command line, execute the following Maven goal:
+
+
```
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false
```
_If you have just installed Maven, it may take a while on the first run. This is because Maven is downloading the most recent artifacts (plugin jars and other files) into your local repository. You may also need to execute the command a couple of times before it succeeds. This is because the remote server may time out before your downloads are complete. Don't worry, there are ways to fix that._
+
You will notice that the _generate_ goal created a directory with the same name given as the artifactId. Change into that directory.
+
+
```
cd my-app
```
Under this directory you will notice the following [standard project structure](../introduction/introduction-to-the-standard-directory-layout.html).
+
+
```
my-app
|-- pom.xml
@@ -88,10 +109,14 @@ my-app
The `src/main/java` directory contains the project source code, the `src/test/java` directory contains the test source, and the `pom.xml` file is the project's Project Object Model, or POM.
+
#### The POM
+
The `pom.xml` file is the core of a project's configuration in Maven. It is a single configuration file that contains the majority of information required to build a project in just the way you want. The POM is huge and can be daunting in its complexity, but it is not necessary to understand all of the intricacies just yet to use it effectively. This project's POM is:
+
+
```
<project 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/maven-4.0.0.xsd">
@@ -117,18 +142,26 @@ my-app
</project>
```
+
#### What did I just do?
+
You executed the Maven goal _archetype:generate_, and passed in various parameters to that goal. The prefix _archetype_ is the [plugin](../../plugins/index.html) that provides the goal. If you are familiar with [Ant](http://ant.apache.org), you may conceive of this as similar to a task. This _archetype:generate_ goal created a simple project based upon a [maven-archetype-quickstart](/archetypes/maven-archetype-quickstart/) archetype. Suffice it to say for now that a _plugin_ is a collec [...]
+
+
#### Build the Project
+
+
```
mvn package
```
The command line will print out various actions, and end with the following:
+
+
```
...
[INFO] ------------------------------------------------------------------------
@@ -141,6 +174,8 @@ mvn package
Unlike the first command executed (_archetype:generate_), the second is simply a single word - _package_. Rather than a _goal_, this is a _phase_. A phase is a step in the [build lifecycle](../introduction/introduction-to-the-lifecycle.html), which is an ordered sequence of phases. When a phase is given, Maven executes every phase in the sequence up to and including the one defined. For example, if you execute the _compile_ phase, the phases that actually get executed are:
+
+
1 validate
1 generate-sources
@@ -153,24 +188,35 @@ mvn package
1 compile
+
You may test the newly compiled and packaged JAR with the following command:
+
+
```
java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App
```
Which will print the quintessential:
+
+
```
Hello World!
```
+
+
### Java 9 or later
+
By default your version of Maven might use an old version of the `maven-compiler-plugin` that is not compatible with Java 9 or later versions. To target Java 9 or later, you should at least use version 3.6.0 of the `maven-compiler-plugin` and set the `maven.compiler.release` property to the Java release you are targetting (e.g. 9, 10, 11, 12, etc.).
+
In the following example, we have configured our Maven project to use version 3.8.1 of `maven-compiler-plugin` and target Java 11:
+
+
```
<properties>
<maven.compiler.release>11</maven.compiler.release>
@@ -191,52 +237,78 @@ Hello World!
To learn more about `javac`'s `--release` option, see [JEP 247](https://openjdk.java.net/jeps/247).
+
+
### Running Maven Tools
+
#### Maven Phases
+
Although hardly a comprehensive list, these are the most common _default_ lifecycle phases executed.
-- **validate**: validate the project is correct and all necessary information is available
-- **compile**: compile the source code of the project
-- **test**: test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
+ - **validate**: validate the project is correct and all necessary information is available
-- **package**: take the compiled code and package it in its distributable format, such as a JAR.
+ - **compile**: compile the source code of the project
-- **integration-test**: process and deploy the package if necessary into an environment where integration tests can be run
+ - **test**: test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
-- **verify**: run any checks to verify the package is valid and meets quality criteria
+ - **package**: take the compiled code and package it in its distributable format, such as a JAR.
-- **install**: install the package into the local repository, for use as a dependency in other projects locally
+ - **integration-test**: process and deploy the package if necessary into an environment where integration tests can be run
+
+ - **verify**: run any checks to verify the package is valid and meets quality criteria
+
+ - **install**: install the package into the local repository, for use as a dependency in other projects locally
+
+ - **deploy**: done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
-- **deploy**: done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
There are two other Maven lifecycles of note beyond the _default_ list above. They are
-- **clean**: cleans up artifacts created by prior builds
-- **site**: generates site documentation for this project
+
+ - **clean**: cleans up artifacts created by prior builds
+
+
+
+ - **site**: generates site documentation for this project
+
Phases are actually mapped to underlying goals. The specific goals executed per phase is dependant upon the packaging type of the project. For example, _package_ executes _jar:jar_ if the project type is a JAR, and _war:war_ if the project type is - you guessed it - a WAR.
+
An interesting thing to note is that phases and goals may be executed in sequence.
+
+
```
mvn clean dependency:copy-dependencies package
```
This command will clean the project, copy dependencies, and package the project (executing all phases up to _package_, of course).
+
+
#### Generating the Site
+
+
```
mvn site
```
This phase generates a site based upon information on the project's pom. You can look at the documentation generated under `target/site`.
+
+
+
### Conclusion
+
We hope this quick overview has piqued your interest in the versatility of Maven. Note that this is a very truncated quick-start guide. Now you are ready for more comprehensive details concerning the actions you have just performed. Check out the [Maven Getting Started Guide](./index.html).
+
+
+
diff --git a/content/markdown/guides/getting-started/windows-prerequisites.md b/content/markdown/guides/getting-started/windows-prerequisites.md
index 1394d25d..2f970aea 100644
--- a/content/markdown/guides/getting-started/windows-prerequisites.md
+++ b/content/markdown/guides/getting-started/windows-prerequisites.md
@@ -22,28 +22,46 @@ under the License.
-->
## Maven on Windows
+
Maven is a command-line tool for building Java (and other) programs. The Maven project provides a simple ZIP file containing a precompiled version of Maven for your convenience. There is no installer. It's up to you to set up your prerequisites and environment to run Maven on Windows.
+
### Prerequisites
+
Maven is written in Java (and primarily used to build Java programs). Thus, the major prerequisite is the Java SDK. You need to install the Java SDK (e.g. from [Oracle's download site](https://www.oracle.com/technetwork/java/javase/downloads/index.html)).
+
Once Java is installed, you must ensure that the commands from the Java SDK are in your PATH environment variable. Running, for example,
+
+
```
java -version
```
must show the right version number.
+
+
### Maven Unpacked
+
You need to unpack the Maven distribution. Don't unpack it in the middle of your source code; pick some location and unpack it there. Let's assume that the path is `${maven.home}`.
+
+
### Maven in PATH
+
You run Maven by invoking a command-line tool: `mvn.cmd` from the `bin` directory of the Maven. To do this conveniently, `${maven.home}/bin` must be in your PATH, just like the Java SDK commands. You can add directories to your `PATH` in the control panel; the details vary by Windows version.
+
+
### Firewalls and Anti-virus
+
Firewall and Anti-virus sometimes prevent Java from running properly, or Windows Firewall (and various other Firewalls) actively prevent Java.exe from reaching out to the Internet to "download stuff" which is a key part of Maven. You may need to configure the Firewall or Anti-virus to add exceptions to allow such actions.
+
+
+
diff --git a/content/markdown/guides/introduction/introduction-to-archetypes.md b/content/markdown/guides/introduction/introduction-to-archetypes.md
index b048e671..876c9db5 100644
--- a/content/markdown/guides/introduction/introduction-to-archetypes.md
+++ b/content/markdown/guides/introduction/introduction-to-archetypes.md
@@ -22,28 +22,41 @@ under the License.
-->
## Introduction to Archetypes
+
+
## What is Archetype?
+
In short, Archetype is a Maven project templating toolkit. An archetype is defined as _an original pattern or model from which all other things of the same kind are made_. The name fits as we are trying to provide a system that provides a consistent means of generating Maven projects. Archetype will help authors create Maven project templates for users, and provides users with the means to generate parameterized versions of those project templates.
+
Using archetypes provides a great way to enable developers quickly in a way consistent with best practices employed by your project or organization. Within the Maven project, we use archetypes to try and get our users up and running as quickly as possible by providing a sample project that demonstrates many of the features of Maven, while introducing new users to the best practices employed by Maven. In a matter of seconds, a new user can have a working Maven project to use as a jumping [...]
+
You may want to standardize J2EE development within your organization, so you may want to provide archetypes for EJBs, or WARs, or for your web services. Once these archetypes are created and deployed in your organization's repository, they are available for use by all developers within your organization.
+
### Using an Archetype
+
To create a new project based on an Archetype, you need to call `mvn archetype:generate` goal, like the following:
+
+
```
mvn archetype:generate
```
Please refer to [Archetype Plugin page](/archetype/maven-archetype-plugin/usage.html).
+
+
### Provided Archetypes
+
Maven provides several Archetype artifacts:
+
|Archetype ArtifactIds|Description|
|---|---|
|maven-archetype-archetype|An archetype to generate a sample archetype project.|
@@ -60,6 +73,12 @@ mvn archetype:generate
For more information on these archetypes, please refer to the [Maven Archetype Bundles page](/archetypes/index.html).
+
+
### What makes up an Archetype?
+
Archetypes are packaged up in a JAR and they consist of the archetype metadata which describes the contents of archetype, and a set of [Velocity](http://velocity.apache.org/) templates which make up the prototype project. If you would like to know how to make your own archetypes, please refer to our [Guide to creating archetypes](../mini/guide-creating-archetypes.html).
+
+
+
diff --git a/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md b/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
index 8d79efe5..ff43f3ab 100644
--- a/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
+++ b/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
@@ -22,37 +22,52 @@ under the License.
-->
## Introduction to the Dependency Mechanism
+
Dependency management is a core feature of Maven. Managing dependencies for a single project is easy. Managing dependencies for multi-module projects and applications that consist of hundreds of modules is possible. Maven helps a great deal in defining, creating, and maintaining reproducible builds with well-defined classpaths and library versions.
+
Learn more about:
-- [Transitive Dependencies](#transitive-dependencies)
-- Excluded/Optional Dependencies
-- [Dependency Scope](#dependency-scope)
+ - [Transitive Dependencies](#transitive-dependencies)
+
+ - Excluded/Optional Dependencies
+
+
+
+ - [Dependency Scope](#dependency-scope)
-- [Dependency Management](#dependency-management)
+ - [Dependency Management](#dependency-management)
-- [Importing Dependencies](#importing-dependencies)
+ - [Importing Dependencies](#importing-dependencies)
-- [Bill of Materials (BOM) POMs](#bill-of-materials-bom-poms)
+ - [Bill of Materials (BOM) POMs](#bill-of-materials-bom-poms)
+
+
+
+ - [System Dependencies](#system-dependencies)
-- [System Dependencies](#system-dependencies)
### Transitive Dependencies
+
Maven avoids the need to discover and specify the libraries that your own dependencies require by including transitive dependencies automatically.
+
This feature is facilitated by reading the project files of your dependencies from the remote repositories specified. In general, all dependencies of those projects are used in your project, as are any that the project inherits from its parents, or from its dependencies, and so on.
+
There is no limit to the number of levels that dependencies can be gathered from. A problem arises only if a cyclic dependency is discovered.
+
With transitive dependencies, the graph of included libraries can quickly grow quite large. For this reason, there are additional features that limit which dependencies are included:
-- _Dependency mediation_ - this determines what version of an artifact will be chosen when multiple versions are encountered as dependencies. Maven picks the "nearest definition". That is, it uses the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, the first declaration wins.
-- "nearest definition" means that the version used will be the closest one to your project in the tree of dependencies. Consider this tree of dependencies:
+
+ - _Dependency mediation_ - this determines what version of an artifact will be chosen when multiple versions are encountered as dependencies. Maven picks the "nearest definition". That is, it uses the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, the first declaration wins.
+
+ - "nearest definition" means that the version used will be the closest one to your project in the tree of dependencies. Consider this tree of dependencies:
```
A
@@ -63,8 +78,11 @@ under the License.
└── D 1.0
```
+
In text, dependencies for A, B, and C are defined as A -\> B -\> C -\> D 2.0 and A -\> E -\> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0, as shown here:
+
+
```
A
├── B
@@ -76,48 +94,63 @@ under the License.
└── D 2.0
```
-- _Dependency management_ - this allows project authors to directly specify the versions of artifacts to be used when they are encountered in transitive dependencies or in dependencies where no version has been specified. In the example in the preceding section a dependency was directly added to A even though it is not directly used by A. Instead, A can include D as a dependency in its dependencyManagement section and directly control which version of D is used when, or if, it is ever re [...]
-- _Dependency scope_ - this allows you to only include dependencies appropriate for the current stage of the build. This is described in more detail below.
-- _Excluded dependencies_ - If project X depends on project Y, and project Y depends on project Z, the owner of project X can explicitly exclude project Z as a dependency, using the "exclusion" element.
-- _Optional dependencies_ - If project Y depends on project Z, the owner of project Y can mark project Z as an optional dependency, using the "optional" element. When project X depends on project Y, X will depend only on Y and not on Y's optional dependency Z. The owner of project X may then explicitly add a dependency on Z, at her option. (It may be helpful to think of optional dependencies as "excluded by default.")
+ - _Dependency management_ - this allows project authors to directly specify the versions of artifacts to be used when they are encountered in transitive dependencies or in dependencies where no version has been specified. In the example in the preceding section a dependency was directly added to A even though it is not directly used by A. Instead, A can include D as a dependency in its dependencyManagement section and directly control which version of D is used when, or if, it is ever r [...]
+
+ - _Dependency scope_ - this allows you to only include dependencies appropriate for the current stage of the build. This is described in more detail below.
+
+ - _Excluded dependencies_ - If project X depends on project Y, and project Y depends on project Z, the owner of project X can explicitly exclude project Z as a dependency, using the "exclusion" element.
+
+ - _Optional dependencies_ - If project Y depends on project Z, the owner of project Y can mark project Z as an optional dependency, using the "optional" element. When project X depends on project Y, X will depend only on Y and not on Y's optional dependency Z. The owner of project X may then explicitly add a dependency on Z, at her option. (It may be helpful to think of optional dependencies as "excluded by default.")
+
Although transitive dependencies can implicitly include desired dependencies, it is a good practice to explicitly specify the dependencies your source code uses directly. This best practice proves its value especially when the dependencies of your project change their dependencies.
+
For example, assume that your project A specifies a dependency on another project B, and project B specifies a dependency on project C. If you are directly using components in project C, and you don't specify project C in your project A, it may cause build failure when project B suddenly updates/removes its dependency on project C.
+
Another reason to directly specify dependencies is that it provides better documentation for your project: one can learn more information by just reading the POM file in your project, or by executing **mvn dependency:tree**.
+
Maven also provides [dependency:analyze](/plugins/maven-dependency-plugin/analyze-mojo.html) plugin goal for analyzing the dependencies: it helps making this best practice more achievable.
+
+
### Dependency Scope
+
Dependency scope is used to limit the transitivity of a dependency and to determine when a dependency is included in a classpath.
+
There are 6 scopes:
-- **compile**\
+
+
+ - **compile**\
This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
-- **provided**\
+ - **provided**\
This is much like `compile`, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope `provided` because the web container provides those classes. A dependency with this scope is added to the classpath used for compilation and test, but not the runtime classpath. It is not transitive.
-- **runtime**\
+ - **runtime**\
This scope indicates that the dependency is not required for compilation, but is for execution. Maven includes a dependency with this scope in the runtime and test classpaths, but not the compile classpath.
-- **test**\
+ - **test**\
This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases. This scope is not transitive. Typically this scope is used for test libraries such as JUnit and Mockito. It is also used for non-test libraries such as Apache Commons IO if those libraries are used in unit tests (src/test/java) but not in the model code (src/main/java).
-- **system**\
+ - **system**\
This scope is similar to `provided` except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
-- **import**\
+ - **import**\
This scope is only supported on a dependency of type `pom` in the `<dependencyManagement>` section. It indicates the dependency is to be replaced with the effective list of dependencies in the specified POM's `<dependencyManagement>` section. Since they are replaced, dependencies with a scope of `import` do not actually participate in limiting the transitivity of a dependency.
+
Each of the scopes (except for `import`) affects transitive dependencies in different ways, as is demonstrated in the table below. If a dependency is set to the scope in the left column, a transitive dependency of that dependency with the scope across the top row results in a dependency in the main project with the scope listed at the intersection. If no scope is listed, it means the dependency is omitted.
+
||compile|provided|runtime|test|
|---|---|---|---|---|
|compile|compile(*)|-|runtime|-|
@@ -127,12 +160,18 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
**(\*) Note:** it is intended that this should be runtime scope instead, so that all compile dependencies must be explicitly listed. However, if a library you depend on extends a class from another library, both must be available at compile time. For this reason, compile time dependencies remain as compile scope even when they are transitive.
+
+
### Dependency Management
+
The dependency management section is a mechanism for centralizing dependency information. When you have a set of projects that inherit from a common parent, it's possible to put all information about the dependency in the common POM and have simpler references to the artifacts in the child POMs. The mechanism is best illustrated through some examples. Given these two POMs which extend the same parent:
+
Project A:
+
+
```
<project>
@@ -163,6 +202,8 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project B:
+
+
```
<project>
@@ -189,6 +230,8 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
These two example POMs share a common dependency and each has one non-trivial dependency. This information can be put in the parent POM like this:
+
+
```
<project>
@@ -232,6 +275,8 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Then the two child POMs become much simpler:
+
+
```
<project>
@@ -253,6 +298,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
```
+
```
<project>
@@ -278,10 +324,14 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
**NOTE:** In two of these dependency references, we had to specify the `<type>` element. This is because the minimal set of information for matching a dependency reference against a dependencyManagement section is actually **{groupId, artifactId, type, classifier}**. In many cases, these dependencies will refer to jar artifacts with no classifier. This allows us to shorthand the identity set to **{groupId, artifactId}**, since the default for the type field is `jar`, and the default cla [...]
+
A second, and very important use of the dependency management section is to control the versions of artifacts used in transitive dependencies. As an example consider these projects:
+
Project A:
+
+
```
<project>
@@ -323,6 +373,8 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project B:
+
+
```
<project>
@@ -367,20 +419,28 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
When maven is run on project B, version 1.0 of artifacts a, b, c, and d will be used regardless of the version specified in their POM.
-- a and c both are declared as dependencies of the project so version 1.0 is used due to dependency mediation. Both also have runtime scope since it is directly specified.
-- b is defined in B's parent's dependency management section and since dependency management takes precedence over dependency mediation for transitive dependencies, version 1.0 will be selected should it be referenced in a or c's POM. b will also have compile scope.
-- Finally, since d is specified in B's dependency management section, should d be a dependency (or transitive dependency) of a or c, version 1.0 will be chosen - again because dependency management takes precedence over dependency mediation and also because the current POM's declaration takes precedence over its parent's declaration.
+ - a and c both are declared as dependencies of the project so version 1.0 is used due to dependency mediation. Both also have runtime scope since it is directly specified.
+
+ - b is defined in B's parent's dependency management section and since dependency management takes precedence over dependency mediation for transitive dependencies, version 1.0 will be selected should it be referenced in a or c's POM. b will also have compile scope.
+
+ - Finally, since d is specified in B's dependency management section, should d be a dependency (or transitive dependency) of a or c, version 1.0 will be chosen - again because dependency management takes precedence over dependency mediation and also because the current POM's declaration takes precedence over its parent's declaration.
+
The reference information about the dependency management tags is available from the [project descriptor reference](../../ref/current/maven-model/maven.html#class_DependencyManagement).
+
#### Importing Dependencies
+
The examples in the previous section describe how to specify managed dependencies through inheritance. However, in larger projects it may be impossible to accomplish this since a project can only inherit from a single parent. To accommodate this, projects can import managed dependencies from other projects. This is accomplished by declaring a POM artifact as a dependency with a scope of "import".
+
Project B:
+
+
```
<project>
@@ -427,8 +487,11 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Assuming A is the POM defined in the preceding example, the end result would be the same. All of A's managed dependencies would be incorporated into B except for d since it is defined in this POM.
+
Project X:
+
+
```
<project>
@@ -460,6 +523,8 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project Y:
+
+
```
<project>
@@ -491,6 +556,8 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project Z:
+
+
```
<project>
@@ -525,14 +592,21 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
In the example above Z imports the managed dependencies from both X and Y. However, both X and Y contain dependency a. Here, version 1.1 of a would be used since X is declared first and a is not declared in Z's dependencyManagement.
+
This process is recursive. For example, if X imports another POM, Q, when Z is processed it will simply appear that all of Q's managed dependencies are defined in X.
+
+
#### Bill of Materials (BOM) POMs
+
Imports are most effective when used for defining a "library" of related artifacts that are generally part of a multiproject build. It is fairly common for one project to use one or more artifacts from these libraries. However, it has sometimes been difficult to keep the versions in the project using the artifacts in synch with the versions distributed in the library. The pattern below illustrates how a "bill of materials" (BOM) can be created for use by other projects.
+
The root of the project is the BOM POM. It defines the versions of all the artifacts that will be created in the library. Other projects that wish to use the library should import this POM into the dependencyManagement section of their POM.
+
+
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -571,6 +645,8 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
The parent subproject has the BOM POM as its parent. It is a normal multiproject pom.
+
+
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -611,6 +687,8 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Next are the actual project POMs.
+
+
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -659,6 +737,8 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
The project that follows shows how the library can now be used in another project without having to specify the dependent project's versions.
+
+
```
<project 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/maven-4.0.0.xsd">
@@ -695,20 +775,30 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Finally, when creating projects that import dependencies, beware of the following:
-- Do not attempt to import a POM that is defined in a submodule of the current POM. Attempting to do that will result in the build failing since it won't be able to locate the POM.
-- Never declare the POM importing a POM as the parent (or grandparent, etc) of the target POM. There is no way to resolve the circularity and an exception will be thrown.
-- When referring to artifacts whose POMs have transitive dependencies, the project needs to specify versions of those artifacts as managed dependencies. Not doing so results in a build failure since the artifact may not have a version specified. (This should be considered a best practice in any case as it keeps the versions of artifacts from changing from one build to the next).
+ - Do not attempt to import a POM that is defined in a submodule of the current POM. Attempting to do that will result in the build failing since it won't be able to locate the POM.
+
+ - Never declare the POM importing a POM as the parent (or grandparent, etc) of the target POM. There is no way to resolve the circularity and an exception will be thrown.
+
+ - When referring to artifacts whose POMs have transitive dependencies, the project needs to specify versions of those artifacts as managed dependencies. Not doing so results in a build failure since the artifact may not have a version specified. (This should be considered a best practice in any case as it keeps the versions of artifacts from changing from one build to the next).
+
+
+
### System Dependencies
+
`Important note: This is deprecated.`
+
Dependencies with the scope _system_ are always available and are not looked up in repository. They are usually used to tell Maven about dependencies which are provided by the JDK or the VM. Thus, system dependencies are especially useful for resolving dependencies on artifacts which are now provided by the JDK, but were available as separate downloads earlier. Typical examples are the JDBC standard extensions or the Java Authentication and Authorization Service (JAAS).
+
A simple example would be:
+
+
```
<project>
@@ -729,6 +819,8 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
If your artifact is provided by the JDK's `tools.jar`, the system path would be defined as follows:
+
+
```
<project>
...
@@ -744,3 +836,5 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
...
</project>
```
+
+
diff --git a/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md b/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md
index 862c6aac..88e29c2f 100644
--- a/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md
+++ b/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md
@@ -22,22 +22,33 @@ under the License.
-->
## Introduction
+
This section discusses optional dependencies and dependency exclusions. This will help users to understand what they are and when and how to use them. It also explains why exclusions are made on a per dependency basis instead of at the POM level.
+
### Optional Dependencies
- Optional dependencies are used when it's not possible (for whatever reason) to split a project into sub-modules. The idea is that some of the dependencies are only used for certain features in the project and will not be needed if that feature isn't used. Ideally, such a feature would be split into a sub-module that depends on the core functionality project. This new subproject would have only non-optional dependencies, since you'd need them all if you decided to use the subproject's fu [...]
+
+ Optional dependencies are used when it's not possible (for whatever reason) to split a project into sub-modules. The idea is that some of the dependencies are only used for certain features in the project and will not be needed if that feature isn't used. Ideally, such a feature would be split into a sub-module that depends on the core functionality project. This new subproject would have only non-optional dependencies, since you'd need them all if you decided to use the subproject's fu [...]
+
However, since the project cannot be split up (again, for whatever reason), these dependencies are declared optional. If a user wants to use functionality related to an optional dependency, they have to redeclare that optional dependency in their own project. This is not the clearest way to handle this situation, but both optional dependencies and dependency exclusions are stop-gap solutions.
+
#### Why use optional dependencies?
- Optional dependencies save space and memory. They prevent problematic jars that violate a license agreement or cause classpath issues from being bundled into a WAR, EAR, fat jar, or the like.
+
+ Optional dependencies save space and memory. They prevent problematic jars that violate a license agreement or cause classpath issues from being bundled into a WAR, EAR, fat jar, or the like.
+
+
#### How do I use the optional tag?
+
A dependency is declared optional by setting the `<optional>` element to true in its dependency declaration:
+
+
```
<project>
@@ -56,8 +67,11 @@ under the License.
```
+
#### How do optional dependencies work?
+
+
```
Project-A -> Project-B
@@ -66,6 +80,8 @@ Project-A -> Project-B
The diagram above says that Project-A depends on Project-B. When A declares B as an optional dependency in its POM, this relationship remains unchanged. It's just like a normal build where Project-B will be added in Project-A's classpath.
+
+
```
Project-X -> Project-A
@@ -74,18 +90,29 @@ Project-X -> Project-A
When another project (Project-X) declares Project-A as a dependency in its POM, the optional nature of the dependency takes effect. Project-B is not included in the classpath of Project-X. You need to declare it directly in the POM of Project X for B to be included in X's classpath.
+
+
#### Example
+
Suppose there is a project named _X2_ that has similar functionality to _Hibernate_. It supports many databases such as MySQL, PostgreSQL, and several versions of Oracle. Each supported database requires an additional dependency on a driver jar. All of these dependencies are needed at compile time to build X2. However your project only uses one specific database and doesn't need drivers for the others. X2 can declare these dependencies as optional, so that when your project declares X2 [...]
+
+
+
### Dependency Exclusions
+
Since Maven resolves dependencies transitively, it is possible for unwanted dependencies to be included in your project's classpath. For example, a certain older jar may have security issues or be incompatible with the Java version you're using. To address this, Maven allows you to exclude specific dependencies. Exclusions are set on a specific dependency in your POM, and are targeted at a specific groupId and artifactId. When you build your project, that artifact will not be added to y [...]
+
#### How to use dependency exclusions
+
Add an `<exclusions>` element in the `<dependency>` element by which the problematic jar is included.
+
+
```
<project>
@@ -108,8 +135,11 @@ Project-X -> Project-A
```
+
#### How dependency exclusion works and when to use it **( as a last resort! )**
+
+
```
Project-A
@@ -123,12 +153,16 @@ Project-A
The diagram shows that Project-A depends on both Project-B and C. Project-B depends on Project-D. Project-D depends on both Project-E and F. By default, Project A's classpath will include:
+
+
```
B, C, D, E, F
```
Suppose you don't want project D and its dependencies to be added to Project A's classpath because some of Project-D's dependencies are missing from the repository, and you don't need the functionality in Project-B that depends on Project-D anyway. Project-B's developers could have marked the dependency on Project-D `<optional>true</optional>`:
+
+
```
<dependency>
<groupId>sample.ProjectD</groupId>
@@ -140,6 +174,8 @@ B, C, D, E, F
Unfortunately, they didn't. As a last resort, you can exclude it on your own POM for Project-A like this:
+
+
```
<project>
@@ -168,16 +204,21 @@ B, C, D, E, F
If you deploy Project-A to a repository, and Project-X declares a normal dependency on Project-A, will Project-D still be excluded from the classpath?
+
+
```
Project-X -> Project-A
```
- The answer is **Yes**. Project-A has declared that it doesn't need Project-D to run, so it won't be brought in as a transitive dependency of Project-A.
+ The answer is **Yes**. Project-A has declared that it doesn't need Project-D to run, so it won't be brought in as a transitive dependency of Project-A.
+
Now, consider that Project-X depends on Project-Y, as in the diagram below:
+
+
```
Project-X -> Project-Y
@@ -187,10 +228,13 @@ Project-X -> Project-Y
```
- Project-Y also has a dependency on Project-B, and it does need the features supported by Project-D. Therefore, it will NOT place an exclusion on Project-D in its dependency list. It may also supply an additional repository, from which it can resolve Project-E. In this case, it's important that Project-D **is not** excluded globally, since it is a legitimate dependency of Project-Y.
+ Project-Y also has a dependency on Project-B, and it does need the features supported by Project-D. Therefore, it will NOT place an exclusion on Project-D in its dependency list. It may also supply an additional repository, from which it can resolve Project-E. In this case, it's important that Project-D **is not** excluded globally, since it is a legitimate dependency of Project-Y.
+
As another scenario, suppose the dependency you don't want is Project-E instead of Project-D. How do you exclude it? See the diagram below:
+
+
```
Project-A
@@ -202,7 +246,9 @@ Project-A
```
- Exclusions work on the entire dependency graph below the point where they are declared. If you want to exclude Project-E instead of Project-D, simply change the exclusion to point at Project-E, but you don't move the exclusion down to Project-D. You cannot change Project-D's POM. If you could, you would use optional dependencies instead of exclusions, or split Project-D up into multiple subprojects, each with nothing but normal dependencies.
+ Exclusions work on the entire dependency graph below the point where they are declared. If you want to exclude Project-E instead of Project-D, simply change the exclusion to point at Project-E, but you don't move the exclusion down to Project-D. You cannot change Project-D's POM. If you could, you would use optional dependencies instead of exclusions, or split Project-D up into multiple subprojects, each with nothing but normal dependencies.
+
+
```
@@ -230,8 +276,15 @@ Project-A
```
+
#### Why exclusions are made on a per-dependency basis, rather than at the POM level
+
This is mainly to be sure the dependency graph is predictable, and to keep inheritance effects from excluding a dependency that should not be excluded. If you get to the method of last resort and have to put in an exclusion, you should be absolutely certain which of your dependencies is bringing in that unwanted transitive dependency.
- If you truly want to ensure that a particular dependency appears nowhere in your classpath, regardless of path, the [banned dependencies rule](/enforcer/enforcer-rules/bannedDependencies.html) can be configured to fail the build if a problematic dependency is found. When the build fails, you'll need to add specific exclusions on each path the enforcer finds.
+
+ If you truly want to ensure that a particular dependency appears nowhere in your classpath, regardless of path, the [banned dependencies rule](/enforcer/enforcer-rules/bannedDependencies.html) can be configured to fail the build if a problematic dependency is found. When the build fails, you'll need to add specific exclusions on each path the enforcer finds.
+
+
+
+
diff --git a/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md b/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
index 41e21074..9f144e42 100644
--- a/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
+++ b/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
@@ -22,22 +22,32 @@ under the License.
-->
## Introduction to Plugin Prefix Resolution
+
When you execute Maven using a standard lifecycle phase, resolving the plugins that participate in that lifecycle is a relatively simple process. However, when you directly invoke a mojo from the command line, as in the case of **clean**, Maven must have some way of reliably resolving the **clean** plugin prefix to the **maven-clean-plugin**. This provides brevity for command-line invocations, while preserving the descriptiveness of the plugin's real artifactId.
+
To complicate matters even more, not all plugins should be forced to have the same groupId in the repository. Since groupIds are presumed to be controlled by one project, and multiple projects may release plugins for Maven, it follows that plugin-prefix mappings must also accommodate multiple plugin groupIds.
+
To address these concerns, Maven provides a new piece of repository-level metadata (not associated with any single artifact) for plugin groups, along with a plugin mapping manager to organize multiple plugin groups and provide search functionality.
+
### Specifying a Plugin's Prefix
+
In order to give users a convenient prefix with which to reference your plugin a prefix must be associated with your plugin when it is built. By default, Maven will make a guess at the plugin-prefix to be used, by removing any instances of "maven" or "plugin" surrounded by hyphens in the plugin's artifact ID. The conventional artifact ID formats to use are:
-- `maven-${prefix}-plugin` - for official plugins maintained by the Apache Maven team itself (you **must not** use this naming pattern for your plugin, see [this note for more informations](../plugin/guide-java-plugin-development.html#plugin-naming-convention-and-apache-maven-trademark))
-- `${prefix}-maven-plugin` - for plugins from other sources
+
+ - `maven-${prefix}-plugin` - for official plugins maintained by the Apache Maven team itself (you **must not** use this naming pattern for your plugin, see [this note for more informations](../plugin/guide-java-plugin-development.html#plugin-naming-convention-and-apache-maven-trademark))
+
+ - `${prefix}-maven-plugin` - for plugins from other sources
+
If your plugin's artifactId fits this pattern, Maven will automatically map your plugin to the correct prefix in the metadata stored within your plugin's groupId path on the repository. However, if you want to customize the prefix used to reference your plugin, you can specify the prefix directly through a configuration parameter on the `maven-plugin-plugin` in your plugin's POM:
+
+
```
<project>
...
@@ -60,28 +70,41 @@ under the License.
The above configuration will allow users to refer to your plugin by the prefix **somePrefix**, as in the following example:
+
+
```
mvn somePrefix:goal
```
+
### Mapping Prefixes to Plugins
+
For each groupId configured for searching, Maven will:
+
+
1 Download `maven-metadata.xml` from each remote repository into the local repository, and name it `maven-metadata-${repoId}.xml` within the path of `${groupId}`.
1 Load these metadata files, along with `maven-metadata-local.xml` (if it exists), within the path of `${groupId}`. Merge them.
1 Lookup the plugin prefix in the merged metadata. If it's mapped, it should refer to a concrete groupId-artifactId pair. Otherwise, go on to #1 for the next groupId in the user's plugin-groups.
+
These metadata files consist of the **groupId** it represents (for clarity when the file is opened outside the context of the directory), and a group of **plugin** elements. Each **plugin** in this list contains a **prefix** element denoting the plugin's command-line prefix, and an **artifactId** element, which provides the other side of the prefix mapping and provides enough information to lookup and use the plugin. When a plugin is installed or deployed, the appropriate metadata file [...]
+
+
### Configuring Maven to Search for Plugins
+
By default, Maven will search the groupId **org.apache.maven.plugins** for prefix-to-artifactId mappings for the plugins it needs to perform a given build. However, as previously mentioned, the user may have a need for third-party plugins. Since the Maven project is assumed to have control over the default plugin groupId, this means configuring Maven to search other groupId locations for plugin-prefix mappings.
+
As it turns out, this is simple. In the Maven settings file (per-user: `${user.home}/.m2/settings.xml`; global: `${maven.home}/conf/settings.xml`), you can provide a custom **pluginGroups** section, listing the plugin groupIds you want to search (each groupId goes in its own **pluginGroup** sub-element). For example, if my project uses a Modello model file, I might have the following in my settings:
+
+
```
<pluginGroups>
<pluginGroup>org.codehaus.modello</pluginGroup>
@@ -90,20 +113,32 @@ mvn somePrefix:goal
This allows me to execute the following, which will generate Java classes from the model:
+
+
```
mvn -Dversion=4.0.0 -Dmodel=maven.mdo modello:java
```
Maven will always search the following groupId's **after** searching any plugin groups specified in the user's settings:
-- org.apache.maven.plugins
-- org.codehaus.mojo
+
+ - org.apache.maven.plugins
+
+ - org.codehaus.mojo
+
**NOTE:** When specifying plugin groups to be used in searching for a prefix mapping, order is critical! By specifying a pluginGroup of `com.myco.plugins` with a prefix of `clean`, I can override the usage of the `maven-clean-plugin` when `clean:clean` is invoked.
+
**NOTE2:** For more information on `settings.xml`, see \[[1](a1)\].
+
+
### Resources
+
1 [Guide to Configuring Maven](../mini/guide-configuring-maven.html)
+
+
+
diff --git a/content/markdown/guides/introduction/introduction-to-plugins.md b/content/markdown/guides/introduction/introduction-to-plugins.md
index 29c1e5f8..2b3ef553 100644
--- a/content/markdown/guides/introduction/introduction-to-plugins.md
+++ b/content/markdown/guides/introduction/introduction-to-plugins.md
@@ -23,28 +23,47 @@ under the License.
## Introduction to Maven Plugin Development
+
Maven consists of a core engine which provides basic project-processing capabilities and build-process management, and a host of plugins which are used to execute the actual build tasks.
+
### What is a Plugin?
+
"Maven" is really just a core framework for a collection of Maven Plugins. In other words, plugins are where much of the real action is performed, plugins are used to: create jar files, create war files, compile code, unit test code, create project documentation, and on and on. Almost any action that you can think of performing on a project is implemented as a Maven plugin.
+
Plugins are the central feature of Maven that allow for the reuse of common build logic across multiple projects. They do this by executing an "action" (i.e. creating a WAR file or compiling unit tests) in the context of a project's description - the Project Object Model (POM). Plugin behavior can be customized through a set of unique parameters which are exposed by a description of each plugin goal (or Mojo).
+
One of the simplest plugins in Maven is the Clean Plugin. The [Maven Clean plugin](../../plugins/maven-clean-plugin/) (maven-clean-plugin) is responsible for removing the target directory of a Maven project. When you run "mvn clean", Maven executes the "clean" goal as defined in the Clean plug-in, and the target directory is removed. The Clean plugin [defines a parameter](../../plugins/maven-clean-plugin/clean-mojo.html) which can be used to customize plugin behavior, this parameter is [...]
+
+
### What is a Mojo (_And Why the H--- is it Named 'Mojo'_)?
+
A Mojo is really just a **goal** in Maven, and plug-ins consist of any number of goals (Mojos). Mojos can be defined as annotated Java classes or Beanshell script. A Mojo specifies metadata about a goal: a goal name, which phase of the lifecycle it fits into, and the parameters it is expecting.
+
MOJO is a play on POJO (Plain-old-Java-object), substituting "Maven" for "Plain". Mojo is also an interesting word (see [definition](http://www.answers.com/mojo&r=67)). From [Wikipedia](http://www.wikipedia.org), a "mojo" is defined as: "...a small bag worn by a person under the clothes (also known as a mojo hand). Such bags were thought to have supernatural powers, such as protecting from evil, bringing good luck, etc."
+
+
### What is the Build Lifecycle? (Overview)
+
The build lifecycle is a series of common **stage**s through which all project builds naturally progress. Plugin goals are bound to specific stages in the lifecycle.
+
+
+
## Resources
+
+
1 [Plugin Development Center](/plugin-developers/index.html)
1 [Configuring plugins](../mini/guide-configuring-plugins.html)
+
+
diff --git a/content/markdown/guides/introduction/introduction-to-profiles.md b/content/markdown/guides/introduction/introduction-to-profiles.md
index 7b0e9d94..9b7caf2d 100644
--- a/content/markdown/guides/introduction/introduction-to-profiles.md
+++ b/content/markdown/guides/introduction/introduction-to-profiles.md
@@ -23,15 +23,17 @@ under the License.
## Introduction to Build Profiles
-- [What are the different types of profile? Where is each defined?](#what-are-the-different-types-of-profile-where-is-each-defined)
-- [How can a profile be triggered? How does this vary according to the type of profile being used?](#how-can-a-profile-be-triggered-how-does-this-vary-according-to-the-type-of-profile-being-used)
-- [Details on profile activation](#details-on-profile-activation)
+ - [What are the different types of profile? Where is each defined?](#what-are-the-different-types-of-profile-where-is-each-defined)
-- [Explicit profile activation](#explicit-profile-activation)
+ - [How can a profile be triggered? How does this vary according to the type of profile being used?](#how-can-a-profile-be-triggered-how-does-this-vary-according-to-the-type-of-profile-being-used)
-- [Implicit profile activation](#implici-profile-activation)
+ - [Details on profile activation](#details-on-profile-activation)
+
+ - [Explicit profile activation](#explicit-profile-activation)
+
+ - [Implicit profile activation](#implici-profile-activation)
- [JDK](#jdk)
@@ -41,82 +43,120 @@ under the License.
- [Files](#files)
-- [Deactivating a profile](#deactivating-a-profile)
-- [Which areas of a POM can be customized by each type of profile? Why?](#which-areas-of-a-pom-can-be-customized-by-each-type-of-profile-why)
-- [Profiles in external files](#profiles-in-external-files)
-- [Profiles in POMs](#profiles-in-poms)
-- [POM elements outside `<profiles>`](#pom-elements-outside-profiles)
+ - [Deactivating a profile](#deactivating-a-profile)
+
+
+
+ - [Which areas of a POM can be customized by each type of profile? Why?](#which-areas-of-a-pom-can-be-customized-by-each-type-of-profile-why)
+
+ - [Profiles in external files](#profiles-in-external-files)
+
+ - [Profiles in POMs](#profiles-in-poms)
+
+ - [POM elements outside `<profiles>`](#pom-elements-outside-profiles)
+
+
+
+ - [Profile Order](#profile-order)
-- [Profile Order](#profile-order)
+ - [Profile Pitfalls](#profile-pitfalls)
-- [Profile Pitfalls](#profile-pitfalls)
+ - [External Properties](#external-properties)
-- [External Properties](#external-properties)
+ - [Incomplete Specification of a Natural Profile Set](#incomplete-specification-of-a-natural-profile-set)
-- [Incomplete Specification of a Natural Profile Set](#incomplete-specification-of-a-natural-profile-set)
-- [How can I tell which profiles are in effect during a build?](#how-can-i-tell-which-profiles-are-in-effect-during-a-build)
-- [Naming Conventions](#naming-conventions)
+ - [How can I tell which profiles are in effect during a build?](#how-can-i-tell-which-profiles-are-in-effect-during-a-build)
+
+ - [Naming Conventions](#naming-conventions)
+
Apache Maven goes to great lengths to ensure that builds are portable. Among other things, this means allowing build configuration inside the POM, avoiding **all** filesystem references (in inheritance, dependencies, and other places), and leaning much more heavily on the local repository to store the metadata needed to make this possible.
+
However, sometimes portability is not entirely possible. Under certain conditions, plugins may need to be configured with local filesystem paths. Under other circumstances, a slightly different dependency set will be required, and the project's artifact name may need to be adjusted slightly. And at still other times, you may even need to include a whole plugin in the build lifecycle depending on the detected build environment.
+
To address these circumstances, Maven supports build profiles. Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing, and production environments). [...]
+
### What are the different types of profile? Where is each defined?
-- Per Project
- - Defined in the POM itself `(pom.xml)`.
-- Per User
+ - Per Project
+
+ - Defined in the POM itself `(pom.xml)`.
+
+
+
+ - Per User
+
+ - Defined in the [ Maven-settings](/ref/current/maven-settings/settings.html) `(%USER_HOME%/.m2/settings.xml)`.
+
- - Defined in the [Maven-settings](/ref/current/maven-settings/settings.html) `(%USER_HOME%/.m2/settings.xml)`.
-- Global
+ - Global
+
+ - Defined in the [ global Maven-settings](/ref/current/maven-settings/settings.html) `(${maven.home}/conf/settings.xml)`.
+
+
+
+ - Profile descriptor
+
+ - a descriptor located in [project basedir `(profiles.xml)`](/ref/2.2.1/maven-profile/profiles.html) (no longer supported in Maven 3.0 and above; see [ Maven 3 compatibility notes](https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-profiles.xml))
+
- - Defined in the [global Maven-settings](/ref/current/maven-settings/settings.html) `(${maven.home}/conf/settings.xml)`.
-- Profile descriptor
- - a descriptor located in [project basedir `(profiles.xml)`](/ref/2.2.1/maven-profile/profiles.html) (no longer supported in Maven 3.0 and above; see [Maven 3 compatibility notes](https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-profiles.xml))
### How can a profile be triggered? How does this vary according to the type of profile being used?
+
A profile can be activated in several ways:
-- Explicitly
-- Implicitly
-- Based on OS
+ - Explicitly
+
+ - Implicitly
+
+ - Based on OS
-- Based on system properties
+ - Based on system properties
+
+ - Based on presence of files
-- Based on presence of files
Refer to the sections below for details.
+
#### Details on profile activation
+
##### Explicit profile activation
+
Profiles can be explicitly specified using the `-P` command line flag.
+
This flag is followed by a comma-delimited list of profile IDs to use. The profile(s) specified in the option are activated in addition to any profiles which are activated by their activation configuration or the `<activeProfiles>` section in `settings.xml`. From Maven 4 onward, Maven will refuse to activate or deactivate a profile that cannot be resolved. To prevent this, prefix the profile identifier with an `?`, marking it as optional:
+
+
```
mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
```
Profiles can be activated in the Maven settings, via the `<activeProfiles>` section. This section takes a list of `<activeProfile>` elements, each containing a profile-id inside.
+
+
```
<settings>
...
@@ -129,14 +169,21 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
Profiles listed in the `<activeProfiles>` tag would be activated by default every time a project use it.
+
+
##### Implicit profile activation
+
Profiles can be automatically triggered based on the detected state of the build environment. These triggers are specified via an `<activation>` section in the profile itself. Currently, this detection is limited to JDK version matching, operating system matching or the presence/the value of a system property. Here are some examples.
+
###### JDK
+
The following configuration will trigger the profile when the JDK's version _starts with_ "1.4" (eg. "1.4.0_08", "1.4.2_07", "1.4"), in particular it _won't be active_ for **newer** versions like "1.8" or "11":
+
+
```
<profiles>
<profile>
@@ -148,7 +195,9 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
</profiles>
```
- Ranges can also be used as of Maven 2.1 (refer to the [Enforcer Version Range Syntax](/enforcer/enforcer-rules/versionRanges.html) for more information). Range values must start with either `\[` or `(` otherwise the value is interpreted as prefix. The following honours versions 1.3, 1.4 and 1.5.
+ Ranges can also be used as of Maven 2.1 (refer to the [ Enforcer Version Range Syntax](/enforcer/enforcer-rules/versionRanges.html) for more information). Range values must start with either `\[` or `(` otherwise the value is interpreted as prefix. The following honours versions 1.3, 1.4 and 1.5.
+
+
```
<profiles>
@@ -163,10 +212,15 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
_Note:_ an upper bound such as `,1.5\]` is likely not to include most releases of 1.5, since they will have an additional "patch" release such as `_05` that is not taken into consideration in the above range.
+
+
###### OS
+
This next one will activate based on the detected operating system. See the [Maven Enforcer Plugin](/enforcer/enforcer-rules/requireOS.html) for more details about OS values.
+
+
```
<profiles>
<profile>
@@ -183,10 +237,14 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
</profiles>
```
+
###### Property
+
The profile below will be activated when the system property "debug" is specified with any value:
+
+
```
<profiles>
<profile>
@@ -202,6 +260,8 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
The following profile will be activated when the system property "debug" is not defined at all:
+
+
```
<profiles>
<profile>
@@ -217,6 +277,8 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
The following profile will be activated when the system property "debug" is not defined, or is defined with a value which is not "true".
+
+
```
<profiles>
<profile>
@@ -233,6 +295,8 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
To activate this you would type one of those on the command line:
+
+
```
mvn groupId:artifactId:goal
mvn groupId:artifactId:goal -Ddebug=false
@@ -240,6 +304,8 @@ mvn groupId:artifactId:goal -Ddebug=false
The next example will trigger the profile when the system property "environment" is specified with the value "test":
+
+
```
<profiles>
<profile>
@@ -256,16 +322,22 @@ mvn groupId:artifactId:goal -Ddebug=false
To activate this you would type this on the command line:
+
+
```
mvn groupId:artifactId:goal -Denvironment=test
```
As of Maven 3.0, profiles in the POM can also be activated based on properties from active profiles from the `settings.xml`.
+
**Note**: Environment variables like `FOO` are available as properties of the form `env.FOO`. Further note that environment variable names are normalized to all upper-case on Windows.
+
Since Maven 3.9.0 one can also evaluate the POM's packaging value by referencing property `packaging`. This is only useful where the profile activation is defined in a common parent POM which is reused among multiple Maven projects. The next example will trigger the profile when a project with packaging `war` is built:
+
+
```
<profiles>
<profile>
@@ -280,10 +352,14 @@ mvn groupId:artifactId:goal -Denvironment=test
</profiles>
```
+
###### Files
+
This example will trigger the profile when the generated file `target/generated-sources/axistools/wsdl2java/org/apache/maven` is missing.
+
+
```
<profiles>
<profile>
@@ -299,8 +375,11 @@ mvn groupId:artifactId:goal -Denvironment=test
As of Maven 2.0.9, the tags `<exists>` and `<missing>` could be interpolated. Supported variables are system properties like `${user.home}` and environment variables like `${env.HOME}`. Please note that properties and values defined in the POM itself are not available for interpolation here, e.g. the above example activator cannot use `${project.build.directory}` but needs to hard-code the path `target`.
+
Profiles can also be active by default using a configuration like the following:
+
+
```
<profiles>
<profile>
@@ -315,90 +394,126 @@ mvn groupId:artifactId:goal -Denvironment=test
This profile will automatically be active for all builds unless another profile in the same POM is activated using one of the previously described methods. All profiles that are active by default are automatically deactivated when a profile in the POM is activated on the command line or through its activation config.
+
+
+
+
#### Deactivating a profile
+
Starting with Maven 2.0.10, one or more profiles can be deactivated using the command line by prefixing their identifier with either the character '!' or '-' as shown below:
+
+
```
mvn groupId:artifactId:goal -P !profile-1,!profile-2,!?profile-3
```
or
+
+
```
mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
```
This can be used to deactivate profiles marked as activeByDefault or profiles that would otherwise be activated through their activation config.
+
+
+
### Which areas of a POM can be customized by each type of profile? Why?
+
Now that we've talked about where to specify profiles, and how to activate them, it will be useful to talk about _what_ you can specify in a profile. As with the other aspects of profile configuration, this answer is not straightforward.
+
Depending on where you choose to configure your profile, you will have access to varying POM configuration options.
+
#### Profiles in external files
+
Profiles specified in external files (i.e in `settings.xml` or `profiles.xml`) are not portable in the strictest sense. Anything that seems to stand a high chance of changing the result of the build is restricted to the inline profiles in the POM. Things like repository lists could simply be a proprietary repository of approved artifacts, and won't change the outcome of the build. Therefore, you will only be able to modify the `<repositories>` and `<pluginRepositories>` sections, plus a [...]
+
The `<properties>` section allows you to specify free-form key-value pairs which will be included in the interpolation process for the POM. This allows you to specify a plugin configuration in the form of `${profile.provided.path}`.
+
+
#### Profiles in POMs
+
On the other hand, if your profiles can be reasonably specified _inside_ the POM, you have many more options. The trade-off, of course, is that you can only modify _that_ project and its sub-modules. Since these profiles are specified inline, and therefore have a better chance of preserving portability, it's reasonable to say you can add more information to them without the risk of that information being unavailable to other users.
+
Profiles specified in the POM can modify [the following POM elements](/ref/current/maven-model/maven.html):
-- `<repositories>`
-- `<pluginRepositories>`
-- `<dependencies>`
+ - `<repositories>`
+
+ - `<pluginRepositories>`
+
+ - `<dependencies>`
+
+ - `<plugins>`
+
+ - `<properties>` (not actually available in the main POM, but used behind the scenes)
-- `<plugins>`
+ - `<modules>`
-- `<properties>` (not actually available in the main POM, but used behind the scenes)
+ - `<reports>`
-- `<modules>`
+ - `<reporting>`
-- `<reports>`
+ - `<dependencyManagement>`
-- `<reporting>`
+ - `<distributionManagement>`
-- `<dependencyManagement>`
+ - a subset of the `<build>` element, which consists of:
-- `<distributionManagement>`
+ - `<defaultGoal>`
-- a subset of the `<build>` element, which consists of:
+ - `<resources>`
-- `<defaultGoal>`
+ - `<testResources>`
-- `<resources>`
+ - `<directory>`
-- `<testResources>`
+ - `<finalName>`
-- `<directory>`
+ - `<filters>`
+
+ - `<pluginManagement>`
+
+ - `<plugins>`
-- `<finalName>`
-- `<filters>`
-- `<pluginManagement>`
-- `<plugins>`
#### POM elements outside `<profiles>`
+
We don't allow modification of some POM elements outside of POM-profiles because these runtime modifications will not be distributed when the POM is deployed to the repository system, making that person's build of that project completely unique from others. While you can do this to some extent with the options given for external profiles, the danger is limited. Another reason is that this POM info is sometimes being reused from the parent POM.
+
External files such as `settings.xml` and `profiles.xml` also does not support elements outside the POM-profiles. Let us take this scenario for elaboration. When the effective POM get deployed to a remote repository, any person can pickup its info out of the repository and use it to build a Maven project directly. Now, imagine that if we can set profiles in dependencies, which is very important to a build, or in any other elements outside POM-profiles in `settings.xml` then most probabl [...]
+
+
+
### Profile Order
+
All profile elements in a POM from active profiles overwrite the global elements with the same name of the POM or extend those in case of collections. In case multiple profiles are active in the same POM or external file, the ones which are defined **later** take precedence over the ones defined **earlier** (independent of their profile id and activation order).
+
Example:
+
+
```
<project>
...
@@ -442,16 +557,24 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
This leads to the repository list: `profile-2-repo, profile-1-repo, global-repo`.
+
+
### Profile Pitfalls
+
We've already mentioned the fact that adding profiles to your build has the potential to break portability for your project. We've even gone so far as to highlight circumstances where profiles are likely to break project portability. However, it's worth reiterating those points as part of a more coherent discussion about some pitfalls to avoid when using profiles.
+
There are two main problem areas to keep in mind when using profiles. First are external properties, usually used in plugin configurations. These pose the risk of breaking portability in your project. The other, more subtle area is the incomplete specification of a natural set of profiles.
+
#### External Properties
+
External property definition concerns any property value defined outside the `pom.xml` but not defined in a corresponding profile inside it. The most obvious usage of properties in the POM is in plugin configuration. While it is certainly possible to break project portability without properties, these critters can have subtle effects that cause builds to fail. For example, specifying appserver paths in a profile that is specified in the `settings.xml` may cause your integration test plu [...]
+
+
```
<project>
...
@@ -474,6 +597,8 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
Now, in your local `${user.home}/.m2/settings.xml`, you have:
+
+
```
<settings>
...
@@ -495,16 +620,24 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
When you build the **integration-test** lifecycle phase, your integration tests pass, since the path you've provided allows the test plugin to install and test this web application.
+
_However_, when your colleague attempts to build to **integration-test**, his build fails spectacularly, complaining that it cannot resolve the plugin configuration parameter `<appserverHome>`, or worse, that the value of that parameter - literally `${appserver.home}` - is invalid (if it warns you at all).
+
Congratulations, your project is now non-portable. Inlining this profile in your `pom.xml` can help alleviate this, with the obvious drawback that each project hierarchy (allowing for the effects of inheritance) now have to specify this information. Since Maven provides good support for project inheritance, it's possible to stick this sort of configuration in the `<pluginManagement>` section of a team-level POM or similar, and simply inherit the paths.
+
Another, less attractive answer might be standardization of development environments. However, this will tend to compromise the productivity gain that Maven is capable of providing.
+
+
#### Incomplete Specification of a Natural Profile Set
+
In addition to the above portability-breaker, it's easy to fail to cover all cases with your profiles. When you do this, you're usually leaving one of your target environments high and dry. Let's take the example `pom.xml` snippet from above one more time:
+
+
```
<project>
...
@@ -527,6 +660,8 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
Now, consider the following profile, which would be specified inline in the `pom.xml`:
+
+
```
<project>
...
@@ -563,44 +698,62 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
This profile looks quite similar to the one from the last example, with a few important exceptions: it's plainly geared toward a development environment, a new profile named `appserverConfig-dev-2` is added and it has an activation section that will trigger its inclusion when the system properties contain "env=dev" for a profile named `appserverConfig-dev` and "env=dev-2" for a profile named `appserverConfig-dev-2`. So, executing:
+
+
```
mvn -Denv=dev-2 integration-test
```
will result in a successful build, applying the properties given by profile named `appserverConfig-dev-2`. And when we execute
+
+
```
mvn -Denv=dev integration-test
```
it will result in a successful build applying the properties given by the profile named `appserverConfig-dev`. However, executing:
+
+
```
mvn -Denv=production integration-test
```
will not do a successful build. Why? Because, the resulting non-interpolated literal value of `${appserver.home}` will not be a valid path for deploying and testing your web application. We haven't considered the case for the production environment when writing our profiles. The "production" environment (env=production), along with "test" and possibly even "local" constitute a natural set of target environments for which we may want to build the integration-test lifecycle phase. The inc [...]
+
As a quick aside, it's possible for user-specific profiles to act in a similar way. This means that profiles for handling different environments which are keyed to the user can act up when the team adds a new developer. While I suppose this _could_ act as useful training for the newbie, it just wouldn't be nice to throw them to the wolves in this way. Again, be sure to think of the _whole_ set of profiles.
+
+
+
### How can I tell which profiles are in effect during a build?
+
Determining active profiles will help the user to know what particular profiles has been executed during a build. We can use the [Maven Help Plugin](/plugins/maven-help-plugin/) to tell what profiles are in effect during a build.
+
+
```
mvn help:active-profiles
```
Let us have some small samples that will help us to understand more on the _active-profiles_ goal of that plugin.
+
From the last example of profiles in the `pom.xml`, you'll notice that there are two profiles named `appserverConfig-dev` and `appserverConfig-dev-2` which has been given different values for properties. If we go ahead and execute:
+
+
```
mvn help:active-profiles -Denv=dev
```
The result will be a bulleted list of the id of the profile with an activation property of "env=dev" together with the source where it was declared. See sample below.
+
+
```
The following profiles are active:
@@ -609,12 +762,16 @@ The following profiles are active:
Now if we have a profile declared in `settings.xml` (refer to the sample of profile in `settings.xml`) and that have been set to be an active profile and execute:
+
+
```
mvn help:active-profiles
```
The result should be something like this
+
+
```
The following profiles are active:
@@ -623,14 +780,19 @@ The following profiles are active:
Even though we don't have an activation property, a profile has been listed as active. Why? Like we mentioned before, a profile that has been set as an active profile in the `settings.xml` is automatically activated.
+
Now if we have something like a profile in the `settings.xml` that has been set as an active profile and also triggered a profile in the POM. Which profile do you think will have an effect on the build?
+
+
```
mvn help:active-profiles -P appserverConfig-dev
```
This will list the activated profiles:
+
+
```
The following profiles are active:
@@ -640,22 +802,34 @@ The following profiles are active:
Even though it listed the two active profiles, we are not sure which one of them has been applied. To see the effect on the build execute:
+
+
```
mvn help:effective-pom -P appserverConfig-dev
```
This will print the effective POM for this build configuration out to the console. Take note that profiles in the `settings.xml` takes higher priority than profiles in the POM. So the profile that has been applied here is `appserverConfig` not `appserverConfig-dev`.
+
If you want to redirect the output from the plugin to a file called `effective-pom.xml`, use the command-line option `-Doutput=effective-pom.xml`.
+
+
### Naming Conventions
+
By now you've noticed that profiles are a natural way of addressing the problem of different build configuration requirements for different target environments. Above, we discussed the concept of a "natural set" of profiles to address this situation, and the importance of considering the whole set of profiles that will be required.
+
However, the question of how to organize and manage the evolution of that set is non-trivial as well. Just as a good developer strives to write self-documenting code, it's important that your profile id's give a hint to their intended use. One good way to do this is to use the common system property trigger as part of the name for the profile. This might result in names like **env-dev**, **env-test**, and **env-prod** for profiles that are triggered by the system property **env**. Such [...]
+
+
```
mvn -Denv=test <phase>
```
The right command-line option can be had by simply substituting "=" for "-" in the profile id.
+
+
+
diff --git a/content/markdown/guides/introduction/introduction-to-repositories.md b/content/markdown/guides/introduction/introduction-to-repositories.md
index 1451569a..fb11b2a1 100644
--- a/content/markdown/guides/introduction/introduction-to-repositories.md
+++ b/content/markdown/guides/introduction/introduction-to-repositories.md
@@ -23,76 +23,120 @@ under the License.
## Introduction to Repositories
+
### Artifact Repositories
+
A repository in Maven holds build artifacts and dependencies of varying types.
+
There are exactly two types of repositories: **local** and **remote**:
+
+
1 the **local** repository is a directory on the computer where Maven runs. It caches remote downloads and contains temporary build artifacts that you have not yet released.
1 **remote** repositories refer to any other type of repository, accessed by a variety of protocols such as `file://` and `https://`. These repositories might be a truly remote repository set up by a third party to provide their artifacts for downloading (for example, [repo.maven.apache.org](https://repo.maven.apache.org/maven2/)). Other "remote" repositories may be internal repositories set up on a file or HTTP server within your company, used to share private artifacts between develop [...]
+
Local and remote repositories are structured the same way so that scripts can run on either side, or they can be synced for offline use. The layout of the repositories is completely transparent to the Maven user, however.
+
+
### Using Repositories
+
In general, you should not need to do anything with the local repository on a regular basis, except clean it out if you are short on disk space (or erase it completely if you are willing to download everything again).
+
For the remote repositories, they are used for both downloading and uploading (if you have the permission to do so).
+
#### Downloading from a Remote Repository
+
Downloading in Maven is triggered by a project declaring a dependency that is not present in the local repository (or for a `SNAPSHOT`, when the remote repository contains one that is newer). By default, Maven will download from the [central](https://repo.maven.apache.org/maven2/) repository.
+
To override this, you need to specify a `mirror` as shown in [Using Mirrors for Repositories](../mini/guide-mirror-settings.html).
+
You can set this in your `settings.xml` file to globally use a certain mirror. However, it is common for a project to [customise the repository in its `pom.xml`](../mini/guide-multiple-repositories.html) and that your setting will take precedence. If dependencies are not being found, check that you have not overridden the remote repository.
+
For more information on dependencies, see [Dependency Mechanism](./introduction-to-dependency-mechanism.html).
+
+
#### Using Mirrors for the Central Repository
+
There are [several official Central repositories](/repository/) geographically distributed. You can make changes to your `settings.xml` file to use one or more mirrors. Instructions for this can be found in the guide [Using Mirrors for Repositories](../mini/guide-mirror-settings.html).
+
+
+
### Building Offline
+
If you are temporarily disconnected from the internet and you need to build your projects offline, you can use the offline switch on the CLI:
+
+
```
mvn -o package
```
Many plugins honor the offline setting and do not perform any operations that connect to the internet. Some examples are resolving Javadoc links and link checking the site.
+
+
### Uploading to a Remote Repository
+
While this is possible for any type of remote repository, you must have the permission to do so. To have someone upload to the Central Maven repository, see [Repository Center](../../repository/index.html).
+
+
### Internal Repositories
+
When using Maven, particularly in a corporate environment, connecting to the internet to download dependencies is not acceptable for security, speed or bandwidth reasons. For that reason, it is desirable to set up an internal repository to house a copy of artifacts, and to publish private artifacts to.
+
Such an internal repository can be downloaded using HTTP or the file system (with a `file://` URL), and uploaded to using SCP, FTP, or a file copy.
+
As far as Maven is concerned, there is nothing special about this repository: it is another **remote repository** that contains artifacts to download to a user's local cache, and is a publish destination for artifact releases.
+
Additionally, you may want to share the repository server with your generated project sites. For more information on creating and deploying sites, see [Creating a Site](../mini/guide-site.html).
+
+
### Setting up the Internal Repository
+
To set up an internal repository just requires that you have a place to put it, and then copy required artifacts there using the same layout as in a remote repository such as [repo.maven.apache.org](https://repo.maven.apache.org/maven2/).
+
It is _not_ recommended that you scrape or `rsync://` a full copy of central as there is a large amount of data there and doing so will get you banned. You can use a program such as those described on the [Repository Management](../../repository-management.html) page to run your internal repository's server, download from the internet as required, and then hold the artifacts in your internal repository for faster downloading later.
+
The other options available are to manually download and vet releases, then copy them to the internal repository, or to have Maven download them for a user, and manually upload the vetted artifacts to the internal repository which is used for releases. This step is the only one available for artifacts where the license forbids their distribution automatically, such as several J2EE JARs provided by Sun. Refer to the [Guide to coping with SUN JARs](../mini/guide-coping-with-sun-jars.html) [...]
+
It should be noted that Maven intends to include enhanced support for such features in the future, including click through licenses on downloading, and verification of signatures.
+
+
### Using the Internal Repository
+
Using the internal repository is quite simple. Simply make a change to add a `repositories` element:
+
+
```
<project>
@@ -110,11 +154,17 @@ under the License.
If your internal repository requires authentication, the `id` element can be used in your [settings](../../settings.html#Servers) file to specify login information.
+
+
### Deploying to the Internal Repository
+
One of the most important reasons to have one or more internal repositories is to be able to publish your own private releases.
+
To publish to the repository, you will need to have access via one of SCP, SFTP, FTP, WebDAV, or the filesystem. Connectivity is accomplished with the various [wagons](/wagon/wagon-providers/index.html). Some wagons may need to be added as [extension](/ref/current/maven-model/maven.html#class_extension) to your build.
+
<!-- For example, to set up an SCP transfer. -->
<!-- show the scp example. -->
+
diff --git a/content/markdown/guides/introduction/introduction-to-the-lifecycle.md b/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
index 7c3fdbdd..8d2dbbf7 100644
--- a/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
+++ b/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
@@ -23,117 +23,166 @@ under the License.
## Introduction to the Build Lifecycle
+
### Table Of Contents
-- [Build Lifecycle Basics](#build-lifecycle-basics)
-- [Setting Up Your Project to Use the Build Lifecycle](#setting-up-your-project-to-use-the-build-lifecycle)
- - [Packaging](#packaging)
+ - [Build Lifecycle Basics](#build-lifecycle-basics)
+
+ - [Setting Up Your Project to Use the Build Lifecycle](#setting-up-your-project-to-use-the-build-lifecycle)
+
+ - [Packaging](#packaging)
+
+ - [Plugins](#plugins)
+
+ - [Lifecycle Reference](#lifecycle-reference)
- - [Plugins](#plugins)
+ - [Built-in Lifecycle Bindings](#built-in-lifecycle-bindings)
-- [Lifecycle Reference](#lifecycle-reference)
-- [Built-in Lifecycle Bindings](#built-in-lifecycle-bindings)
### Build Lifecycle Basics
+
Maven is based around the central concept of a build lifecycle. What this means is that the process for building and distributing a particular artifact (project) is clearly defined.
+
For the person building a project, this means that it is only necessary to learn a small set of commands to build any Maven project, and the [POM](./introduction-to-the-pom.html) will ensure they get the results they desired.
+
There are three built-in build lifecycles: default, clean and site. The `default` lifecycle handles your project deployment, the `clean` lifecycle handles project cleaning, while the `site` lifecycle handles the creation of your project's web site.
+
#### A Build Lifecycle is Made Up of Phases
+
Each of these build lifecycles is defined by a different list of build phases, wherein a build phase represents a stage in the lifecycle.
+
For example, the default lifecycle comprises of the following phases (for a complete list of the lifecycle phases, refer to the [Lifecycle Reference](Lifecycle_Reference)):
-- `validate` - validate the project is correct and all necessary information is available
-- `compile` - compile the source code of the project
-- `test` - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
+ - `validate` - validate the project is correct and all necessary information is available
+
+ - `compile` - compile the source code of the project
+
+ - `test` - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
+
+ - `package` - take the compiled code and package it in its distributable format, such as a JAR.
-- `package` - take the compiled code and package it in its distributable format, such as a JAR.
+ - `verify` - run any checks on results of integration tests to ensure quality criteria are met
-- `verify` - run any checks on results of integration tests to ensure quality criteria are met
+ - `install` - install the package into the local repository, for use as a dependency in other projects locally
-- `install` - install the package into the local repository, for use as a dependency in other projects locally
+ - `deploy` - done in the build environment, copies the final package to the remote repository for sharing with other developers and projects.
-- `deploy` - done in the build environment, copies the final package to the remote repository for sharing with other developers and projects.
These lifecycle phases (plus the other lifecycle phases not shown here) are executed sequentially to complete the `default` lifecycle. Given the lifecycle phases above, this means that when the default lifecycle is used, Maven will first validate the project, then will try to compile the sources, run those against the tests, package the binaries (e.g. jar), run integration tests against that package, verify the integration tests, install the verified package to the local repository, the [...]
+
_[\[top\]](./introduction-to-the-lifecycle.html)._
+
+
#### Usual Command Line Calls
+
You should select the phase that matches your outcome. If you want your jar, run `package`. If you want to run the unit tests, run `test`.
+
If you are uncertain what you want, the preferred phase to call is
+
+
```
mvn verify
```
This command executes each default lifecycle phase in order (`validate`, `compile`, `package`, etc.), before executing `verify`. You only need to call the last build phase to be executed, in this case, `verify`. In most cases the effect is the same as `package`. However, in case there are integration-tests, these will be executed as well. And during the `verify` phase some additional checks can be done, e.g. if your code written according to the predefined checkstyle rules.
+
In a build environment, use the following call to cleanly build and deploy artifacts into the shared repository.
+
+
```
mvn clean deploy
```
The same command can be used in a multi-module scenario (i.e. a project with one or more subprojects). Maven traverses into every subproject and executes `clean`, then executes `deploy` (including all of the prior build phase steps).
+
_[\[top\]](./introduction-to-the-lifecycle.html)._
+
+
#### A Build Phase is Made Up of Plugin Goals
+
However, even though a build phase is responsible for a specific step in the build lifecycle, the manner in which it carries out those responsibilities may vary. And this is done by declaring the plugin goals bound to those build phases.
+
A plugin goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation. The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked. For example, consider the command below. The `clean` and `package` arguments are build phases, while the `de [...]
+
+
```
mvn clean dependency:copy-dependencies package
```
If this were to be executed, the `clean` phase will be executed first (meaning it will run all preceding phases of the clean lifecycle, plus the `clean` phase itself), and then the `dependency:copy-dependencies` goal, before finally executing the `package` phase (and all its preceding build phases of the default lifecycle).
+
Moreover, if a goal is bound to one or more build phases, that goal will be called in all those phases.
+
Furthermore, a build phase can also have zero or more goals bound to it. If a build phase has no goals bound to it, that build phase will not execute. But if it has one or more goals bound to it, it will execute all those goals.
+
<!-- ~ -->
<!-- ~ Check if the following is true for Maven 3... -->
(_Note: In Maven 2.0.5 and above, multiple goals bound to a phase are executed in the same order as they are declared in the POM, however multiple instances of the same plugin are not supported. Multiple instances of the same plugin are grouped to execute together and ordered in Maven 2.0.11 and above_).
+
<!-- ~ -->
_[\[top\]](./introduction-to-the-lifecycle.html)._
+
+
#### Some Phases Are Not Usually Called From the Command Line
+
The phases named with hyphenated-words (`pre-\*`, `post-\*`, or `process-\*`) are not usually directly called from the command line. These phases sequence the build, producing intermediate results that are not useful outside the build. In the case of invoking `integration-test`, the environment may be left in a hanging state.
+
Code coverage tools such as Jacoco and execution container plugins such as Tomcat, Cargo, and Docker bind goals to the `pre-integration-test` phase to prepare the integration test container environment. These plugins also bind goals to the `post-integration-test` phase to collect coverage statistics or decommission the integration test container.
+
Failsafe and code coverage plugins bind goals to `integration-test` and `verify` phases. The net result is test and coverage reports are available after the `verify` phase. If `integration-test` were to be called from the command line, no reports are generated. Worse is that the integration test container environment is left in a hanging state; the Tomcat webserver or Docker instance is left running, and Maven may not even terminate by itself.
+
_[\[top\]](./introduction-to-the-lifecycle.html)._
+
+
+
### Setting Up Your Project to Use the Build Lifecycle
+
The build lifecycle is simple enough to use, but when you are constructing a Maven build for a project, how do you go about assigning tasks to each of those build phases?
+
#### Packaging
+
The first, and most common way, is to set the packaging for your project via the equally named POM element `<packaging>`. Some of the valid packaging values are `jar`, `war`, `ear` and `pom`. If no packaging value has been specified, it will default to `jar`.
+
Each packaging contains a list of goals to bind to a particular phase. For example, the `jar` packaging will bind the following goals to build phases of the default lifecycle.
+
|Phase|plugin:goal|
|---|---|
|`process-resources`|`resources:resources`|
@@ -147,20 +196,30 @@ mvn clean dependency:copy-dependencies package
This is an almost [standard set of bindings](/ref/current/maven-core/default-bindings.html); however, some packagings handle them differently. For example, a project that is purely metadata (packaging value is `pom`) only binds goals to the `install` and `deploy` phases (for a complete list of goal-to-build-phase bindings of some of the packaging types, refer to the [Lifecycle Reference](Lifecycle_Reference)).
+
Note that for some packaging types to be available, you may also need to include a particular plugin in the `<build>` section of your POM and specify `<extensions>true</extensions>` for that plugin. One example of a plugin that requires this is the Plexus plugin, which provides a `plexus-application` and `plexus-service` packaging.
+
_[\[top\]](./introduction-to-the-lifecycle.html)._
+
+
#### Plugins
+
The second way to add goals to phases is to configure plugins in your project. Plugins are artifacts that provide goals to Maven. Furthermore, a plugin may have one or more goals wherein each goal represents a capability of that plugin. For example, the Compiler plugin has two goals: `compile` and `testCompile`. The former compiles the source code of your main code, while the latter compiles the source code of your test code.
+
As you will see in the later sections, plugins can contain information that indicates which lifecycle phase to bind a goal to. Note that adding the plugin on its own is not enough information - you must also specify the goals you want to run as part of your build.
+
The goals that are configured will be added to the goals already bound to the lifecycle from the packaging selected. If more than one goal is bound to a particular phase, the order used is that those from the packaging are executed first, followed by those configured in the POM. Note that you can use the `<executions>` element to gain more control over the order of particular goals.
+
For example, the Modello plugin binds by default its goal `modello:java` to the `generate-sources` phase (Note: The `modello:java` goal generates Java source codes). So to use the Modello plugin and have it generate sources from a model and incorporate that into the build, you would add the following to your POM in the `<plugins>` section of `<build>`:
+
+
```
<plugin>
<groupId>org.codehaus.modello</groupId>
@@ -184,10 +243,14 @@ mvn clean dependency:copy-dependencies package
You might be wondering why that `<executions>` element is there. That is so that you can run the same goal multiple times with different configuration if needed. Separate executions can also be given an ID so that during inheritance or the application of profiles you can control whether goal configuration is merged or turned into an additional execution.
+
When multiple executions are given that match a particular phase, they are executed in the order specified in the POM, with inherited executions running first.
+
Now, in the case of `modello:java`, it only makes sense in the `generate-sources` phase. But some goals can be used in more than one phase, and there may not be a sensible default. For those, you can specify the phase yourself. For example, let's say you have a goal `display:time` that echos the current time to the commandline, and you want it to run in the `process-test-resources` phase to indicate when the tests were started. This would be configured like so:
+
+
```
<plugin>
<groupId>com.mycompany.example</groupId>
@@ -206,20 +269,28 @@ mvn clean dependency:copy-dependencies package
_[\[top\]](./introduction-to-the-lifecycle.html)._
+
+
+
### Lifecycle Reference
+
The following lists all build phases of the `default`, `clean` and `site` lifecycles, which are executed in the order given up to the point of the one specified.
+
#### Clean Lifecycle
+
|Phase|Description|
|---|---|
|`pre-clean`|execute processes needed prior to the actual project cleaning|
|`clean`|remove all files generated by the previous build|
|`post-clean`|execute processes needed to finalize the project cleaning|
+
#### Default Lifecycle
+
|Phase|Description|
|---|---|
|`validate`|validate the project is correct and all necessary information is available.|
@@ -246,8 +317,10 @@ mvn clean dependency:copy-dependencies package
|`install`|install the package into the local repository, for use as a dependency in other projects locally.|
|`deploy`|done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.|
+
#### Site Lifecycle
+
|Phase|Description|
|---|---|
|`pre-site`|execute processes needed prior to the actual project site generation|
@@ -257,18 +330,26 @@ mvn clean dependency:copy-dependencies package
_[\[top\]](./introduction-to-the-lifecycle.html)._
+
+
+
### Built-in Lifecycle Bindings
+
Some phases have goals bound to them by default. And for the default lifecycle, these bindings depend on the packaging value. Here are some of the goal-to-build-phase bindings.
+
#### Clean Lifecycle Bindings
+
|Phase|plugin:goal|
|---|---|
|`clean`|`clean:clean`|
+
#### Default Lifecycle Bindings - Packaging `ejb` / `ejb3` / `jar` / `par` / `rar` / `war`
+
|Phase|plugin:goal|
|---|---|
|`process-resources`|`resources:resources`|
@@ -280,8 +361,10 @@ mvn clean dependency:copy-dependencies package
|`install`|`install:install`|
|`deploy`|`deploy:deploy`|
+
#### Default Lifecycle Bindings - Packaging `ear`
+
|Phase|plugin:goal|
|---|---|
|`generate-resources`|`ear:generate-application-xml`|
@@ -290,8 +373,10 @@ mvn clean dependency:copy-dependencies package
|`install`|`install:install`|
|`deploy`|`deploy:deploy`|
+
#### Default Lifecycle Bindings - Packaging `maven-plugin`
+
|Phase|plugin:goal|
|---|---|
|`generate-resources`|`plugin:descriptor`|
@@ -304,27 +389,40 @@ mvn clean dependency:copy-dependencies package
|`install`|`install:install`|
|`deploy`|`deploy:deploy`|
+
#### Default Lifecycle Bindings - Packaging `pom`
+
|Phase|plugin:goal|
|---|---|
|`package`||
|`install`|`install:install`|
|`deploy`|`deploy:deploy`|
+
#### Site Lifecycle Bindings
+
|Phase|plugin:goal|
|---|---|
|`site`|`site:site`|
|`site-deploy`|`site:deploy`|
+
#### References
+
The full Maven lifecycle is defined by the `components.xml` file in the `maven-core` module, with [associated documentation](/ref/current/maven-core/lifecycles.html) for reference.
+
Default lifecycle bindings are defined in a separate `[default-bindings.xml](https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml)` descriptor.
+
See [Lifecycles Reference](/ref/current/maven-core/lifecycles.html) and [Plugin Bindings for default Lifecycle Reference](/ref/current/maven-core/default-bindings.html) for latest documentation taken directly from source code.
+
_[\[top\]](./introduction-to-the-lifecycle.html)._
+
+
+
+
diff --git a/content/markdown/guides/introduction/introduction-to-the-pom.md b/content/markdown/guides/introduction/introduction-to-the-pom.md
index 1d930325..9f6b3909 100644
--- a/content/markdown/guides/introduction/introduction-to-the-pom.md
+++ b/content/markdown/guides/introduction/introduction-to-the-pom.md
@@ -25,64 +25,91 @@ under the License.
## Introduction to the POM
-- [What is a POM](./introduction-to-the-pom.html#what-is-a-pom)?
-- [Super POM](./introduction-to-the-pom.html#super-pom)
-- [Minimal POM](./introduction-to-the-pom.html#minimal-pom)
+ - [What is a POM](./introduction-to-the-pom.html#what-is-a-pom)?
-- [Project Inheritance](./introduction-to-the-pom.html#project-inheritance)
+ - [Super POM](./introduction-to-the-pom.html#super-pom)
-- [Example 1](./introduction-to-the-pom.html#example-1)
+ - [Minimal POM](./introduction-to-the-pom.html#minimal-pom)
-- [Example 2](./introduction-to-the-pom.html#example-2)
+ - [Project Inheritance](./introduction-to-the-pom.html#project-inheritance)
-- [Project Aggregation](./introduction-to-the-pom.html#project-aggregation)
+ - [Example 1](./introduction-to-the-pom.html#example-1)
-- [Example 3](./introduction-to-the-pom.html#example-3)
+ - [Example 2](./introduction-to-the-pom.html#example-2)
-- [Example 4](./introduction-to-the-pom.html#example-4)
-- [Project Inheritance vs Project Aggregation](./introduction-to-the-pom.html#project-inheritance-vs-project-aggregation)
-- [Example 5](./introduction-to-the-pom.html#example-5)
+ - [Project Aggregation](./introduction-to-the-pom.html#project-aggregation)
+
+ - [Example 3](./introduction-to-the-pom.html#example-3)
+
+ - [Example 4](./introduction-to-the-pom.html#example-4)
+
+
+
+ - [Project Inheritance vs Project Aggregation](./introduction-to-the-pom.html#project-inheritance-vs-project-aggregation)
+
+ - [Example 5](./introduction-to-the-pom.html#example-5)
+
+
+
+ - [Project Interpolation and Variables](./introduction-to-the-pom.html#project-nterpolation)
+
+ - [Available Variables](./introduction-to-the-pom.html#available-variables)
+
-- [Project Interpolation and Variables](./introduction-to-the-pom.html#project-nterpolation)
-- [Available Variables](./introduction-to-the-pom.html#available-variables)
### What is a POM?
+
A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects. Examples for this is the build directory, which is `target`; the source directory, which is `src/main/java`; the test source directory, which is `src/test/java`; and so on. When executing a task or goal, Maven looks for the POM in the current direct [...]
+
Some of the configuration that can be specified in the POM are the project dependencies, the plugins or goals that can be executed, the build profiles, and so on. Other information such as the project version, description, developers, mailing lists and such can also be specified.
+
[\[top\]](./introduction-to-the-pom.html)
+
+
### Super POM
+
The Super POM is Maven's default POM. All POMs extend the Super POM unless explicitly set, meaning the configuration specified in the Super POM is inherited by the POMs you created for your projects.
+
You can see the [Super POM for Maven 3.6.3](/ref/3.6.3/maven-model-builder/super-pom.html) in Maven Core reference documentation.
+
[\[top\]](./introduction-to-the-pom.html)
+
+
### Minimal POM
+
The minimum requirement for a POM are the following:
-- `project` root
-- `modelVersion` - should be set to 4.0.0
-- `groupId` - the id of the project's group.
+ - `project` root
+
+ - `modelVersion` - should be set to 4.0.0
+
+ - `groupId` - the id of the project's group.
+
+ - `artifactId` - the id of the artifact (project)
-- `artifactId` - the id of the artifact (project)
+ - `version` - the version of the artifact under the specified group
-- `version` - the version of the artifact under the specified group
Here's an example:
+
+
```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -95,36 +122,50 @@ under the License.
A POM requires that its groupId, artifactId, and version be configured. These three values form the project's fully qualified artifact name. This is in the form of `<groupId>:<artifactId>:<version>`. As for the example above, its fully qualified artifact name is "com.mycompany.app:my-app:1".
+
Also, as mentioned in the [first section](#hat-is-a-pom), if the configuration details are not specified, Maven will use their defaults. One of these default values is the packaging type. Every Maven project has a packaging type. If it is not specified in the POM, then the default value "jar" would be used.
+
Furthermore, you can see that in the minimal POM the _repositories_ were not specified. If you build your project using the minimal POM, it would inherit the _repositories_ configuration in the Super POM. Therefore when Maven sees the dependencies in the minimal POM, it would know that these dependencies will be downloaded from `https://repo.maven.apache.org/maven2` which was specified in the Super POM.
+
[\[top\]](./introduction-to-the-pom.html)
+
+
### Project Inheritance
+
Elements in the POM that are merged are the following:
-- dependencies
... 8032 lines suppressed ...
[maven-site] 09/14: Revert "Maven Reporting Impl 4.0.0-M4 released"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit 7bafdd429b5da874e49e7595521de8ce96ef0e6d
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:33:56 2023 +0100
Revert "Maven Reporting Impl 4.0.0-M4 released"
This reverts commit f8021b4597288afb26547f0ab74228d2b4d02f9d.
---
content/markdown/shared/index.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/markdown/shared/index.md b/content/markdown/shared/index.md
index 464eb023..5bf568ba 100644
--- a/content/markdown/shared/index.md
+++ b/content/markdown/shared/index.md
@@ -41,7 +41,7 @@ under the License.
|[ `maven-mapping`](/shared/maven-mapping/)|3.0.0|2015-11-19|A shared component for all plugins that need to do mapping.|[Git](https://gitbox.apache.org/repos/asf/maven-mapping.git) / [GitHub](https://github.com/apache/maven-mapping/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-mapping)|
|[ `maven-reporting-api`](/shared/maven-reporting-api/)|4.0.0-M4|2023-01-21|API to manage report generation.|[Git](https://gitbox.apache.org/repos/asf/maven-reporting-api.git) / [GitHub](https://github.com/apache/maven-reporting-api/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-reporting-api)|
|[ `maven-reporting-exec`](/shared/maven-reporting-exec/)|2.0.0-M4|2023-01-31|API to manage report plugins preparation with Maven 3.|[Git](https://gitbox.apache.org/repos/asf/maven-reporting-exec.git) / [GitHub](https://github.com/apache/maven-reporting-exec/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-reporting-exec)|
-|[ `maven-reporting-impl`](/shared/maven-reporting-impl/)|4.0.0-M4|2023-02-11|Abstract classes to manage report generation.|[Git](https://gitbox.apache.org/repos/asf/maven-reporting-impl.git) / [GitHub](https://github.com/apache/maven-reporting-impl/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-reporting-impl)|
+|[ `maven-reporting-impl`](/shared/maven-reporting-impl/)|4.0.0-M3|2022-11-29|Abstract classes to manage report generation.|[Git](https://gitbox.apache.org/repos/asf/maven-reporting-impl.git) / [GitHub](https://github.com/apache/maven-reporting-impl/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-reporting-impl)|
|[ `maven-script-interpreter`](/shared/maven-script-interpreter/)|1.4|2022-12-20|Utilities to interpret/execute some scripts for various implementations: groovy or beanshell.|[Git](https://gitbox.apache.org/repos/asf/maven-script-interpreter.git) / [GitHub](https://github.com/apache/maven-script-interpreter/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-script-interpreter)|
|[ `maven-shared-incremental`](/shared/maven-shared-incremental/)|1.1|2013-04-08|Various utility classes and plexus components for supporting incremental build functionality in Maven plugins.|[Git](https://gitbox.apache.org/repos/asf/maven-shared-incremental.git) / [GitHub](https://github.com/apache/maven-shared-incremental/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-shared-incremental)|
|[ `maven-shared-jar`](/shared/maven-shared-jar/)|1.2|2015-12-31|Utilities which help identify the contents of a JAR, including Java class analysis and Maven metadata analysis.|[Git](https://gitbox.apache.org/repos/asf/maven-shared-jar.git) / [GitHub](https://github.com/apache/maven-shared-jar/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-shared-jar)|
[maven-site] 01/14: Revert "(doc) added snippet types"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit f3f37282fb6b55c18a5639505a0a6bf9e81a2be9
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:31:10 2023 +0100
Revert "(doc) added snippet types"
This reverts commit d7db85d39f794e361af3736a613515d32aeba551.
---
content/markdown/developers/committer-settings.md | 4 +--
content/markdown/developers/conventions/code.md | 8 ++---
content/markdown/developers/conventions/git.md | 4 +--
content/markdown/docs/3.2.2/release-notes.md | 4 +--
content/markdown/docs/3.3.1/release-notes.md | 6 ++--
content/markdown/docs/3.6.1/release-notes.md | 2 +-
.../examples/injecting-properties-via-settings.md | 4 +--
.../development/guide-documentation-style.md | 2 +-
.../development/guide-plugin-documentation.md | 24 ++++++-------
.../guide-testing-development-plugins.md | 6 ++--
.../guides/development/guide-testing-releases.md | 6 ++--
content/markdown/guides/getting-started/index.md | 34 +++++++++---------
.../getting-started/maven-in-five-minutes.md | 4 +--
.../introduction-to-dependency-mechanism.md | 34 +++++++++---------
...uction-to-optional-and-excludes-dependencies.md | 10 +++---
.../introduction-to-plugin-prefix-mapping.md | 4 +--
.../introduction/introduction-to-profiles.md | 32 ++++++++---------
.../introduction/introduction-to-repositories.md | 2 +-
.../introduction/introduction-to-the-lifecycle.md | 4 +--
.../guides/introduction/introduction-to-the-pom.md | 32 ++++++++---------
.../guides/mini/guide-archive-configuration.md | 2 +-
content/markdown/guides/mini/guide-assemblies.md | 8 ++---
.../markdown/guides/mini/guide-attached-tests.md | 4 +--
.../guide-building-for-different-environments.md | 2 +-
.../guides/mini/guide-configuring-maven.md | 4 +--
.../guides/mini/guide-configuring-plugins.md | 42 +++++++++++-----------
.../guides/mini/guide-creating-archetypes.md | 8 ++---
.../guides/mini/guide-default-execution-ids.md | 6 ++--
.../mini/guide-deployment-security-settings.md | 2 +-
content/markdown/guides/mini/guide-encryption.md | 10 +++---
.../guides/mini/guide-generating-sources.md | 2 +-
.../markdown/guides/mini/guide-http-settings.md | 24 ++++++-------
.../guide-large-scale-centralized-deployments.md | 4 +--
.../guides/mini/guide-maven-classloading.md | 2 +-
.../markdown/guides/mini/guide-mirror-settings.md | 6 ++--
.../guides/mini/guide-multiple-repositories.md | 4 +--
content/markdown/guides/mini/guide-proxies.md | 2 +-
content/markdown/guides/mini/guide-releasing.md | 6 ++--
content/markdown/guides/mini/guide-relocation.md | 2 +-
.../markdown/guides/mini/guide-repository-ssl.md | 4 +--
.../guides/mini/guide-reproducible-builds.md | 2 +-
content/markdown/guides/mini/guide-site.md | 10 +++---
.../markdown/guides/mini/guide-snippet-macro.md | 4 +--
content/markdown/guides/mini/guide-using-ant.md | 4 +--
.../markdown/guides/mini/guide-using-extensions.md | 4 +--
.../markdown/guides/mini/guide-wagon-providers.md | 4 +--
.../guides/plugin/guide-java-plugin-development.md | 16 ++++-----
.../plugin/guide-java-report-plugin-development.md | 14 ++++----
content/markdown/plugin-developers/common-bugs.md | 24 ++++++-------
.../cookbook/plexus-plugin-upgrade.md | 10 +++---
.../markdown/plugin-developers/plugin-testing.md | 6 ++--
content/markdown/plugins/localization.md | 2 +-
content/markdown/repository/central-index.md | 2 +-
.../repository/guide-central-repository-upload.md | 2 +-
content/markdown/skins/index.md | 2 +-
55 files changed, 238 insertions(+), 238 deletions(-)
diff --git a/content/markdown/developers/committer-settings.md b/content/markdown/developers/committer-settings.md
index 417a8adc..54d00842 100644
--- a/content/markdown/developers/committer-settings.md
+++ b/content/markdown/developers/committer-settings.md
@@ -31,7 +31,7 @@ under the License.
**It is highly recommended to use Maven's [password encryption capabilities](../guides/mini/guide-encryption.html) for your passwords**.
-```xml
+```
<settings>
...
<servers>
@@ -56,7 +56,7 @@ under the License.
To be able to send out announcements of Maven releases you need to add a couple of properties to the `apache-release` profile.
-```xml
+```
<settings>
...
<profiles>
diff --git a/content/markdown/developers/conventions/code.md b/content/markdown/developers/conventions/code.md
index d00ce056..3f96f8a9 100644
--- a/content/markdown/developers/conventions/code.md
+++ b/content/markdown/developers/conventions/code.md
@@ -120,7 +120,7 @@ under the License.
- **Line Breaks**: Always use a new line with indentation for complex XML types and no line break for simple XML types. Always use a new line to separate XML sections or blocks, for instance:
-```xml
+```
<aTag>
<simpleType>This is a simple type</simpleType>
@@ -132,13 +132,13 @@ under the License.
In some cases, adding comments could improve the readability of blocks, for instance:
-```xml
+```
<!-- Simple XML documentation -->
```
or
-```xml
+```
<!-- ====================================================================== -->
<!-- Block documentation -->
<!-- ====================================================================== -->
@@ -154,7 +154,7 @@ under the License.
The following is the recommended ordering for all Maven POM files:
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion/>
diff --git a/content/markdown/developers/conventions/git.md b/content/markdown/developers/conventions/git.md
index de3b0191..ef568786 100644
--- a/content/markdown/developers/conventions/git.md
+++ b/content/markdown/developers/conventions/git.md
@@ -101,7 +101,7 @@ git commit --amend -m "new comment"
Workflow for svn folks is something like :
-```bash
+```
$ git pull
$ hack hack hack
$ git push
@@ -113,7 +113,7 @@ git commit --amend -m "new comment"
A more quiet workflow :
-```bash
+```
$ git pull
$ hack hack hack
$ git push
diff --git a/content/markdown/docs/3.2.2/release-notes.md b/content/markdown/docs/3.2.2/release-notes.md
index 347381bd..d5814845 100644
--- a/content/markdown/docs/3.2.2/release-notes.md
+++ b/content/markdown/docs/3.2.2/release-notes.md
@@ -47,7 +47,7 @@ The full list of changes can be found in our [issue management system][4].
Parent elements can now use bounded ranges in the version specification. You can now consistently use ranges for all intra-project dependencies, of which parents are a special case but still considered a dependency of projects that inherit from them. The following is now permissible:
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
@@ -77,7 +77,7 @@ This feature helps support the pattern where many streams of development are set
Now when you use create plugins that strictly use annotation processing to generate the descriptor, you can avoid the confusing configuration previously required. This is what you typically needed to include in order to run the descriptor generator on compiled classes and avoid errors.
-```xml
+```
<pluginManagement>
<plugins>
<plugin>
diff --git a/content/markdown/docs/3.3.1/release-notes.md b/content/markdown/docs/3.3.1/release-notes.md
index e1dd1324..918c407b 100644
--- a/content/markdown/docs/3.3.1/release-notes.md
+++ b/content/markdown/docs/3.3.1/release-notes.md
@@ -86,7 +86,7 @@ The new [Maven 3.3.1 Release is just out](http://mail-archives.apache.org/mod_mb
you can define an `${maven.projectBasedir}/.mvn/extensions.xml` file which looks
like the following:
-```xml
+``` xml
<extensions xmlns="http://maven.apache.org/EXTENSIONS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0 http://maven.apache.org/xsd/core-extensions-1.0.0.xsd">
<extension>
@@ -161,7 +161,7 @@ mvn exec:java
The configuration which is used here can be defined in your pom by using an execution id `default-cli`.
-```xml
+```
<project...>
<build>
@@ -187,7 +187,7 @@ The configuration which is used here can be defined in your pom by using an exec
Starting with this Maven release you can now define several configuration for different
executions on command like the following:
-```xml
+```
<project...>
<build>
diff --git a/content/markdown/docs/3.6.1/release-notes.md b/content/markdown/docs/3.6.1/release-notes.md
index ab9ccf2a..f7bce3be 100644
--- a/content/markdown/docs/3.6.1/release-notes.md
+++ b/content/markdown/docs/3.6.1/release-notes.md
@@ -164,7 +164,7 @@ mvn -ntp ... ....
URL's etc. within `project`, `distributionManagement` and `scm` part in the pom for multi module
builds like this:
-```xml
+```
<project child.project.url.inherit.append.path="false">
<url>...</url>
diff --git a/content/markdown/examples/injecting-properties-via-settings.md b/content/markdown/examples/injecting-properties-via-settings.md
index 5a96daac..51aef3de 100644
--- a/content/markdown/examples/injecting-properties-via-settings.md
+++ b/content/markdown/examples/injecting-properties-via-settings.md
@@ -28,7 +28,7 @@ under the License.
### Plugin Configuration
-```xml
+```
<project>
[...]
<build>
@@ -47,7 +47,7 @@ under the License.
### `settings.xml`
-```xml
+```
<settings>
[...]
<profiles>
diff --git a/content/markdown/guides/development/guide-documentation-style.md b/content/markdown/guides/development/guide-documentation-style.md
index dc66732a..62813733 100644
--- a/content/markdown/guides/development/guide-documentation-style.md
+++ b/content/markdown/guides/development/guide-documentation-style.md
@@ -73,7 +73,7 @@ under the License.
The following is an example of how the distribution management of the Maven site is configured.
-```xml
+```
<project>
...
<distributionManagement>
diff --git a/content/markdown/guides/development/guide-plugin-documentation.md b/content/markdown/guides/development/guide-plugin-documentation.md
index af884a96..8c3d1e7a 100644
--- a/content/markdown/guides/development/guide-plugin-documentation.md
+++ b/content/markdown/guides/development/guide-plugin-documentation.md
@@ -74,7 +74,7 @@ mvn site
- `<issueManagement>` - describes the system used for reporting problems and modification requests
-```xml
+```
<project>
[...]
<issueManagement>
@@ -89,7 +89,7 @@ mvn site
- `<mailingLists>` - lists where other users or the developers can be contacted for help and discussions
-```xml
+```
<project>
[...]
<mailingLists>
@@ -110,7 +110,7 @@ mvn site
- `<licenses>` - plugin license
-```xml
+```
<project>
[...]
<licenses>
@@ -126,7 +126,7 @@ mvn site
- `<scm>` - the source code management configuration - a plugin without this would raise suspicion, might not be OSS
-```xml
+```
<project>
[...]
<scm>
@@ -140,7 +140,7 @@ mvn site
- `<organization>` - the organization maintaining the plugin, just in case we need someone to blame
-```xml
+```
<project>
[...]
<organization>
@@ -155,7 +155,7 @@ mvn site
The Maven Plugin Plugin is responsible for generating the Plugin Info site and needs to be added to the `<reporting>` section unless it is already inherited from a parent POM:
-```xml
+```
<project>
[...]
<reporting>
@@ -175,7 +175,7 @@ mvn site
- all `@parameter` fields should have a descriptive comment, informative enough that even a regular user can understand
-```java
+```
[...]
/**
* Put something informative here that a regular user can understand.
@@ -188,7 +188,7 @@ mvn site
- class level comment should explain what the goal does
-```java
+```
[...]
/**
* Everything here will show up on the top of the generated plugin info page.
@@ -215,7 +215,7 @@ public class ExampleMojo
The site descriptor describes the navigation links and can be found in `src/site/site.xml`. Below is the suggested site descriptor template.
-```xml
+```
<?xml version="1.0" encoding="UTF-8"?>
<project>
<body>
@@ -303,7 +303,7 @@ Plugin Name
A well documented project always collates frequently asked questions which are usually located in `src/site/fml/faq.fml`. The example below provides a template for your FAQ:
-```xml
+```
<?xml version="1.0" encoding="UTF-8"?>
<faqs id="FAQ" title="Frequently Asked Questions">
<part id="General">
@@ -339,7 +339,7 @@ Plugin Name
To enable javadoc for your plugin add the following to your `pom.xml`
-```xml
+```
<project>
[...]
<build>
@@ -372,7 +372,7 @@ Plugin Name
To enable source code cross-references add the following to your `pom.xml`
-```xml
+```
<project>
[...]
<build>
diff --git a/content/markdown/guides/development/guide-testing-development-plugins.md b/content/markdown/guides/development/guide-testing-development-plugins.md
index 4636d43b..3ec34daf 100644
--- a/content/markdown/guides/development/guide-testing-development-plugins.md
+++ b/content/markdown/guides/development/guide-testing-development-plugins.md
@@ -40,7 +40,7 @@ under the License.
The first step is to include this in your project:
-```xml
+```
<project>
...
<pluginRepositories>
@@ -61,7 +61,7 @@ under the License.
- You can have Maven automatically check for updates on a given interval, for example:
-```xml
+```
<project>
...
<pluginRepositories>
@@ -84,7 +84,7 @@ under the License.
You need to modify your `${user.home}/.m2/settings.xml` file to include two new profiles and then when you need access to the plugin snapshots use `-Papache`. The profile only needs to be enabled once so that the plugins can be downloaded into you local repository. Once in your local repository Maven can successfully resolve the dependencies and the profile no longer needs to be activated.
-```xml
+```
<settings>
...
<profiles>
diff --git a/content/markdown/guides/development/guide-testing-releases.md b/content/markdown/guides/development/guide-testing-releases.md
index 0d700cd7..8273de10 100644
--- a/content/markdown/guides/development/guide-testing-releases.md
+++ b/content/markdown/guides/development/guide-testing-releases.md
@@ -38,7 +38,7 @@ under the License.
The repository configuration for testing a plugin will typically look something like this (it will be provided in the vote email):
-```xml
+```
...
<pluginRepositories>
<pluginRepository>
@@ -93,7 +93,7 @@ under the License.
If you are using the repository mirroring technique to lock down to the repository manager in your environment, you would add an additional mirror to correspond to the additional repository in the POM, such as:
-```xml
+```
...
<mirror>
<id>staged-releases-mirror</id>
@@ -107,7 +107,7 @@ under the License.
If you regularly test staged releases and want to have a more convenient way to add the repository to a build without modifying your POM, you may add a profile to your `\~/.m2/settings.xml`:
-```xml
+```
...
<profiles>
<profile>
diff --git a/content/markdown/guides/getting-started/index.md b/content/markdown/guides/getting-started/index.md
index b877af8b..fb0c5d20 100644
--- a/content/markdown/guides/getting-started/index.md
+++ b/content/markdown/guides/getting-started/index.md
@@ -102,7 +102,7 @@ mvn -B archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -Darch
Once you have executed this command, you will notice a few things have happened. First, you will notice that a directory named `my-app` has been created for the new project, and this directory contains a file named `pom.xml` that should look like this:
-```xml
+```
<project 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/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
@@ -394,7 +394,7 @@ mvn clean
Notice the value of the **version** tag in the `pom.xml` file shown below has the suffix: `-SNAPSHOT`.
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0"
...
<groupId>...</groupId>
@@ -417,7 +417,7 @@ mvn clean
For this example, we will configure the Java compiler to allow JDK 5.0 sources. This is as simple as adding this to your POM:
-```xml
+```
...
<build>
<plugins>
@@ -522,7 +522,7 @@ my-app
In a unit test you could use a simple snippet of code like the following to access the resource required for testing:
-```java
+```
...
// Retrieve resource
@@ -539,7 +539,7 @@ InputStream is = getClass().getResourceAsStream( "/test.properties" );
To have Maven filter resources when copying, simply set `filtering` to true for the resource directory in your `pom.xml`:
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
@@ -607,7 +607,7 @@ my.filter.value=hello!
Next, we'll add a reference to this new file in the `pom.xml`:
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
@@ -654,7 +654,7 @@ message=${my.filter.value}
the next execution of the `mvn process-resources` command will put our new property value into `application.properties`. As an alternative to defining the my.filter.value property in an external file, you could also have defined it in the `properties` section of your `pom.xml` and you'd get the same effect (notice I don't need the references to `src/main/filters/filter.properties` either):
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
@@ -711,7 +711,7 @@ mvn process-resources "-Dcommand.line.prop=hello again"
The `dependencies` section of the pom.xml lists all of the external dependencies that our project needs in order to build (whether it needs that dependency at compile time, test time, run time, or whatever). Right now, our project is depending on JUnit only (I took out all of the resource filtering stuff for clarity):
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
@@ -742,7 +742,7 @@ mvn process-resources "-Dcommand.line.prop=hello again"
With this information about a dependency, Maven will be able to reference the dependency when it builds the project. Where does Maven reference the dependency from? Maven looks in your local repository (`${user.home}/.m2/repository` is the default location) to find all dependencies. In a [previous section](#how-do-i-create-a-jar-and-install-it-in-my-local-repository), we installed the artifact from our project (my-app-1.0-SNAPSHOT.jar) into the local repository. Once it's installed ther [...]
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<groupId>com.mycompany.app</groupId>
@@ -764,7 +764,7 @@ mvn process-resources "-Dcommand.line.prop=hello again"
Let's add another dependency to our project. Let's say we've added some logging to the code and need to add log4j as a dependency. First, we need to know what the groupId, artifactId, and version are for log4j. The appropriate directory on Maven Central is called [/maven2/log4j/log4j](https://repo.maven.apache.org/maven2/log4j/log4j/). In that directory is a file called maven-metadata.xml. Here's what the maven-metadata.xml for log4j looks like:
-```xml
+```
<metadata>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
@@ -789,7 +789,7 @@ mvn process-resources "-Dcommand.line.prop=hello again"
Now that we know the information we need, we can add the dependency to our pom.xml:
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
@@ -829,7 +829,7 @@ mvn process-resources "-Dcommand.line.prop=hello again"
Here is an example using scp and username/password authentication:
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
@@ -882,7 +882,7 @@ mvn process-resources "-Dcommand.line.prop=hello again"
</project>
```
-```xml
+```
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
...
@@ -931,7 +931,7 @@ mvn archetype:generate \
Note that these must all be on a single line. This will create a directory called `my-webapp` containing the following project descriptor:
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
@@ -986,7 +986,7 @@ mvn package
The POM file you'll create should contain the following:
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
@@ -1005,7 +1005,7 @@ mvn package
We'll need a dependency on the JAR from the webapp, so add this to `my-webapp/pom.xml`:
-```xml
+```
...
<dependencies>
<dependency>
@@ -1019,7 +1019,7 @@ mvn package
Finally, add the following `<parent>` element to both of the other `pom.xml` files in the subdirectories:
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
diff --git a/content/markdown/guides/getting-started/maven-in-five-minutes.md b/content/markdown/guides/getting-started/maven-in-five-minutes.md
index 3a8f93d8..2e2bc8ce 100644
--- a/content/markdown/guides/getting-started/maven-in-five-minutes.md
+++ b/content/markdown/guides/getting-started/maven-in-five-minutes.md
@@ -92,7 +92,7 @@ my-app
The `pom.xml` file is the core of a project's configuration in Maven. It is a single configuration file that contains the majority of information required to build a project in just the way you want. The POM is huge and can be daunting in its complexity, but it is not necessary to understand all of the intricacies just yet to use it effectively. This project's POM is:
-```xml
+```
<project 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/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
@@ -171,7 +171,7 @@ Hello World!
In the following example, we have configured our Maven project to use version 3.8.1 of `maven-compiler-plugin` and target Java 11:
-```xml
+```
<properties>
<maven.compiler.release>11</maven.compiler.release>
</properties>
diff --git a/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md b/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
index 39b0f0f6..8d79efe5 100644
--- a/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
+++ b/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
@@ -133,7 +133,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project A:
-```xml
+```
<project>
...
@@ -163,7 +163,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project B:
-```xml
+```
<project>
...
@@ -189,7 +189,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
These two example POMs share a common dependency and each has one non-trivial dependency. This information can be put in the parent POM like this:
-```xml
+```
<project>
...
@@ -232,7 +232,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Then the two child POMs become much simpler:
-```xml
+```
<project>
...
@@ -253,7 +253,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
```
-```xml
+```
<project>
...
@@ -282,7 +282,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project A:
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
@@ -323,7 +323,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project B:
-```xml
+```
<project>
<parent>
@@ -381,7 +381,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project B:
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
@@ -429,7 +429,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project X:
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
@@ -460,7 +460,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project Y:
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
@@ -491,7 +491,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project Z:
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
@@ -533,7 +533,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
The root of the project is the BOM POM. It defines the versions of all the artifacts that will be created in the library. Other projects that wish to use the library should import this POM into the dependencyManagement section of their POM.
-```xml
+```
<project 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/maven-4.0.0.xsd">
@@ -571,7 +571,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
The parent subproject has the BOM POM as its parent. It is a normal multiproject pom.
-```xml
+```
<project 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/maven-4.0.0.xsd">
@@ -611,7 +611,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Next are the actual project POMs.
-```xml
+```
<project 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/maven-4.0.0.xsd">
@@ -659,7 +659,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
The project that follows shows how the library can now be used in another project without having to specify the dependent project's versions.
-```xml
+```
<project 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/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
@@ -709,7 +709,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
A simple example would be:
-```xml
+```
<project>
...
@@ -729,7 +729,7 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
If your artifact is provided by the JDK's `tools.jar`, the system path would be defined as follows:
-```xml
+```
<project>
...
<dependencies>
diff --git a/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md b/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md
index 93475d85..862c6aac 100644
--- a/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md
+++ b/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md
@@ -38,7 +38,7 @@ under the License.
A dependency is declared optional by setting the `<optional>` element to true in its dependency declaration:
-```xml
+```
<project>
...
@@ -86,7 +86,7 @@ Project-X -> Project-A
Add an `<exclusions>` element in the `<dependency>` element by which the problematic jar is included.
-```xml
+```
<project>
...
@@ -129,7 +129,7 @@ B, C, D, E, F
Suppose you don't want project D and its dependencies to be added to Project A's classpath because some of Project-D's dependencies are missing from the repository, and you don't need the functionality in Project-B that depends on Project-D anyway. Project-B's developers could have marked the dependency on Project-D `<optional>true</optional>`:
-```xml
+```
<dependency>
<groupId>sample.ProjectD</groupId>
<artifactId>ProjectD</artifactId>
@@ -140,7 +140,7 @@ B, C, D, E, F
Unfortunately, they didn't. As a last resort, you can exclude it on your own POM for Project-A like this:
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
@@ -204,7 +204,7 @@ Project-A
Exclusions work on the entire dependency graph below the point where they are declared. If you want to exclude Project-E instead of Project-D, simply change the exclusion to point at Project-E, but you don't move the exclusion down to Project-D. You cannot change Project-D's POM. If you could, you would use optional dependencies instead of exclusions, or split Project-D up into multiple subprojects, each with nothing but normal dependencies.
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
diff --git a/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md b/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
index 0c394da8..41e21074 100644
--- a/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
+++ b/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
@@ -38,7 +38,7 @@ under the License.
If your plugin's artifactId fits this pattern, Maven will automatically map your plugin to the correct prefix in the metadata stored within your plugin's groupId path on the repository. However, if you want to customize the prefix used to reference your plugin, you can specify the prefix directly through a configuration parameter on the `maven-plugin-plugin` in your plugin's POM:
-```xml
+```
<project>
...
<build>
@@ -82,7 +82,7 @@ mvn somePrefix:goal
As it turns out, this is simple. In the Maven settings file (per-user: `${user.home}/.m2/settings.xml`; global: `${maven.home}/conf/settings.xml`), you can provide a custom **pluginGroups** section, listing the plugin groupIds you want to search (each groupId goes in its own **pluginGroup** sub-element). For example, if my project uses a Modello model file, I might have the following in my settings:
-```xml
+```
<pluginGroups>
<pluginGroup>org.codehaus.modello</pluginGroup>
</pluginGroups>
diff --git a/content/markdown/guides/introduction/introduction-to-profiles.md b/content/markdown/guides/introduction/introduction-to-profiles.md
index ea6cc806..7b0e9d94 100644
--- a/content/markdown/guides/introduction/introduction-to-profiles.md
+++ b/content/markdown/guides/introduction/introduction-to-profiles.md
@@ -117,7 +117,7 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
Profiles can be activated in the Maven settings, via the `<activeProfiles>` section. This section takes a list of `<activeProfile>` elements, each containing a profile-id inside.
-```xml
+```
<settings>
...
<activeProfiles>
@@ -137,7 +137,7 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
The following configuration will trigger the profile when the JDK's version _starts with_ "1.4" (eg. "1.4.0_08", "1.4.2_07", "1.4"), in particular it _won't be active_ for **newer** versions like "1.8" or "11":
-```xml
+```
<profiles>
<profile>
<activation>
@@ -150,7 +150,7 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
Ranges can also be used as of Maven 2.1 (refer to the [Enforcer Version Range Syntax](/enforcer/enforcer-rules/versionRanges.html) for more information). Range values must start with either `\[` or `(` otherwise the value is interpreted as prefix. The following honours versions 1.3, 1.4 and 1.5.
-```xml
+```
<profiles>
<profile>
<activation>
@@ -167,7 +167,7 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
This next one will activate based on the detected operating system. See the [Maven Enforcer Plugin](/enforcer/enforcer-rules/requireOS.html) for more details about OS values.
-```xml
+```
<profiles>
<profile>
<activation>
@@ -187,7 +187,7 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
The profile below will be activated when the system property "debug" is specified with any value:
-```xml
+```
<profiles>
<profile>
<activation>
@@ -202,7 +202,7 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
The following profile will be activated when the system property "debug" is not defined at all:
-```xml
+```
<profiles>
<profile>
<activation>
@@ -217,7 +217,7 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
The following profile will be activated when the system property "debug" is not defined, or is defined with a value which is not "true".
-```xml
+```
<profiles>
<profile>
<activation>
@@ -240,7 +240,7 @@ mvn groupId:artifactId:goal -Ddebug=false
The next example will trigger the profile when the system property "environment" is specified with the value "test":
-```xml
+```
<profiles>
<profile>
<activation>
@@ -266,7 +266,7 @@ mvn groupId:artifactId:goal -Denvironment=test
Since Maven 3.9.0 one can also evaluate the POM's packaging value by referencing property `packaging`. This is only useful where the profile activation is defined in a common parent POM which is reused among multiple Maven projects. The next example will trigger the profile when a project with packaging `war` is built:
-```xml
+```
<profiles>
<profile>
<activation>
@@ -284,7 +284,7 @@ mvn groupId:artifactId:goal -Denvironment=test
This example will trigger the profile when the generated file `target/generated-sources/axistools/wsdl2java/org/apache/maven` is missing.
-```xml
+```
<profiles>
<profile>
<activation>
@@ -301,7 +301,7 @@ mvn groupId:artifactId:goal -Denvironment=test
Profiles can also be active by default using a configuration like the following:
-```xml
+```
<profiles>
<profile>
<id>profile-1</id>
@@ -399,7 +399,7 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
Example:
-```xml
+```
<project>
...
<repositories>
@@ -452,7 +452,7 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
External property definition concerns any property value defined outside the `pom.xml` but not defined in a corresponding profile inside it. The most obvious usage of properties in the POM is in plugin configuration. While it is certainly possible to break project portability without properties, these critters can have subtle effects that cause builds to fail. For example, specifying appserver paths in a profile that is specified in the `settings.xml` may cause your integration test plu [...]
-```xml
+```
<project>
...
<build>
@@ -474,7 +474,7 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
Now, in your local `${user.home}/.m2/settings.xml`, you have:
-```xml
+```
<settings>
...
<profiles>
@@ -505,7 +505,7 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
In addition to the above portability-breaker, it's easy to fail to cover all cases with your profiles. When you do this, you're usually leaving one of your target environments high and dry. Let's take the example `pom.xml` snippet from above one more time:
-```xml
+```
<project>
...
<build>
@@ -527,7 +527,7 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
Now, consider the following profile, which would be specified inline in the `pom.xml`:
-```xml
+```
<project>
...
<profiles>
diff --git a/content/markdown/guides/introduction/introduction-to-repositories.md b/content/markdown/guides/introduction/introduction-to-repositories.md
index 9867640d..1451569a 100644
--- a/content/markdown/guides/introduction/introduction-to-repositories.md
+++ b/content/markdown/guides/introduction/introduction-to-repositories.md
@@ -93,7 +93,7 @@ under the License.
Using the internal repository is quite simple. Simply make a change to add a `repositories` element:
-```xml
+```
<project>
...
diff --git a/content/markdown/guides/introduction/introduction-to-the-lifecycle.md b/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
index 11f6ad50..7c3fdbdd 100644
--- a/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
+++ b/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
@@ -161,7 +161,7 @@ mvn clean dependency:copy-dependencies package
For example, the Modello plugin binds by default its goal `modello:java` to the `generate-sources` phase (Note: The `modello:java` goal generates Java source codes). So to use the Modello plugin and have it generate sources from a model and incorporate that into the build, you would add the following to your POM in the `<plugins>` section of `<build>`:
-```xml
+```
<plugin>
<groupId>org.codehaus.modello</groupId>
<artifactId>modello-maven-plugin</artifactId>
@@ -188,7 +188,7 @@ mvn clean dependency:copy-dependencies package
Now, in the case of `modello:java`, it only makes sense in the `generate-sources` phase. But some goals can be used in more than one phase, and there may not be a sensible default. For those, you can specify the phase yourself. For example, let's say you have a goal `display:time` that echos the current time to the commandline, and you want it to run in the `process-test-resources` phase to indicate when the tests were started. This would be configured like so:
-```xml
+```
<plugin>
<groupId>com.mycompany.example</groupId>
<artifactId>display-maven-plugin</artifactId>
diff --git a/content/markdown/guides/introduction/introduction-to-the-pom.md b/content/markdown/guides/introduction/introduction-to-the-pom.md
index ddc941e1..1d930325 100644
--- a/content/markdown/guides/introduction/introduction-to-the-pom.md
+++ b/content/markdown/guides/introduction/introduction-to-the-pom.md
@@ -83,7 +83,7 @@ under the License.
Here's an example:
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -125,7 +125,7 @@ under the License.
As an example, let us reuse our previous artifact, com.mycompany.app:my-app:1. And let us introduce another artifact, com.mycompany.app:my-module:1.
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -152,7 +152,7 @@ under the License.
**com.mycompany.app:my-module:1's POM**
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -172,7 +172,7 @@ under the License.
Alternatively, if you want the groupId or the version of your modules to be the same as their parents, you can remove the groupId or the version identity of your module in its POM.
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -210,7 +210,7 @@ under the License.
To address this directory structure (or any other directory structure), we would have to add the `<relativePath>` element to our parent section.
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -245,7 +245,7 @@ under the License.
**com.mycompany.app:my-app:1's POM**
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -257,7 +257,7 @@ under the License.
**com.mycompany.app:my-module:1's POM**
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -280,7 +280,7 @@ under the License.
If we are to aggregate my-module into my-app, we would only have to modify my-app.
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -321,7 +321,7 @@ under the License.
The answer? - the same way as Example 3, by specifying the path to the module.
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -360,7 +360,7 @@ under the License.
**com.mycompany.app:my-app:1's POM**
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -372,7 +372,7 @@ under the License.
**com.mycompany.app:my-module:1's POM**
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -398,7 +398,7 @@ under the License.
**com.mycompany.app:my-app:1's POM**
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -415,7 +415,7 @@ under the License.
**com.mycompany.app:my-module:1's POM**
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -440,7 +440,7 @@ under the License.
For example, to access the `project.version` variable, you would reference it like so:
-```xml
+```
<version>${project.version}</version>
```
@@ -463,7 +463,7 @@ under the License.
The format of the build timestamp can be customized by declaring the property `maven.build.timestamp.format` as shown in the example below:
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
...
<properties>
@@ -479,7 +479,7 @@ under the License.
You are also able to reference any properties defined in the project as a variable. Consider the following example:
-```xml
+```
<project xmlns="http://maven.apache.org/POM/4.0.0">
...
<properties>
diff --git a/content/markdown/guides/mini/guide-archive-configuration.md b/content/markdown/guides/mini/guide-archive-configuration.md
index ac5052b8..82c41b4c 100644
--- a/content/markdown/guides/mini/guide-archive-configuration.md
+++ b/content/markdown/guides/mini/guide-archive-configuration.md
@@ -31,7 +31,7 @@ under the License.
To disable the generation of these files, include the following configuration for your plugin (in this example, the WAR plugin is used):
-```xml
+```
<project>
...
<build>
diff --git a/content/markdown/guides/mini/guide-assemblies.md b/content/markdown/guides/mini/guide-assemblies.md
index b9ff862e..bf424d8b 100644
--- a/content/markdown/guides/mini/guide-assemblies.md
+++ b/content/markdown/guides/mini/guide-assemblies.md
@@ -25,7 +25,7 @@ under the License.
The assembly mechanism in Maven provides an easy way to create distributions using a assembly descriptor and dependency information found in you POM. In order to use the assembly plug-in you need to configure the assembly plug-in in your POM and it might look like the following:
-```xml
+```
<project>
<parent>
<artifactId>maven</artifactId>
@@ -69,7 +69,7 @@ under the License.
This is the most typical usage of the assembly plugin where you are creating a distribution for standard use.
-```xml
+```
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>bin</id>
@@ -107,7 +107,7 @@ under the License.
How to use such pre-defined assembly descriptors is described in the [documentation of maven-assembly-plugin](/plugins/maven-assembly-plugin/usage.html#configuration).
-```xml
+```
<assembly
xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
@@ -147,7 +147,7 @@ under the License.
If you like to create a source distribution package the best solution is to use the [pre-defined assembly descriptor src](/plugins/maven-assembly-plugin/descriptor-refs.html#src) for such purposes.
-```xml
+```
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>src</id>
diff --git a/content/markdown/guides/mini/guide-attached-tests.md b/content/markdown/guides/mini/guide-attached-tests.md
index f5176b88..070b0c41 100644
--- a/content/markdown/guides/mini/guide-attached-tests.md
+++ b/content/markdown/guides/mini/guide-attached-tests.md
@@ -25,7 +25,7 @@ under the License.
You can reuse the tests that you have created for one project in another. For example, suppose `foo-core` contains test code in the `${basedir}/src/test/java`. To package up those compiled tests in a JAR and deploy them for general reuse, configure the `maven-jar-plugin` as follows:
-```xml
+```
<project>
<build>
@@ -52,7 +52,7 @@ under the License.
To use the attached test JAR, specify a dependency on the main artifact with a specified type of `test-jar` and the `classifier`.
-```xml
+```
<project>
...
diff --git a/content/markdown/guides/mini/guide-building-for-different-environments.md b/content/markdown/guides/mini/guide-building-for-different-environments.md
index 420cc17d..2a34d7b9 100644
--- a/content/markdown/guides/mini/guide-building-for-different-environments.md
+++ b/content/markdown/guides/mini/guide-building-for-different-environments.md
@@ -53,7 +53,7 @@ src/
In the project descriptor, you need to configure the different profiles. Only the test profile is showed here.
-```xml
+```
<profiles>
<profile>
<id>test</id>
diff --git a/content/markdown/guides/mini/guide-configuring-maven.md b/content/markdown/guides/mini/guide-configuring-maven.md
index c3ee5ed9..11c35d27 100644
--- a/content/markdown/guides/mini/guide-configuring-maven.md
+++ b/content/markdown/guides/mini/guide-configuring-maven.md
@@ -44,7 +44,7 @@ under the License.
The location of your local repository can be changed in your user configuration. The default value is `${user.home}/.m2/repository/`.
-```xml
+```
<settings>
...
<localRepository>/path/to/local/repo/</localRepository>
@@ -82,7 +82,7 @@ export MAVEN_OPTS=-Dmaven.artifact.threads=3
Which settings are required will depend on the type of repository you are deploying to. As of the first release, only SCP deployments and file deployments are supported by default, so only the following SCP configuration is needed:
-```xml
+```
<settings>
...
<servers>
diff --git a/content/markdown/guides/mini/guide-configuring-plugins.md b/content/markdown/guides/mini/guide-configuring-plugins.md
index 80886d7f..5cde7b6e 100644
--- a/content/markdown/guides/mini/guide-configuring-plugins.md
+++ b/content/markdown/guides/mini/guide-configuring-plugins.md
@@ -75,7 +75,7 @@ under the License.
Maven plugins (build and reporting) are configured by specifying a `<configuration>` element where the child elements of the `<configuration>` element are mapped to fields, or setters, inside your Mojo. (Remember that a plug-in consists of one or more Mojos where a Mojo maps to a goal.) Say, for example, you have a Mojo that performs a query against a particular URL, with a specified timeout and list of options. The Mojo might look like the following:
-```java
+```
@Mojo( name = "query" )
public class MyQueryMojo
extends AbstractMojo
@@ -99,7 +99,7 @@ public class MyQueryMojo
To configure the Mojo from your POM with the desired URL, timeout and options you might have something like the following:
-```xml
+```
<project>
...
<build>
@@ -151,7 +151,7 @@ mvn javadoc:help -Ddetail -Dgoal=javadoc
Mapping value types, like Boolean or Integer, is very simple. The `<configuration>` element might look like the following:
-```xml
+```
<project>
...
<configuration>
@@ -192,7 +192,7 @@ mvn javadoc:help -Ddetail -Dgoal=javadoc
Mapping complex types is also fairly straight forward. Let's look at a simple example where we are trying to map a configuration for Person object. The `<configuration>` element might look like the following:
-```xml
+```
<project>
...
<configuration>
@@ -213,7 +213,7 @@ mvn javadoc:help -Ddetail -Dgoal=javadoc
- If you wish to have the object to be instantiated live in a different package or have a more complicated name, specify this using an `implementation` attribute like the following:
-```xml
+```
<project>
...
<configuration>
@@ -234,7 +234,7 @@ mvn javadoc:help -Ddetail -Dgoal=javadoc
Mapping to collections works in much the same way as mapping to arrays. Each item is given in the XML as dedicated element. The element name does not matter in that case. So if you have a mojo like the following:
-```java
+```
public class MyAnimalMojo
extends AbstractMojo
{
@@ -251,7 +251,7 @@ public class MyAnimalMojo
where you have a field named `animals` then your configuration for the plug-in would look like the following:
-```xml
+```
<project>
...
<build>
@@ -287,7 +287,7 @@ public class MyAnimalMojo
Since Maven 3.3.9 ([MNG-5440](https://issues.apache.org/jira/browse/MNG-5440)), you can list individual items alternatively as comma-separated list in the XML value of animals directly. This approach is also used if configuring collection/array parameters via command line The following example is equivalent to the example above:
-```xml
+```
<project>
...
<build>
@@ -311,14 +311,14 @@ public class MyAnimalMojo
In the same way, you could define maps like the following:
-```java
+```
...
@Parameter
private Map<String,String> myMap;
...
```
-```xml
+```
<project>
...
<configuration>
@@ -339,14 +339,14 @@ public class MyAnimalMojo
Properties should be defined like the following:
-```java
+```
...
@Parameter
private Properties myProperties;
...
```
-```xml
+```
<project>
...
<configuration>
@@ -375,7 +375,7 @@ public class MyAnimalMojo
You can also configure a mojo using the `<executions>` tag. This is most commonly used for mojos that are intended to participate in some phases of the [build lifecycle](../introduction/introduction-to-the-lifecycle.html). Using `MyQueryMojo` as an example, you may have something that will look like:
-```xml
+```
<project>
...
<build>
@@ -429,7 +429,7 @@ public class MyAnimalMojo
How about if we have a multiple executions with different phases bound to it? How do you think will it behave? Let us use the example POM above again, but this time we shall bind `execution2` to a phase.
-```xml
+```
<project>
...
<build>
@@ -470,7 +470,7 @@ public class MyAnimalMojo
Now, let us have another mojo example which shows a default lifecycle phase binding.
-```java
+```
@Mojo( name = "query", defaultPhase = LifecyclePhase.PACKAGE )
public class MyBoundQueryMojo
extends AbstractMojo
@@ -494,7 +494,7 @@ public class MyBoundQueryMojo
From the above mojo example, `MyBoundQueryMojo` is by default bound to the package phase (see the `@phase` notation). But if we want to execute this mojo during the install phase and not with package we can rebind this mojo into a new lifecycle phase using the `<phase>` tag under `<execution>`.
-```xml
+```
<project>
...
<build>
@@ -541,7 +541,7 @@ mvn myquery:query@execution1
For instance, the Maven Antrun Plugin version 1.2 uses Ant version 1.6.5, if you want to use the latest Ant version when running this plugin, you need to add `<dependencies>` element like the following:
-```xml
+```
<project>
...
<build>
@@ -574,7 +574,7 @@ mvn myquery:query@execution1
By default, plugin configuration should be propagated to child POMs, so to break the inheritance, you could use the `<inherited>` tag:
-```xml
+```
<project>
...
<build>
@@ -608,7 +608,7 @@ mvn myquery:query@execution1
You can configure a reporting plugin using the `<reportSets>` tag. This is most commonly used to generate reports selectively when running `mvn site`. The following will generate only the project team report.
-```xml
+```
<project>
...
<reporting>
@@ -635,7 +635,7 @@ mvn myquery:query@execution1
1 To exclude all reports, you need to use:
-```xml
+```
<reportSets>
<reportSet>
<reports/>
@@ -649,7 +649,7 @@ mvn myquery:query@execution1
Similar to the build plugins, to break the inheritance, you can use the `<inherited>` tag:
-```xml
+```
<project>
...
<reporting>
diff --git a/content/markdown/guides/mini/guide-creating-archetypes.md b/content/markdown/guides/mini/guide-creating-archetypes.md
index 08facb30..a63bc0be 100644
--- a/content/markdown/guides/mini/guide-creating-archetypes.md
+++ b/content/markdown/guides/mini/guide-creating-archetypes.md
@@ -39,7 +39,7 @@ under the License.
An example `pom.xml` for an archetype artifact looks as follows:
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -69,7 +69,7 @@ under the License.
The [archetype descriptor](/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html) is a file called `archetype-metadata.xml` which must be located in the `src/main/resources/META-INF/maven/` directory. An example of an archetype descriptor can be found in the quickstart archetype:
-```xml
+```
<archetype-descriptor
xmlns="http://maven.apache.org/plugins/maven-archetype-plugin/archetype-descriptor/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -103,7 +103,7 @@ under the License.
Thus the quickstart archetype shown above defines the following directory structure:
-```xml
+```
archetype
|-- pom.xml
@@ -131,7 +131,7 @@ archetype
An example for a prototype `pom.xml` is:
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
diff --git a/content/markdown/guides/mini/guide-default-execution-ids.md b/content/markdown/guides/mini/guide-default-execution-ids.md
index 25f33f6e..cb7990fc 100644
--- a/content/markdown/guides/mini/guide-default-execution-ids.md
+++ b/content/markdown/guides/mini/guide-default-execution-ids.md
@@ -45,7 +45,7 @@ under the License.
In this case, the assembly-plugin configuration might look like this:
-```xml
+```
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
@@ -90,7 +90,7 @@ under the License.
The resulting configuration might look something like this:
-```xml
+```
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
@@ -138,7 +138,7 @@ under the License.
The resulting compiler-plugin configuration might look something like the following:
-```xml
+```
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
diff --git a/content/markdown/guides/mini/guide-deployment-security-settings.md b/content/markdown/guides/mini/guide-deployment-security-settings.md
index 02a23375..11f3c306 100644
--- a/content/markdown/guides/mini/guide-deployment-security-settings.md
+++ b/content/markdown/guides/mini/guide-deployment-security-settings.md
@@ -29,7 +29,7 @@ under the License.
Which settings are required will depend on the type of repository you are deploying to. As of the first release, only SCP deployments and file deployments are supported by default, so only the following SCP configuration is needed:
-```xml
+```
<settings>
.
diff --git a/content/markdown/guides/mini/guide-encryption.md b/content/markdown/guides/mini/guide-encryption.md
index 01bc4260..68587a3d 100644
--- a/content/markdown/guides/mini/guide-encryption.md
+++ b/content/markdown/guides/mini/guide-encryption.md
@@ -77,7 +77,7 @@ mvn --encrypt-master-password <password>
Store this password in the `${user.home}/.m2/settings-security.xml`; it should look like
-```xml
+```
<settingsSecurity>
<master>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}</master>
</settingsSecurity>
@@ -103,7 +103,7 @@ mvn --encrypt-password <password>
Copy and paste it into the servers section of your `settings.xml` file. This will look like:
-```xml
+```
<settings>
...
<servers>
@@ -121,7 +121,7 @@ mvn --encrypt-password <password>
Please note that password can contain any information outside of the curly brackets, so that the following will still work:
-```xml
+```
<settings>
...
<servers>
@@ -149,7 +149,7 @@ mvn deploy:deploy-file -Durl=https://maven.corp.com/repo \
Create the master password exactly as described above, and store it on a removable drive, for instance on OSX, my USB drive mounts as `/Volumes/mySecureUsb`, so I store
-```xml
+```
<settingsSecurity>
<master>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}</master>
</settingsSecurity>
@@ -159,7 +159,7 @@ mvn deploy:deploy-file -Durl=https://maven.corp.com/repo \
And then I create `${user.home}/.m2/settings-security.xml` with the following content:
-```xml
+```
<settingsSecurity>
<relocation>/Volumes/mySecureUsb/secure/settings-security.xml</relocation>
</settingsSecurity>
diff --git a/content/markdown/guides/mini/guide-generating-sources.md b/content/markdown/guides/mini/guide-generating-sources.md
index 6d547035..606198c9 100644
--- a/content/markdown/guides/mini/guide-generating-sources.md
+++ b/content/markdown/guides/mini/guide-generating-sources.md
@@ -27,7 +27,7 @@ under the License.
So this is all fine and dandy, we have a plugin that wants to generate some sources from a Antlr4 grammar but how do we use it. You need to specify that you want to use it in your POM:
-```xml
+```
<project>
...
diff --git a/content/markdown/guides/mini/guide-http-settings.md b/content/markdown/guides/mini/guide-http-settings.md
index 85319b5a..a8f04fe3 100644
--- a/content/markdown/guides/mini/guide-http-settings.md
+++ b/content/markdown/guides/mini/guide-http-settings.md
@@ -73,7 +73,7 @@ under the License.
In all HTTP transports, you can add your custom HTTP headers like this:
-```xml
+```
<settings>
<servers>
<server>
@@ -97,7 +97,7 @@ under the License.
All transport implementations that perform some network access allow the configuration of a several timeouts, for example to allow the user to tell Maven how long to wait before giving up on a connection that has not responded.
-```xml
+```
<settings>
<servers>
<server>
@@ -174,7 +174,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
In all of the examples below, it's important to understand that you can configure the HTTP settings for all requests made to a given server, or for only one method. To configure all methods for a server, use the following section of the `settings.xml` file:
-```xml
+```
<settings>
[...]
<servers>
@@ -194,7 +194,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
On the other hand, if you can live with the default configuration for most requests - say, HEAD and GET requests, which are used to check for the existence of a file and retrieve a file respectively - maybe you only need to configure the PUT method:
-```xml
+```
<settings>
[...]
<servers>
@@ -220,7 +220,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
To turn off this default behavior, simply disable the default headers. Then, respecify the other headers that you are still interested in, like this:
-```xml
+```
<settings>
[...]
<servers>
@@ -294,7 +294,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
Using the above syntax, you can configure preemptive authentication for PUT requests using the boolean HttpClient parameter `http.authentication.preemptive`, like this:
-```xml
+```
<settings>
<servers>
<server>
@@ -318,7 +318,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
Another option is to make write it like this:
-```xml
+```
<settings>
<servers>
<server>
@@ -343,7 +343,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
Like the example above, telling the HttpClient to ignore cookies for all methods of request is a simple matter of configuring the `http.protocol.cookie-policy` parameter (it uses a regular string value, so no special syntax is required):
-```xml
+```
<settings>
<servers>
<server>
@@ -375,7 +375,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
In all HTTP Wagon implementations, you can add your own HTTP headers like this:
-```xml
+```
<settings>
<servers>
<server>
@@ -399,7 +399,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
All wagon implementations that extend the `AbstractWagon` class, including those for SCP, HTTP, FTP, and more, allow the configuration of a connection timeout, to allow the user to tell Maven how long to wait before giving up on a connection that has not responded. This option is preserved in the HttpClient-based wagon, but this wagon also provides a fine-grained alternative configuration that can allow you to specify timeouts per-method for a given server. The old configuration option [...]
-```xml
+```
<settings>
<servers>
<server>
@@ -414,7 +414,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
...while the new configuration option looks more like this:
-```xml
+```
<settings>
<servers>
<server>
@@ -437,7 +437,7 @@ problems with HTTP servers and proxies that do not support HTTP/1.1 protocol.
With Wagon 2.0 and Apache Maven 3.0.4, a default timeout of 30 minutes comes by default. If you want to change this value, you can add the following setup in your settings:
-```xml
+```
<settings>
<servers>
<server>
diff --git a/content/markdown/guides/mini/guide-large-scale-centralized-deployments.md b/content/markdown/guides/mini/guide-large-scale-centralized-deployments.md
index 3cdbb86a..d2a00dab 100644
--- a/content/markdown/guides/mini/guide-large-scale-centralized-deployments.md
+++ b/content/markdown/guides/mini/guide-large-scale-centralized-deployments.md
@@ -73,7 +73,7 @@ under the License.
Example: To download artifacts from the corporate repository manager's `maven-virtual` repository:
-```xml
+```
<settings>
...
<mirrors>
@@ -103,7 +103,7 @@ under the License.
Example: To upload artifacts to one of the corporate repository manager's hosted repositories:
-```xml
+```
<settings>
...
<profiles>
diff --git a/content/markdown/guides/mini/guide-maven-classloading.md b/content/markdown/guides/mini/guide-maven-classloading.md
index cd3cdaea..5d852ce7 100644
--- a/content/markdown/guides/mini/guide-maven-classloading.md
+++ b/content/markdown/guides/mini/guide-maven-classloading.md
@@ -96,7 +96,7 @@ under the License.
Users can add dependencies to this classloader by adding dependencies to a plugin in the `[plugins/plugin](/ref/current/maven-model/maven.html#class_plugin)` section of their project `pom.xml`. Here is a sample of adding `ant-nodeps` to the plugin classloader of the Antrun Plugin and hereby enabling the use of additional/optional Ant tasks:
-```xml
+```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
diff --git a/content/markdown/guides/mini/guide-mirror-settings.md b/content/markdown/guides/mini/guide-mirror-settings.md
index 2500aa4d..edf960ce 100644
--- a/content/markdown/guides/mini/guide-mirror-settings.md
+++ b/content/markdown/guides/mini/guide-mirror-settings.md
@@ -34,7 +34,7 @@ under the License.
To configure a mirror of a given repository, you provide it in your settings file (`${user.home}/.m2/settings.xml`), giving the new repository its own `id` and `url`, and specify the `mirrorOf` setting that is the ID of the repository you are using a mirror of. For example, the ID of the main Maven Central repository included by default is `central`, so to use the different mirror instance, you would configure the following:
-```xml
+```
<settings>
...
<mirrors>
@@ -65,7 +65,7 @@ under the License.
**Note:** This feature is only available in Maven 2.0.5+.
-```xml
+```
<settings>
...
<mirrors>
@@ -112,7 +112,7 @@ under the License.
- `*,!repo1` = everything except repo1
-```xml
+```
<settings>
...
<mirrors>
diff --git a/content/markdown/guides/mini/guide-multiple-repositories.md b/content/markdown/guides/mini/guide-multiple-repositories.md
index 09e3f2f1..28788183 100644
--- a/content/markdown/guides/mini/guide-multiple-repositories.md
+++ b/content/markdown/guides/mini/guide-multiple-repositories.md
@@ -24,7 +24,7 @@ under the License.
There are two different ways that you can specify the use of multiple repositories. The first way is to specify in a POM which repositories you want to use. That is supported both inside and outside of build profiles:
-```xml
+```
<project>
...
@@ -49,7 +49,7 @@ under the License.
The other way you can specify multiple repositories is by creating a profile in the `${user.home}/.m2/settings.xml` or `${maven.home}/conf/settings.xml` file like the following:
-```xml
+```
<settings>
...
diff --git a/content/markdown/guides/mini/guide-proxies.md b/content/markdown/guides/mini/guide-proxies.md
index 1b8e7451..ce5da3ac 100644
--- a/content/markdown/guides/mini/guide-proxies.md
+++ b/content/markdown/guides/mini/guide-proxies.md
@@ -26,7 +26,7 @@ under the License.
The `nonProxyHosts` setting accepts wild cards, and each host not to proxy is separated by the | character. This matches the JDK configuration equivalent.
-```xml
+```
<settings>
.
diff --git a/content/markdown/guides/mini/guide-releasing.md b/content/markdown/guides/mini/guide-releasing.md
index db680e95..b48cf04f 100644
--- a/content/markdown/guides/mini/guide-releasing.md
+++ b/content/markdown/guides/mini/guide-releasing.md
@@ -66,7 +66,7 @@ mvn release:prepare \
The previous goal parameters can be supplied while executing maven on the commandline, (as shown in the previous example) or they can be defined and maintained within the project's _pom.xml_ file. The location of the current development trunk is defined within the _pom.xml_ file in the following form:
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
@@ -103,7 +103,7 @@ mvn release:prepare \
To define the tagBase parameter within the _pom.xml_ file a tagBase element must be defined within a _plugins/plugin/configuration_ element. The following example shows how this would look within the _pom.xml_ file.
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
@@ -199,7 +199,7 @@ checkpoint.check-in-development-version=OK
The following is an example of how a distributionManagement element can be configured within a project _pom.xml_ file.
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
diff --git a/content/markdown/guides/mini/guide-relocation.md b/content/markdown/guides/mini/guide-relocation.md
index 7c352245..4c6f3506 100644
--- a/content/markdown/guides/mini/guide-relocation.md
+++ b/content/markdown/guides/mini/guide-relocation.md
@@ -46,7 +46,7 @@ under the License.
The minimal POM file might look like this for version 1.0 of `foo`:
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>bar</groupId>
diff --git a/content/markdown/guides/mini/guide-repository-ssl.md b/content/markdown/guides/mini/guide-repository-ssl.md
index aa458174..df8a9f06 100644
--- a/content/markdown/guides/mini/guide-repository-ssl.md
+++ b/content/markdown/guides/mini/guide-repository-ssl.md
@@ -64,7 +64,7 @@ maven.repo.remote=https://my.server.com/maven,http://www.ibiblio.org/maven
The following command line imports the certififcate authority's certificate into a JKS formatted key store named `trust.jks`, the _trust store_.
-```bash
+```
$> keytool -v -alias mavensrv -import \
-file /somewhere/in/filesystem/CACert.cert\
-keystore trust.jks
@@ -104,7 +104,7 @@ $>
They may be set either on maven's command-line, in `.mavenrc` file or in `MAVEN_OPTS` environment variable. For the setting defined in this document, here is an example `.mavenrc` file:
-```bash
+```
MAVEN_OPTS="-Xmx512m -Djavax.net.ssl.trustStore=trust.jks \
-Djavax.net.ssl.trustStorePassword= \
-Djavax.net.ssl.keyStore=/home/directory/mycertificate.p12 \
diff --git a/content/markdown/guides/mini/guide-reproducible-builds.md b/content/markdown/guides/mini/guide-reproducible-builds.md
index 57d66a52..d67bba5e 100644
--- a/content/markdown/guides/mini/guide-reproducible-builds.md
+++ b/content/markdown/guides/mini/guide-reproducible-builds.md
@@ -40,7 +40,7 @@ mvn artifact:check-buildplan
1 Enable Reproducible Builds mode for plugins, by adding [`project.build.outputTimestamp` property](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318#Reproducible/VerifiableBuilds-OutputArchiveEntriesTimestamp) to the project's `pom.xml`:
-```xml
+```
<properties>
<project.build.outputTimestamp>2023-01-01T00:00:00Z</project.build.outputTimestamp>
</properties>
diff --git a/content/markdown/guides/mini/guide-site.md b/content/markdown/guides/mini/guide-site.md
index 2fafdea2..854310e6 100644
--- a/content/markdown/guides/mini/guide-site.md
+++ b/content/markdown/guides/mini/guide-site.md
@@ -91,7 +91,7 @@ mvn site
To be able to deploy the site with a classical network protocol (ftp, scp, webdav), you must first declare a location to distribute to in your `pom.xml`, similar to the repository for deployment:
-```xml
+```
<project>
...
<distributionManagement>
@@ -120,7 +120,7 @@ mvn site-deploy
For example with a project hosted on GitHub and using GitHub Pages for its site publication:
-```xml
+```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-scm-publish-plugin</artifactId>
@@ -142,7 +142,7 @@ mvn site-deploy
The `site.xml` file is used to describe the structure of the site. A sample is given below:
-```xml
+```
<?xml version="1.0" encoding="ISO-8859-1"?>
<project xmlns="http://maven.apache.org/DECORATION/1.8.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/DECORATION/1.8.0 https://maven.apache.org/xsd/decoration-1.8.0.xsd"
@@ -227,7 +227,7 @@ mvn site-deploy
To add these reports to your site, you must add the Project Info Reports plugin to a special `<reporting>` section in the POM. The following example shows how to configure the standard project information reports that display information from the POM in a friendly format:
-```xml
+```
<project>
...
<reporting>
@@ -257,7 +257,7 @@ mvn site-deploy
To enable multiple locales, add a configuration similar to the following to your POM:
-```xml
+```
<project>
...
<build>
diff --git a/content/markdown/guides/mini/guide-snippet-macro.md b/content/markdown/guides/mini/guide-snippet-macro.md
index 3b1aa2c5..5fe0828a 100644
--- a/content/markdown/guides/mini/guide-snippet-macro.md
+++ b/content/markdown/guides/mini/guide-snippet-macro.md
@@ -39,7 +39,7 @@ under the License.
#### Java
-```java
+```
// START SNIPPET: snip-id
public static void main( String[] args )
{
@@ -50,7 +50,7 @@ under the License.
#### XML
-```xml
+```
<!-- START SNIPPET: snip-id -->
<navigation-rule>
<from-view-id>/logon.jsp</from-view-id>
diff --git a/content/markdown/guides/mini/guide-using-ant.md b/content/markdown/guides/mini/guide-using-ant.md
index 447b1d3b..4b09e3ad 100644
--- a/content/markdown/guides/mini/guide-using-ant.md
+++ b/content/markdown/guides/mini/guide-using-ant.md
@@ -24,7 +24,7 @@ under the License.
The example above illustrates how to bind an ant script to a lifecycle phase. You can add a script to each lifecycle phase, by duplicating the _execution/_ section and specifying a new phase.
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
@@ -64,7 +64,7 @@ under the License.
So a concrete example would be something like the following:
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
diff --git a/content/markdown/guides/mini/guide-using-extensions.md b/content/markdown/guides/mini/guide-using-extensions.md
index 80205c53..388624f5 100644
--- a/content/markdown/guides/mini/guide-using-extensions.md
+++ b/content/markdown/guides/mini/guide-using-extensions.md
@@ -46,7 +46,7 @@ under the License.
Example:
-```xml
+```
<project>
...
@@ -71,7 +71,7 @@ under the License.
Example:
-```xml
+```
<project>
...
diff --git a/content/markdown/guides/mini/guide-wagon-providers.md b/content/markdown/guides/mini/guide-wagon-providers.md
index aadf492c..4231f535 100644
--- a/content/markdown/guides/mini/guide-wagon-providers.md
+++ b/content/markdown/guides/mini/guide-wagon-providers.md
@@ -44,7 +44,7 @@ mvn -Dmaven.wagon.provider.http=httpclient clean install
To specify which Wagon provider to use for a particular server, modify your `settings.xml` file to add the `<wagonProvider>` configuration to your `<server>` entry, like the following:
-```xml
+```
<settings>
[...]
<servers>
@@ -61,7 +61,7 @@ mvn -Dmaven.wagon.provider.http=httpclient clean install
Maven 2.2.1 provides two providers for HTTP/HTTPS Wagons: `lightweight` and `httpclient`. If you add a new HTTP Wagon implementation via build extension, you'll need to make sure the extension binds its Wagon components to role-hints of the form `<protocol>-<provider>` in order to allow users to specify your alternative Wagon provider. For instance, the HttpClient HTTP Wagon component definition looks like this:
-```xml
+```
<component>
<role>org.apache.maven.wagon.Wagon</role>
<role-hint>http-httpclient</role-hint>
diff --git a/content/markdown/guides/plugin/guide-java-plugin-development.md b/content/markdown/guides/plugin/guide-java-plugin-development.md
index 45acfc5e..3b84d309 100644
--- a/content/markdown/guides/plugin/guide-java-plugin-development.md
+++ b/content/markdown/guides/plugin/guide-java-plugin-development.md
@@ -73,7 +73,7 @@ Any class with this annotation are included in the plugin configuration file.
Listed below is a simple mojo class which has no parameters. This is about as simple as a mojo can be.
After the listing is a description of the various parts of the source.
-```java
+```
package sample.plugin;
import org.apache.maven.plugin.AbstractMojo;
@@ -116,7 +116,7 @@ Once the mojos have been written for the plugin, it is time to build the plugin.
Listed below is an illustration of the sample mojo project's pom with the parameters set as described in the above table:
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
@@ -189,7 +189,7 @@ For more details, you can look at [detailed bindings for `maven-plugin` packagin
The most direct means of executing your new plugin is to specify the plugin goal directly on the command line.
To do this, you need to configure the `hello-maven-plugin` plugin in you project:
-```xml
+```
<project>
...
<build>
@@ -230,7 +230,7 @@ There are several ways to reduce the amount of required typing:
- Finally, you can also add your plugin's groupId to the list of groupIds searched by default.
To do this, you need to add the following to your `${user.home}/.m2/settings.xml` file:
-```xml
+```
<pluginGroups>
<pluginGroup>sample.plugin</pluginGroup>
</pluginGroups>
@@ -242,7 +242,7 @@ At this point, you can run the mojo with `mvn hello:sayhi`.
You can also configure your plugin to attach specific goals to a particular phase of the build lifecycle. Here is an example:
-```xml
+```
<build>
<pluginManagement>
<plugins>
@@ -296,7 +296,7 @@ It is unlikely that a mojo will be very useful without parameters. Parameters pr
Defining a parameter is as simple as creating an instance variable in the mojo and adding the proper annotations.
Listed below is an example of a parameter for the simple mojo:
-```java
+```
/**
* The greeting to display.
*/
@@ -319,7 +319,7 @@ The `property` parameter can be used to allow configuration of the mojo paramete
Configuring the parameter values for a plugin is done in a Maven project within the `pom.xml` file as part of defining the plugin in the project.
An example of configuring a plugin:
-```xml
+```
<plugin>
<groupId>sample.plugin</groupId>
<artifactId>hello-maven-plugin</artifactId>
@@ -344,7 +344,7 @@ You can also add `@Parameter` annotation on setter method (from version 3.7.0 of
So our Mojo would look like the following:
-```java
+```
public class MyQueryMojo extends AbstractMojo {
diff --git a/content/markdown/guides/plugin/guide-java-report-plugin-development.md b/content/markdown/guides/plugin/guide-java-report-plugin-development.md
index 1e3a6de5..35bb90dc 100644
--- a/content/markdown/guides/plugin/guide-java-report-plugin-development.md
+++ b/content/markdown/guides/plugin/guide-java-report-plugin-development.md
@@ -34,7 +34,7 @@ under the License.
1 A regular Maven project usually invokes _reporting goals_ of a plugin by declaring such plugin in the [`<reporting>`](/plugins/maven-site-plugin/examples/configuring-reports.html) section of its `pom.xml` as in the example below:
-```xml
+```
<project>
...
<reporting>
@@ -103,7 +103,7 @@ under the License.
#### ./pom.xml
-```xml
+```
<project 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/maven-4.0.0.xsd">
@@ -207,7 +207,7 @@ under the License.
#### ./src/main/java/com/mycompany/maven/SimpleReport.java
-```java
+```
package com.mycompany.maven;
import java.util.Locale;
@@ -326,7 +326,7 @@ mvn install
To make sure everything went well and is properly declared, you can now execute the below command in any other Maven project directory:
-```bash
+```
$ mvn com.mycompany.maven:simple-maven-plugin:1.0-SNAPSHOT:help
[INFO] --- simple-maven-plugin:1.0-SNAPSHOT:help (default-cli) @ hardware-connectors ---
@@ -355,7 +355,7 @@ simple:simple
To invoke the _report Mojo_ of our plugin in another Maven project, we just need to declare the plugin in the [`<reporting>`](/plugins/maven-site-plugin/examples/configuring-reports.html) section of its `pom.xml` as in the example below:
-```xml
+```
<project>
...
<reporting>
@@ -381,7 +381,7 @@ simple:simple
You will use the [`Sink`](/doxia/doxia/doxia-sink-api/apidocs/org/apache/maven/doxia/sink/Sink.html) object associated to the report:
-```java
+```
Sink sink = getSink();
```
@@ -417,7 +417,7 @@ Sink sink = getSink();
You may need to create not just one HTML file, but several of them (like Javadoc produces one HTML file for each Java class). To do so, you will need to get a new _Sink_ for each HTML file you need to produce. This is achieved by using the [`SinkFactory`](/doxia/doxia/doxia-sink-api/apidocs/org/apache/maven/doxia/sink/SinkFactory.html) object that you can easily obtain with the [`getSinkFactory()`](/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html# [...]
-```java
+```
public class SimpleReport extends AbstractMavenReport {
...
diff --git a/content/markdown/plugin-developers/common-bugs.md b/content/markdown/plugin-developers/common-bugs.md
index d0d344a0..42ae60fa 100644
--- a/content/markdown/plugin-developers/common-bugs.md
+++ b/content/markdown/plugin-developers/common-bugs.md
@@ -53,7 +53,7 @@ under the License.
Therefore, developers should avoid any direct or indirect usage of the classes/methods that simply employ the platform's default encoding. For instance, `FileWriter` and `FileReader` should usually be avoided:
-```java
+```
/*
* FIXME: This assumes the source file is using the platform's default encoding.
*/
@@ -70,7 +70,7 @@ Reader reader = new FileReader( javaFile );
Finally note that XML files require special handling because they are equipped with an encoding declaration in the XML prolog. Reading or writing XML files with an encoding that does not match their XML prolog's `encoding` attribute is a bad idea:
-```java
+```
/*
* FIXME: This assumes the XML encoding declaration matches the platform's default encoding.
*/
@@ -84,7 +84,7 @@ writer.write( xmlContent );
URLs and filesystem paths are really two different things and converting between them is not trivial. The main source of problems is that different encoding rules apply for the strings that make up a URL or filesystem path. For example, consider the following code snippet and its associated console output:
-```java
+```
File file = new File( "foo bar+foo" );
URL url = file.toURI().toURL();
@@ -105,7 +105,7 @@ System.out.println( URLDecoder.decode( url.getPath(), "UTF-8" ) );
Next, `[URL.getPath()](http://java.sun.com/javase/6/docs/api/java/net/URL.html#getPath())` does in general not return a string that can be used as a filesystem path. It returns a substring of the URL and as such can contain escape sequences. The prominent example is the space character which will show up as "%20". People sometimes hack around this by means of `replace("%20", " ")` but that does simply not cover all cases. It's worth to mention that on the other hand the related method ` [...]
-```java
+```
URL url = new URL( "file:/C:/Program%20Files/Java/bin/java.exe" );
/*
@@ -118,7 +118,7 @@ File path = new File( url.getPath() );
In an ideal world, code targetting JRE 1.4+ could easily avoid these problems by using the constructor `[File(URI)](http://java.sun.com/javase/6/docs/api/java/io/File.html#File(java.net.URI))` as suggested by the following snippet:
-```java
+```
URL url = new URL( "file:/C:/Documents and Settings/user/.m2/settings.xml" );
/*
@@ -137,7 +137,7 @@ File path = new File( new URI( url.toExternalForm() ) );
The gotcha with the arg-less methods is that their output depends on the default locale of the JVM but the default locale is out of control of the developer. That means the string expected by the developer (who runs/tests his code in a JVM using locale `xy`) does not necessarily match the string seen by another user (that runs a JVM with locale `ab`). For example, the comparison shown in the next code snippet is likely to fail for systems with default locale Turkish because Turkish has [...]
-```java
+```
/*
* FIXME: This assumes the casing rules of the current platform
* match the rules for the English locale.
@@ -173,7 +173,7 @@ src/
Maven's command line supports the definition of system properties via arguments of the form `-D key=value`. While these properties are called system properties, plugins should never use `[System.getProperty()](http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperty(java.lang.String))` and related methods to query these properties. For example, the following code snippet will not work reliably when Maven is embedded, say into an IDE or a CI server:
-```java
+```
public MyMojo extends AbstractMojo
{
public void execute()
@@ -192,7 +192,7 @@ public MyMojo extends AbstractMojo
People occasionally employ shutdown hooks to perform cleanup tasks, e.g. to delete temporary files as shown in the example below:
-```java
+```
public MyMojo extends AbstractMojo
{
public void execute()
@@ -233,7 +233,7 @@ public MyMojo extends AbstractMojo
Hence this example code is prone to misbehave:
-```java
+```
public MyMojo extends AbstractMojo
{
/**
@@ -254,7 +254,7 @@ public MyMojo extends AbstractMojo
In order to guarantee reliable builds, Maven and its plugins must manually resolve relative paths against the project's base directory. A simple idiom like the following will do just fine:
-```java
+```
File file = new File( path );
if ( !file.isAbsolute() )
{
@@ -270,7 +270,7 @@ if ( !file.isAbsolute() )
Now, some plugins need to create additional files in the report output directory that accompany the report generated via the sink interface. While it is tempting to use either the method `getOutputDirectory()` or the field `outputDirectory` directly in order to setup a path for the output files, this leads most likely to a bug. More precisely, those plugins will not properly output files when run by the Maven Site Plugin as part of the site lifecycle. This is best noticed when the outpu [...]
-```java
+```
public MyReportMojo extends AbstractMavenReport
{
/**
@@ -304,7 +304,7 @@ public MyReportMojo extends AbstractMavenReport
For example, the next snippet tries to retrieve the mojo logger during construction time but the mojo logger is an injected component and as such has not been properly initialized yet:
-```java
+```
public MyMojo extends AbstractMojo
{
/*
diff --git a/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md b/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
index 37139c5a..6fb725d1 100644
--- a/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
+++ b/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
@@ -67,7 +67,7 @@ default: `${basedir}/src/test/resources/META-INF/plexus`|
In your `pom.xml`, replace `plexus-maven-plugin` configuration:
-```xml
+```
<project>
<build>
<plugins>
@@ -89,7 +89,7 @@ default: `${basedir}/src/test/resources/META-INF/plexus`|
with corresponding `plexus-component-metadata` configuration:
-```xml
+```
<project>
<build>
<plugins>
@@ -115,7 +115,7 @@ default: `${basedir}/src/test/resources/META-INF/plexus`|
In your `pom.xml`, add `plexus-component-annotations` dependency:
-```xml
+```
<project>
<dependencies>
<dependency>
@@ -129,7 +129,7 @@ default: `${basedir}/src/test/resources/META-INF/plexus`|
In your java sources, replace javadoc tags:
-```java
+```
/**
* @plexus.component role="foo.MyComponent" role-hint="hint-value"
*/
@@ -145,7 +145,7 @@ public class MyComponentImplementation
with corresponding Java 5 annotations
-```java
+```
import org.codehaus.plexus.component.annotations.Component;
import org.codehaus.plexus.component.annotations.Requirement;
diff --git a/content/markdown/plugin-developers/plugin-testing.md b/content/markdown/plugin-developers/plugin-testing.md
index 389f0a78..a0f97e87 100644
--- a/content/markdown/plugin-developers/plugin-testing.md
+++ b/content/markdown/plugin-developers/plugin-testing.md
@@ -56,7 +56,7 @@ under the License.
In general, you need to include `maven-plugin-testing-harness` as a dependency, and create a \*MojoTest (by convention) class which `extends AbstractMojoTestCase`.
-```xml
+```
...
<dependencies>
...
@@ -71,7 +71,7 @@ under the License.
...
```
-```java
+```
public class YourMojoTest
extends AbstractMojoTestCase
{
@@ -117,7 +117,7 @@ public class YourMojoTest
You can take a look at the [maven-install-plugin](https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin/src/it/) how there are integration tests are written.
-```xml
+```
<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
...
diff --git a/content/markdown/plugins/localization.md b/content/markdown/plugins/localization.md
index d32cea26..0c27bc7c 100644
--- a/content/markdown/plugins/localization.md
+++ b/content/markdown/plugins/localization.md
@@ -64,7 +64,7 @@ under the License.
- Configure a project to use the latest SNAPSHOT version of the plugin you are working on. Also configure the project to produce a site in the language you are adding a translation for. For Spanish, as we used in the example above, it would look like this:
-```xml
+```
<build>
<plugins>
<plugin>
diff --git a/content/markdown/repository/central-index.md b/content/markdown/repository/central-index.md
index 2c4341a8..f7da9a80 100644
--- a/content/markdown/repository/central-index.md
+++ b/content/markdown/repository/central-index.md
@@ -40,7 +40,7 @@ java -jar indexer-cli-5.1.1.jar --unpack nexus-maven-repository-index.gz --desti
- download and extract [Luke binary tarball](https://github.com/DmitryKey/luke/releases/download/luke-4.10.4/luke-with-deps.tar.gz) and launch it on the Central index with Lucene format:
-```bash
+```
luke.sh -ro -index central-lucene-index
```
diff --git a/content/markdown/repository/guide-central-repository-upload.md b/content/markdown/repository/guide-central-repository-upload.md
index 520be3d0..266b4581 100644
--- a/content/markdown/repository/guide-central-repository-upload.md
+++ b/content/markdown/repository/guide-central-repository-upload.md
@@ -48,7 +48,7 @@ under the License.
### A basic sample
-```xml
+```
<project>
<modelVersion>4.0.0</modelVersion>
diff --git a/content/markdown/skins/index.md b/content/markdown/skins/index.md
index ce1ef828..8e374907 100644
--- a/content/markdown/skins/index.md
+++ b/content/markdown/skins/index.md
@@ -52,7 +52,7 @@ under the License.
To use one of these skins in your project, you use the `skin` element of the [site descriptor](/plugins/maven-site-plugin/examples/sitedescriptor.html). This is a regular artifact or dependency-like element. For example, to use the Maven Fluido Skin, you would include the this in your `site.xml` file:
-```xml
+```
<project>
...
<skin>
[maven-site] 05/14: Revert "Refresh - Guide to Developing Java Plugins"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit 917e15fd39194f9d85d62eb28f698a11ebeb325e
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:32:14 2023 +0100
Revert "Refresh - Guide to Developing Java Plugins"
This reverts commit ec3f5b70f3441388a7d44f5aadc3ff848918ba0f.
---
.../guides/plugin/guide-java-plugin-development.md | 387 ++++++++++++---------
1 file changed, 221 insertions(+), 166 deletions(-)
diff --git a/content/markdown/guides/plugin/guide-java-plugin-development.md b/content/markdown/guides/plugin/guide-java-plugin-development.md
index bf3e9ab1..725cbd36 100644
--- a/content/markdown/guides/plugin/guide-java-plugin-development.md
+++ b/content/markdown/guides/plugin/guide-java-plugin-development.md
@@ -20,58 +20,83 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
+## Introduction
-# Introduction
-This guide is intended to assist users in developing Java plugins for Maven.
+ This guide is intended to assist users in developing Java plugins for Maven.
-<!-- TODO replace by TOC macro after https://issues.apache.org/jira/browse/DOXIA-696 -->
-- [Important Notice: Plugin Naming Convention and Apache Maven Trademark](#important-notice-plugin-naming-convention-and-apache-maven-trade)
-- [Your First Plugin](#your-first-plugin)
- - [Your First Mojo](#your-first-mojo)
- - [A Simple Mojo](#a-simple-mojo)
- - [Project Definition](#project-definition)
- - [Building a Plugin](#building-a-plugin)
-- [Executing Your First Mojo](#executing-your-first-mojo)
- - [Shortening the Command Line](#shortening-the-command-line)
- - [Attaching the Mojo to the Build Lifecycle](#attaching-the-mojo-to-the-build-lifecycle)
-- [Mojo archetype](#mojo-archetype)
-- [Parameters](#parameters)
- - [Defining Parameters Within a Mojo](#defining-parameters-within-a-mojo)
- - [Configuring Parameters in a Project](#configuring-parameters-in-a-project)
-- [Using Setters](#using-setters)
-- [Resources](#resources)
-## Important Notice: [Plugin Naming Convention and Apache Maven Trademark](../mini/guide-naming-conventions.html)
+ - [Important Notice: Plugin Naming Convention and Apache Maven Trademark](Important_Notice:_Plugin_Naming_Convention_and_Apache_Maven_Trademark)
-You will typically name your plugin `<yourplugin>-maven-plugin`.
+ - [Your First Plugin](Your_First_Plugin)
-Calling it `maven-<yourplugin>-plugin` (note "Maven" is at the beginning of the plugin name)
-is **strongly discouraged** since it's a **reserved naming pattern for official Apache Maven plugins maintained by the Apache Maven team**
-with groupId `org.apache.maven.plugins`.
+ - [Your First Mojo](Your_First_Mojo)
-Using this naming pattern is an infringement of the Apache Maven Trademark.
+ - [A Simple Mojo](A_Simple_Mojo)
-## Your First Plugin
-In this section we will build a simple plugin with one goal which takes no parameters and simply displays a message on the screen when run.
-Along the way, we will cover the basics of setting up a project to create a plugin, the minimal contents of a Java mojo which will define goal code,
-and a couple ways to execute the mojo.
-### Your First Mojo
+ - [Project Definition](Project_Definition)
-At its simplest, a Java mojo consists simply of a single class representing one plugin's goal.
-There is no requirement for multiple classes like EJBs, although a plugin which contains a number of similar mojos is likely to use an abstract superclass
-for the mojos to consolidate code common to all mojos.
+ - [Building a Plugin](Building_a_Plugin)
-When processing the source tree to find mojos, [`plugin-tools`](/plugin-tools/) looks for classes with either `@Mojo` annotation.
-Any class with this annotation are included in the plugin configuration file.
+ - [Executing Your First Mojo](Executing_Your_First_Mojo)
+
+ - [Shortening the Command Line](Shortening_the_Command_Line)
+
+ - [Attaching the Mojo to the Build Lifecycle](Attaching_the_Mojo_to_the_Build_Lifecycle)
+
+
+
+
+
+ - [Mojo archetype](Mojo_archetype)
+
+ - [Parameters](Parameters)
+
+ - [Defining Parameters Within a Mojo](Defining_Parameters_Within_a_Mojo)
+
+ - [Configuring Parameters in a Project](Configuring_Parameters_in_a_Project)
+
+
+
+ - [Using Setters](Using_Setters)
+
+ - [Resources](Resources)
+
+
+### Important Notice: [Plugin Naming Convention and Apache Maven Trademark](../mini/guide-naming-conventions.html)
+
+
+ You will typically name your plugin `<yourplugin>-maven-plugin`.
+
+
+ Calling it `maven-<yourplugin>-plugin` (note "Maven" is at the beginning of the plugin name) is **strongly discouraged** since it's a **reserved naming pattern for official Apache Maven plugins maintained by the Apache Maven team** with groupId `org.apache.maven.plugins`. Using this naming pattern is an infringement of the Apache Maven Trademark.
+
+
+
+### Your First Plugin
+
+
+ In this section we will build a simple plugin with one goal which takes no parameters and simply displays a message on the screen when run. Along the way, we will cover the basics of setting up a project to create a plugin, the minimal contents of a Java mojo which will define goal code, and a couple ways to execute the mojo.
+
+
+#### Your First Mojo
+
+
+ At its simplest, a Java mojo consists simply of a single class representing one plugin's goal. There is no requirement for multiple classes like EJBs, although a plugin which contains a number of similar mojos is likely to use an abstract superclass for the mojos to consolidate code common to all mojos.
+
+
+ When processing the source tree to find mojos, [ `plugin-tools`](/plugin-tools/) looks for classes with either `@Mojo` Java 5 annotation or "`goal`" javadoc annotation. Any class with this annotation are included in the plugin configuration file.
+
+
+##### A Simple Mojo
+
+
+ Listed below is a simple mojo class which has no parameters. This is about as simple as a mojo can be. After the listing is a description of the various parts of the source.
-### A Simple Mojo
-Listed below is a simple mojo class which has no parameters. This is about as simple as a mojo can be.
-After the listing is a description of the various parts of the source.
```
package sample.plugin;
@@ -84,37 +109,53 @@ import org.apache.maven.plugins.annotations.Mojo;
* Says "Hi" to the user.
*
*/
-@Mojo(name = "sayhi")
-public class GreetingMojo extends AbstractMojo {
-
- public void execute() throws MojoExecutionException {
+@Mojo( name = "sayhi")
+public class GreetingMojo extends AbstractMojo
+{
+ public void execute() throws MojoExecutionException
+ {
getLog().info( "Hello, world." );
}
}
```
-- The class `org.apache.maven.plugin.AbstractMojo` provides most of the infrastructure required to implement a mojo except for the `execute` method.
-- The annotation "`@Mojo`" is required and control how and when the mojo is executed.
-- The `execute` method can throw an exception:
- - `org.apache.maven.plugin.MojoExecutionException` if an unexpected problem occurs. Throwing this exception causes a "BUILD FAILURE" message to be displayed.
-- The `getLog` method (defined in `AbstractMojo`) returns a log4j-like logger object which allows plugins to create messages at levels of "debug", "info", "warn", and "error".
- This logger is the accepted means to display information to the user. Please have a look at the section [Retrieving the Mojo Logger](../../plugin-developers/common-bugs.html#retrieving-the-mojo-logger) for a hint on its proper usage.
-All Mojo annotations are described by the [Mojo API Specification](../../developers/mojo-api-specification.html#The_Descriptor_and_Annotations).
+ - The class `org.apache.maven.plugin.AbstractMojo` provides most of the infrastructure required to implement a mojo except for the `execute` method.
+
+ - The annotation "`@Mojo`" is required and control how and when the mojo is executed.
+
+ - The `execute` method can throw two exceptions:
+
+ - `org.apache.maven.plugin.MojoExecutionException` if an unexpected problem occurs. Throwing this exception causes a "BUILD ERROR" message to be displayed.
+
+ - `org.apache.maven.plugin.MojoFailureException` if an expected problem (such as a compilation failure) occurs. Throwing this exception causes a "BUILD FAILURE" message to be displayed.
+
+
+
+ - The `getLog` method (defined in `AbstractMojo`) returns a log4j-like logger object which allows plugins to create messages at levels of "debug", "info", "warn", and "error". This logger is the accepted means to display information to the user. Please have a look at the section [Retrieving the Mojo Logger](../../plugin-developers/common-bugs.html#Retrieving_the_Mojo_Logger) for a hint on its proper usage.
+
+
+ All Mojo annotations are described by the [Mojo API Specification](../../developers/mojo-api-specification.html#The_Descriptor_and_Annotations).
+
+
+
-### Project Definition
+#### Project Definition
-Once the mojos have been written for the plugin, it is time to build the plugin. To do this properly, the project's descriptor needs to have a number of settings set properly:
-| | |
-|----------------|-------------------------------------------------------------------------------------------------------------|
-| `groupId` | This is the group ID for the plugin, and should match the common prefix to the packages used by the mojos |
-| `artifactId` | This is the name of the plugin |
-| `version` | This is the version of the plugin |
-| `packaging` | This must be set to "`maven-plugin`" |
-| `dependencies` | A dependency must be declared to the Maven Plugin Tools API to resolve "`AbstractMojo`" and related classes |
+ Once the mojos have been written for the plugin, it is time to build the plugin. To do this properly, the project's descriptor needs to have a number of settings set properly:
+
+
+|`groupId`|This is the group ID for the plugin, and should match the common prefix to the packages used by the mojos|
+|---|---|
+|`artifactId`|This is the name of the plugin|
+|`version`|This is the version of the plugin|
+|`packaging`|This should be set to "`maven-plugin`"|
+|`dependencies`|A dependency must be declared to the Maven Plugin Tools API to resolve "`AbstractMojo`" and related classes|
+
+ Listed below is an illustration of the sample mojo project's pom with the parameters set as described in the above table:
+
-Listed below is an illustration of the sample mojo project's pom with the parameters set as described in the above table:
```
<project>
@@ -126,11 +167,7 @@ Listed below is an illustration of the sample mojo project's pom with the parame
<packaging>maven-plugin</packaging>
<name>Sample Parameter-less Maven Plugin</name>
-
- <properties>
- <maven-plugin-tools.version>3.7.1</maven-plugin-tools.version>
- </properties>
-
+
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
@@ -143,54 +180,40 @@ Listed below is an illustration of the sample mojo project's pom with the parame
<dependency>
<groupId>org.apache.maven.plugin-tools</groupId>
<artifactId>maven-plugin-annotations</artifactId>
- <version>${maven-plugin-tools.version}</version>
+ <version>3.4</version>
<scope>provided</scope>
</dependency>
</dependencies>
-
- <build>
- <pluginManagement>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-plugin-plugin</artifactId>
- <version>${maven-plugin-tools.version}</version>
- <executions>
- <execution>
- <id>help-mojo</id>
- <goals>
- <!-- good practice is to generate help mojo for plugin -->
- <goal>helpmojo</goal>
- </goals>
- </execution>
- </executions>
- </plugin>
- </pluginManagement>
- </build>
</project>
```
-### Building a Plugin
-There are few plugins goals bound to the standard build lifecycle defined with the `maven-plugin` packaging:
+#### Building a Plugin
+
+
+ There are few plugins goals bound to the standard build lifecycle defined with the `maven-plugin` packaging:
+
+
+|`compile`|Compiles the Java code for the plugin|
+|---|---|
+|`process-classes`|Extracts data to build the [plugin descriptor](/ref/current/maven-plugin-api/plugin.html)|
+|`test`|Runs the plugin's unit tests|
+|`package`|Builds the plugin jar|
+|`install`|Installs the plugin jar in the local repository|
+|`deploy`|Deploys the plugin jar to the remote repository|
+
+ For more details, you can look at [ detailed bindings for `maven-plugin` packaging](/ref/current/maven-core/default-bindings.html#Plugin_bindings_for_maven-plugin_packaging).
+
-| | |
-|-------------------|-------------------------------------------------------------------------------------------|
-| `compile` | Compiles the Java code for the plugin |
-| `process-classes` | Extracts data to build the [plugin descriptor](/ref/current/maven-plugin-api/plugin.html) |
-| `test` | Runs the plugin's unit tests |
-| `package` | Builds the plugin jar |
-| `install` | Installs the plugin jar in the local repository |
-| `deploy` | Deploys the plugin jar to the remote repository |
-For more details, you can look at [detailed bindings for `maven-plugin` packaging](/ref/current/maven-core/default-bindings.html#Plugin_bindings_for_maven-plugin_packaging).
+#### Executing Your First Mojo
+
+
+ The most direct means of executing your new plugin is to specify the plugin goal directly on the command line. To do this, you need to configure the `hello-maven-plugin` plugin in you project:
-## Executing Your First Mojo
-The most direct means of executing your new plugin is to specify the plugin goal directly on the command line.
-To do this, you need to configure the `hello-maven-plugin` plugin in you project:
```
-<project>
...
<build>
<pluginManagement>
@@ -204,31 +227,34 @@ To do this, you need to configure the `hello-maven-plugin` plugin in you project
</pluginManagement>
</build>
...
-</project>
```
-And, you need to specify a fully-qualified goal in the form of:
+ And, you need to specify a fully-qualified goal in the form of:
+
+
```
mvn groupId:artifactId:version:goal
```
-For example, to run the simple mojo in the sample plugin, you would enter "`mvn sample.plugin:hello-maven-plugin:1.0-SNAPSHOT:sayhi`" on the command line.
+ For example, to run the simple mojo in the sample plugin, you would enter "`mvn sample.plugin:hello-maven-plugin:1.0-SNAPSHOT:sayhi`" on the command line.
+
+
+ **Tips**: `version` is not required to run a standalone goal.
-**Tips**: `version` is not required to run a standalone goal.
-### Shortening the Command Line
+##### Shortening the Command Line
-There are several ways to reduce the amount of required typing:
-- If you need to run the latest version of a plugin installed in your local repository, you can omit its version number.
- So just use "`mvn sample.plugin:hello-maven-plugin:sayhi`" to run your plugin.
-- You can assign a shortened prefix to your plugin, such as `mvn hello:sayhi`.
- This is done automatically if you follow the convention of using `${prefix}-maven-plugin`
- (or `maven-${prefix}-plugin` if the plugin is part of the Apache Maven project).
- You may also assign one through additional configuration - for more information see [ Introduction to Plugin Prefix Mapping](../introduction/introduction-to-plugin-prefix-mapping.html).
-- Finally, you can also add your plugin's groupId to the list of groupIds searched by default.
- To do this, you need to add the following to your `${user.home}/.m2/settings.xml` file:
+ There are several ways to reduce the amount of required typing:
+
+
+
+ - If you need to run the latest version of a plugin installed in your local repository, you can omit its version number. So just use "`mvn sample.plugin:hello-maven-plugin:sayhi`" to run your plugin.
+
+ - You can assign a shortened prefix to your plugin, such as `mvn hello:sayhi`. This is done automatically if you follow the convention of using `${prefix}-maven-plugin` (or `maven-${prefix}-plugin` if the plugin is part of the Apache Maven project). You may also assign one through additional configuration - for more information see [ Introduction to Plugin Prefix Mapping](../introduction/introduction-to-plugin-prefix-mapping.html).
+
+ - Finally, you can also add your plugin's groupId to the list of groupIds searched by default. To do this, you need to add the following to your `${user.home}/.m2/settings.xml` file:
```
<pluginGroups>
@@ -236,11 +262,18 @@ There are several ways to reduce the amount of required typing:
</pluginGroups>
```
-At this point, you can run the mojo with `mvn hello:sayhi`.
-### Attaching the Mojo to the Build Lifecycle
-You can also configure your plugin to attach specific goals to a particular phase of the build lifecycle. Here is an example:
+ At this point, you can run the mojo with "`mvn hello:sayhi`".
+
+
+
+##### Attaching the Mojo to the Build Lifecycle
+
+
+ You can also configure your plugin to attach specific goals to a particular phase of the build lifecycle. Here is an example:
+
+
```
<build>
@@ -270,11 +303,18 @@ You can also configure your plugin to attach specific goals to a particular phas
</build>
```
-This causes the simple mojo to be executed whenever Java code is compiled. For more information on binding a mojo to phases in the lifecycle, please refer to the [Build Lifecycle](../introduction/introduction-to-the-lifecycle.html) document.
+ This causes the simple mojo to be executed whenever Java code is compiled. For more information on binding a mojo to phases in the lifecycle, please refer to the [Build Lifecycle](../introduction/introduction-to-the-lifecycle.html) document.
+
+
+
+
+
+### Mojo archetype
+
+
+ To create a new plugin project, you could using the Mojo [archetype](../introduction/introduction-to-archetypes.html) with the following command line:
-## Mojo archetype
-To create a new plugin project, you could using the Mojo [archetype](../introduction/introduction-to-archetypes.html) with the following command line:
```
mvn archetype:generate \
@@ -284,17 +324,25 @@ mvn archetype:generate \
-DarchetypeArtifactId=maven-archetype-plugin
```
-## Parameters
-It is unlikely that a mojo will be very useful without parameters. Parameters provide a few very important functions:
+### Parameters
+
+
+ It is unlikely that a mojo will be very useful without parameters. Parameters provide a few very important functions:
+
+
-- It provides hooks to allow the user to adjust the operation of the plugin to suit their needs.
-- It provides a means to easily extract the value of elements from the POM without the need to navigate the objects.
+ - It provides hooks to allow the user to adjust the operation of the plugin to suit their needs.
+
+ - It provides a means to easily extract the value of elements from the POM without the need to navigate the objects.
+
+
+#### Defining Parameters Within a Mojo
+
+
+ Defining a parameter is as simple as creating an instance variable in the mojo and adding the proper annotations. Listed below is an example of a parameter for the simple mojo:
-### Defining Parameters Within a Mojo
-Defining a parameter is as simple as creating an instance variable in the mojo and adding the proper annotations.
-Listed below is an example of a parameter for the simple mojo:
```
/**
@@ -304,20 +352,16 @@ Listed below is an example of a parameter for the simple mojo:
private String greeting;
```
-The portion before the annotations is the description of the parameter.
+ The portion before the annotations is the description of the parameter. The `parameter` annotation identifies the variable as a mojo parameter. The `defaultValue` parameter of the annotation defines the default value for the variable. This value can include expressions which reference the project, such as "`${project.version}`" (more can be found in the ["Parameter Expressions" document](/ref/current/maven-core/apidocs/org/apache/maven/plugin/PluginParameterExpressionEvaluator.html)). T [...]
+
-The `@Parameter` annotation identifies the variable as a mojo parameter.
-The `defaultValue` parameter of the annotation defines the default value for the variable.
-This value can include expressions which reference the project, such as "`${project.version}`"
-(more can be found in the ["Parameter Expressions" document](/ref/current/maven-core/apidocs/org/apache/maven/plugin/PluginParameterExpressionEvaluator.html)).
+#### Configuring Parameters in a Project
-The `property` parameter can be used to allow configuration of the mojo parameter from the command line by referencing a property that the user sets via the `-D` option.
-### Configuring Parameters in a Project
+ Configuring the parameter values for a plugin is done in a Maven project within the `pom.xml` file as part of defining the plugin in the project. An example of configuring a plugin:
+
-Configuring the parameter values for a plugin is done in a Maven project within the `pom.xml` file as part of defining the plugin in the project.
-An example of configuring a plugin:
```
<plugin>
@@ -330,67 +374,78 @@ An example of configuring a plugin:
</plugin>
```
-In the configuration section, the element name ("`greeting`") is the parameter name and the contents of the element ("`Welcome`") is the value to be assigned to the parameter.
+ In the configuration section, the element name ("`greeting`") is the parameter name and the contents of the element ("`Welcome`") is the value to be assigned to the parameter.
-**Note**: More details can be found in the [Guide to Configuring Plugins](../mini/guide-configuring-plugins.html).
-## Using Setters
+ **Note**: More details can be found in the [Guide to Configuring Plugins](../mini/guide-configuring-plugins.html).
-You are not restricted to using private field mapping which is good if you are trying to make you Mojos reusable outside the context of Maven.
-Using the example above we could define public setters methods that the configuration mapping mechanism can use.
-You can also add `@Parameter` annotation on setter method (from version 3.7.0 of `plugin-tools`)
-So our Mojo would look like the following:
+### Using Setters
-```
-public class MyQueryMojo extends AbstractMojo {
+ You are not restricted to using private field mapping which is good if you are trying to make you Mojos resuable outside the context of Maven. Using the example above we could name our private fields using the underscore convention and provide setters that the configuration mapping mechanism can use. So our Mojo would look like the following:
- // provide name for non matching field and setter name
- @Parameter(name="url", property="url")
+
+
+```
+
+public class MyQueryMojo
+ extends AbstractMojo
+{
+ @Parameter(property="url")
private String _url;
@Parameter(property="timeout")
- private int timeout;
+ private int _timeout;
- private String option0;
- private String option1;
+ @Parameter(property="options")
+ private String[] _options;
- public void setUrl(String url) {
+ public void setUrl( String url )
+ {
_url = url;
}
- public void setTimeout(int timeout) {
- this.timeout = timeout;
+ public void setTimeout( int timeout )
+ {
+ _timeout = timeout;
}
- @Parameter(property="options")
- public void setOptions(String[] options) {
- // we can do something more with provided parameter
- this.option0 = options[0];
- this.option1 = options[1];
+ public void setOptions( String[] options )
+ {
+ _options = options;
}
- public void execute() throws MojoExecutionException {
+ public void execute()
+ throws MojoExecutionException
+ {
...
}
}
```
-Note the specification of the property name for each parameter which tells Maven
-what setter and getter to use when the field's name does not match the intended name of the parameter in the plugin configuration.
+ Note the specification of the property name for each parameter which tells Maven what setter and getter to use when the field's name does not match the intended name of the parameter in the plugin configuration.
+
+
+
+### Resources
+
+
+
+ 1 [Mojo Documentation](../../developers/mojo-api-specification.html): Mojo API, Mojo annotations
+
+ 1 [Maven Plugin Testing Harness](/shared/maven-plugin-testing-harness/): Testing framework for your Mojos.
+
+ 1 [Plexus](https://codehaus-plexus.github.io/): The IoC container used by Maven.
+
+ 1 [Plexus Common Utilities](https://codehaus-plexus.github.io/plexus-utils/): Set of utilities classes useful for Mojo development.
-## Resources
+ 1 [Commons IO](http://commons.apache.org/io/): Set of utilities classes useful for file/path handling.
-1. [Mojo Documentation](../../developers/mojo-api-specification.html): Mojo API, Mojo annotations
-2. [Maven Plugin Testing Harness](/shared/maven-plugin-testing-harness/): Testing framework for your Mojos.
-3. [Plexus](https://codehaus-plexus.github.io/): The IoC container used by Maven.
-4. [Plexus Common Utilities](https://codehaus-plexus.github.io/plexus-utils/): Set of utilities classes useful for Mojo development.
-5. [Commons IO](http://commons.apache.org/io/): Set of utilities classes useful for file/path handling.
-6. [Common Bugs and Pitfalls](../../plugin-developers/common-bugs.html): Overview of problematic coding patterns.
+ 1 [Common Bugs and Pitfalls](../../plugin-developers/common-bugs.html): Overview of problematic coding patterns.
[maven-site] 14/14: Revert "[MNGSITE-507] Converted .apt documents to Markdown"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit 656d36f2aadcd348f469c73bd3faff5f71bae413
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:35:38 2023 +0100
Revert "[MNGSITE-507] Converted .apt documents to Markdown"
This reverts commit 394bf48a
---
content/apt/archives/maven-2.x/index.apt | 48 +
.../maven-2.x/maven-2.1-architectural-goals.apt} | 0
content/apt/developers/committer-environment.apt | 54 +
content/apt/developers/committer-settings.apt | 81 ++
content/apt/developers/compatibility-plan.apt | 77 ++
content/apt/developers/conventions/code.apt | 246 ++++
content/apt/developers/conventions/git.apt | 228 ++++
content/apt/developers/dependency-policies.apt | 78 ++
content/apt/developers/index.apt | 115 ++
content/apt/developers/release/index.apt | 48 +
.../release/maven-project-release-procedure.apt | 328 +++++
.../apt/developers/release/parent-pom-release.apt | 101 ++
.../developers/release/pmc-gpg-keys.apt} | 152 +--
content/apt/developers/retirement-plan-plugins.apt | 166 +++
.../deploy-component-reference-documentation.apt | 165 +++
.../developers/website/deploy-maven-website.apt | 117 ++
content/apt/developers/website/index.apt | 74 ++
.../apt/developers/website/website-overview.apt | 43 +
.../developers/website/website-overview.odg | Bin
.../apt/developers/welcome-to-new-committers.apt | 70 ++
content/apt/examples/index.apt | 35 +
.../examples/injecting-properties-via-settings.apt | 84 ++
.../guides/development/guide-building-maven.apt | 92 ++
.../guides/development/guide-committer-school.apt | 157 +++
.../development/guide-documentation-style.apt | 136 +++
content/apt/guides/development/guide-helping.apt | 106 ++
.../guides/development/guide-maven-development.apt | 197 +++
.../development/guide-plugin-documentation.apt | 410 +++++++
.../guide-testing-development-plugins.apt | 141 +++
.../guides/development/guide-testing-releases.apt | 153 +++
content/apt/guides/getting-started/index.apt | 1241 +++++++++++++++++++
.../getting-started/maven-in-five-minutes.apt | 294 +++++
.../getting-started/windows-prerequisites.apt | 66 ++
.../introduction/introduction-to-archetypes.apt | 102 ++
.../introduction-to-dependency-mechanism.apt | 876 ++++++++++++++
...ction-to-optional-and-excludes-dependencies.apt | 320 +++++
.../introduction-to-plugin-prefix-mapping.apt | 167 +++
.../introduction/introduction-to-plugins.apt | 87 ++
.../introduction/introduction-to-profiles.apt | 816 +++++++++++++
.../introduction/introduction-to-repositories.apt | 167 +++
.../introduction/introduction-to-the-lifecycle.apt | 483 ++++++++
.../introduction/introduction-to-the-pom.apt | 577 +++++++++
...troduction-to-the-standard-directory-layout.apt | 86 ++
.../apt/guides/mini/guide-3rd-party-jars-local.apt | 59 +
.../guides/mini/guide-3rd-party-jars-remote.apt | 87 ++
.../guides/mini/guide-archive-configuration.apt | 71 ++
.../guides/mini/guide-assemblies.apt} | 118 +-
.../guides/mini/guide-attached-tests.apt} | 81 +-
.../apt/guides/mini/guide-bash-m2-completion.apt | 37 +
.../guide-building-for-different-environments.apt | 161 +++
.../apt/guides/mini/guide-configuring-maven.apt | 171 +++
.../apt/guides/mini/guide-configuring-plugins.apt | 752 ++++++++++++
.../apt/guides/mini/guide-creating-archetypes.apt | 242 ++++
.../guides/mini/guide-default-execution-ids.apt | 218 ++++
.../mini/guide-deployment-security-settings.apt | 66 ++
content/apt/guides/mini/guide-encryption.apt | 258 ++++
.../apt/guides/mini/guide-generating-sources.apt | 77 ++
content/apt/guides/mini/guide-http-settings.apt | 528 +++++++++
.../guide-large-scale-centralized-deployments.apt | 243 ++++
content/apt/guides/mini/guide-manifest.apt | 44 +
.../apt/guides/mini/guide-maven-classloading.apt | 154 +++
content/apt/guides/mini/guide-mirror-settings.apt | 178 +++
content/apt/guides/mini/guide-multiple-modules.apt | 88 ++
.../guides/mini/guide-multiple-repositories.apt | 136 +++
.../apt/guides/mini/guide-naming-conventions.apt | 63 +
content/apt/guides/mini/guide-new-committers.apt | 45 +
content/apt/guides/mini/guide-proxies.apt | 69 ++
content/apt/guides/mini/guide-releasing.apt | 311 +++++
content/apt/guides/mini/guide-relocation.apt | 151 +++
content/apt/guides/mini/guide-repository-ssl.apt | 155 +++
.../apt/guides/mini/guide-reproducible-builds.apt | 171 +++
content/apt/guides/mini/guide-site.apt | 348 ++++++
content/apt/guides/mini/guide-snippet-macro.apt | 116 ++
.../guides/mini/guide-using-ant.apt} | 73 +-
content/apt/guides/mini/guide-using-extensions.apt | 110 ++
content/apt/guides/mini/guide-using-modello.apt | 90 ++
.../mini/guide-using-one-source-directory.apt | 194 +++
content/apt/guides/mini/guide-using-toolchains.apt | 179 +++
content/apt/guides/mini/guide-wagon-providers.apt | 95 ++
.../plugin/guide-java-plugin-development.apt | 436 +++++++
.../guide-java-report-plugin-development.apt | 539 +++++++++
content/apt/maven-features.apt | 80 ++
content/apt/plugin-developers/common-bugs.apt | 457 +++++++
content/apt/plugin-developers/cookbook/index.apt | 38 +
.../cookbook/plexus-plugin-upgrade.apt | 189 +++
content/apt/plugin-developers/index.apt | 79 ++
.../apt/plugin-developers/plugin-documenting.apt | 46 +
content/apt/plugin-developers/plugin-testing.apt | 163 +++
content/apt/plugins/index.apt | 276 +++++
content/apt/plugins/localization.apt | 193 +++
content/apt/repository/central-index.apt | 64 +
content/apt/repository/central-metadata.apt | 58 +
.../repository/guide-central-repository-upload.apt | 190 +++
content/apt/run-maven/index.apt | 106 ++
content/apt/shared/index.apt | 85 ++
content/apt/skins/index.apt | 89 ++
content/apt/users/getting-help.apt | 111 ++
content/apt/users/index.apt | 53 +
content/markdown/archives/maven-2.x/index.md | 36 -
.../markdown/developers/committer-environment.md | 60 -
content/markdown/developers/committer-settings.md | 85 --
content/markdown/developers/compatibility-plan.md | 84 --
content/markdown/developers/conventions/code.md | 298 -----
content/markdown/developers/conventions/git.md | 252 ----
content/markdown/developers/dependency-policies.md | 82 --
content/markdown/developers/index.md | 125 --
content/markdown/developers/release/index.md | 47 -
.../release/maven-project-release-procedure.md | 368 ------
.../developers/release/parent-pom-release.md | 111 --
.../markdown/developers/retirement-plan-plugins.md | 157 ---
.../deploy-component-reference-documentation.md | 174 ---
.../developers/website/deploy-maven-website.md | 121 --
content/markdown/developers/website/index.md | 67 --
.../developers/website/website-overview.md | 38 -
.../developers/welcome-to-new-committers.md | 66 --
content/markdown/docs/3.2.1/release-notes.md | 3 +
content/markdown/docs/3.2.2/release-notes.md | 3 +
content/markdown/docs/3.2.3/release-notes.md | 3 +
content/markdown/docs/3.2.5/release-notes.md | 3 +
content/markdown/docs/3.3.1/release-notes.md | 3 +
content/markdown/docs/3.3.3/release-notes.md | 3 +
content/markdown/docs/3.3.9/release-notes.md | 3 +
.../markdown/docs/3.5.0-alpha-1/release-notes.md | 3 +
.../markdown/docs/3.5.0-beta-1/release-notes.md | 3 +
content/markdown/docs/3.5.0/release-notes.md | 3 +
content/markdown/docs/3.5.2/release-notes.md | 3 +
content/markdown/docs/3.5.3/release-notes.md | 3 +
content/markdown/docs/3.5.4/release-notes.md | 3 +
content/markdown/docs/3.6.0/release-notes.md | 3 +
content/markdown/docs/3.6.1/release-notes.md | 3 +
content/markdown/docs/3.6.2/release-notes.md | 3 +
content/markdown/docs/3.6.3/release-notes.md | 3 +
content/markdown/docs/3.8.1/release-notes.md | 3 +
content/markdown/docs/3.8.2/release-notes.md | 3 +
content/markdown/docs/3.8.3/release-notes.md | 3 +
content/markdown/docs/3.8.4/release-notes.md | 3 +
content/markdown/docs/3.8.5/release-notes.md | 3 +
content/markdown/docs/3.8.6/release-notes.md | 3 +
content/markdown/docs/3.8.7/release-notes.md | 3 +
content/markdown/docs/3.9.0/release-notes.md | 3 +
.../markdown/docs/4.0.0-alpha-2/release-notes.md | 3 +
.../markdown/docs/4.0.0-alpha-3/release-notes.md | 3 +
.../markdown/docs/4.0.0-alpha-4/release-notes.md | 3 +
content/markdown/docs/history.md.vm | 3 +
content/markdown/examples/index.md | 30 -
.../examples/injecting-properties-via-settings.md | 84 --
.../guides/development/guide-building-maven.md | 115 --
.../guides/development/guide-committer-school.md | 174 ---
.../development/guide-documentation-style.md | 146 ---
.../markdown/guides/development/guide-helping.md | 107 --
.../guides/development/guide-maven-development.md | 206 ----
.../development/guide-plugin-documentation.md | 481 --------
.../guide-testing-development-plugins.md | 157 ---
.../guides/development/guide-testing-releases.md | 164 ---
content/markdown/guides/getting-started/index.md | 1252 --------------------
.../getting-started/maven-in-five-minutes.md | 314 -----
.../getting-started/windows-prerequisites.md | 67 --
.../introduction/introduction-to-archetypes.md | 84 --
.../introduction-to-dependency-mechanism.md | 840 -------------
...uction-to-optional-and-excludes-dependencies.md | 290 -----
.../introduction-to-plugin-prefix-mapping.md | 144 ---
.../guides/introduction/introduction-to-plugins.md | 69 --
.../introduction/introduction-to-profiles.md | 835 -------------
.../introduction/introduction-to-repositories.md | 170 ---
.../introduction/introduction-to-the-lifecycle.md | 430 -------
.../guides/introduction/introduction-to-the-pom.md | 660 -----------
...ntroduction-to-the-standard-directory-layout.md | 65 -
.../guides/mini/guide-3rd-party-jars-local.md | 56 -
.../guides/mini/guide-3rd-party-jars-remote.md | 88 --
.../guides/mini/guide-archive-configuration.md | 70 --
.../guides/mini/guide-bash-m2-completion.md | 29 -
.../guide-building-for-different-environments.md | 162 ---
.../guides/mini/guide-configuring-maven.md | 190 ---
.../guides/mini/guide-configuring-plugins.md | 795 -------------
.../guides/mini/guide-creating-archetypes.md | 237 ----
.../guides/mini/guide-default-execution-ids.md | 198 ----
.../mini/guide-deployment-security-settings.md | 64 -
content/markdown/guides/mini/guide-encryption.md | 299 -----
.../guides/mini/guide-generating-sources.md | 62 -
.../markdown/guides/mini/guide-http-settings.md | 573 ---------
.../guide-large-scale-centralized-deployments.md | 240 ----
content/markdown/guides/mini/guide-manifest.md | 36 -
.../guides/mini/guide-maven-classloading.md | 168 ---
.../markdown/guides/mini/guide-mirror-settings.md | 172 ---
.../markdown/guides/mini/guide-multiple-modules.md | 106 --
.../guides/mini/guide-multiple-repositories.md | 141 ---
.../guides/mini/guide-naming-conventions.md | 57 -
.../markdown/guides/mini/guide-new-committers.md | 37 -
content/markdown/guides/mini/guide-proxies.md | 68 --
content/markdown/guides/mini/guide-releasing.md | 323 -----
content/markdown/guides/mini/guide-relocation.md | 135 ---
.../markdown/guides/mini/guide-repository-ssl.md | 156 ---
.../guides/mini/guide-reproducible-builds.md | 178 ---
content/markdown/guides/mini/guide-site.md | 369 ------
.../markdown/guides/mini/guide-snippet-macro.md | 123 --
.../markdown/guides/mini/guide-using-extensions.md | 112 --
.../markdown/guides/mini/guide-using-modello.md | 312 -----
.../mini/guide-using-one-source-directory.md | 211 ----
.../markdown/guides/mini/guide-using-toolchains.md | 162 ---
.../markdown/guides/mini/guide-wagon-providers.md | 93 --
.../guides/plugin/guide-java-plugin-development.md | 451 -------
.../plugin/guide-java-report-plugin-development.md | 544 ---------
content/markdown/maven-features.md | 55 -
content/markdown/plugin-developers/common-bugs.md | 409 -------
.../markdown/plugin-developers/cookbook/index.md | 34 -
.../cookbook/plexus-plugin-upgrade.md | 190 ---
content/markdown/plugin-developers/index.md | 76 --
.../plugin-developers/plugin-documenting.md | 51 -
.../markdown/plugin-developers/plugin-testing.md | 187 ---
content/markdown/plugins/index.md | 185 ---
content/markdown/plugins/localization.md | 165 ---
content/markdown/repository/central-index.md | 58 -
content/markdown/repository/central-metadata.md | 51 -
.../repository/guide-central-repository-upload.md | 191 ---
content/markdown/run-maven/index.md | 110 --
content/markdown/shared/index.md | 56 -
content/markdown/skins/index.md | 78 --
content/markdown/users/getting-help.md | 106 --
content/markdown/users/index.md | 51 -
219 files changed, 18059 insertions(+), 18328 deletions(-)
diff --git a/content/apt/archives/maven-2.x/index.apt b/content/apt/archives/maven-2.x/index.apt
new file mode 100644
index 00000000..c629528a
--- /dev/null
+++ b/content/apt/archives/maven-2.x/index.apt
@@ -0,0 +1,48 @@
+ ---
+ Maven 2 Graveyard
+ ---
+ Karl-Heinz Marbaise
+ ---
+ 2014-03-22
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+
+This is the Maven 2 Graveyard
+
+ Based on a decision for the End Of Lifetime of Maven 2
+ this location is intended as a graveyard for Maven 2 only related information and links.
+
+* Plugin List
+
+ The following list of plugins contains plugins which are Maven 2 specific. Apart from
+ that for those plugins which are listed here there are no updates/bug fixes planned etc.
+
+
+*--------------------------------------------------------------+------------+--------------+------------+------------------+------------------------+
+|| <<Plugin>> || <<Type*>> || <<Version>> || <<Last Release Date>> || <<Description>> || <<Date of Funeral>>
+*--------------------------------------------------------------+------------+--------------+------------+------------------+------------------------+
+| <<Core plugins>> | | | | <<Plugins corresponding to default core phases (ie. clean, compile). They may have multiple goals as well.>>
+*--------------------------------------------------------------+------------+--------------+------------+------------------+------------------------+
+| {{{/plugins/maven-reactor-plugin/} <<<reactor>>>}} | B | 1.0 | 2008-09-27 | Build a subset of interdependent projects in a reactor | 2014-03-24
+*--------------------------------------------------------------+------------+--------------+------------+------------------+------------------------+--------------------+
+
+ \* <<B>>uild or <<R>>eporting plugin
+
+ []
diff --git a/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md b/content/apt/archives/maven-2.x/maven-2.1-architectural-goals.apt
similarity index 100%
rename from content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md
rename to content/apt/archives/maven-2.x/maven-2.1-architectural-goals.apt
diff --git a/content/apt/developers/committer-environment.apt b/content/apt/developers/committer-environment.apt
new file mode 100644
index 00000000..9247e4e1
--- /dev/null
+++ b/content/apt/developers/committer-environment.apt
@@ -0,0 +1,54 @@
+ ------
+ Developers centre - Committer Environment
+ ------
+ Vincent Siveton
+ ------
+ 2006-10-01
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ https://maven.apache.org/doxia/references/apt-format.html
+
+Committer Environment
+
+* Introduction
+
+ This document describes how to set up the Maven committer environment.
+
+* Source File Encoding
+
+ When editing source files, make sure you use the right file encoding. For the Maven project, UTF-8 has been chosen
+ as the default file encoding. UTF-8 is an encoding scheme for the Unicode character set that can encode
+ all characters that Java can handle. The source files should not contain the byte order mark (BOM). There are
+ exceptions to this general rule. For instance, properties files are encoded using ISO-8859-1 as per the JRE API, so
+ please keep this in mind, too.
+
+* Maven Code Style
+
+ Refer to {{{./conventions/code.html}Maven Code Style And Code Conventions}}
+
+* Useful software
+
+ The Maven Team uses assorted software. Here is a partial list:
+
+ * {{{https://www.cygwin.com/}Cygwin}}: collection of free software tools that allow various versions of Microsoft
+ Windows to act somewhat like a Unix system
+
+ * {{{https://www.gnupg.org/}GnuPG}}: GNU Privacy Guard.
diff --git a/content/apt/developers/committer-settings.apt b/content/apt/developers/committer-settings.apt
new file mode 100644
index 00000000..dbe1c629
--- /dev/null
+++ b/content/apt/developers/committer-settings.apt
@@ -0,0 +1,81 @@
+ ------
+ Developers centre - Committer Settings
+ ------
+ Vincent Siveton
+ Dennis Lundberg
+ ------
+ 2011-05-23
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ https://maven.apache.org/doxia/references/apt-format.html
+
+Introduction
+
+ This document is intended to set up the Maven committer settings, i.e. the <<<$\{user.home\}/.m2/settings.xml>>>.
+
+* Enable Apache Servers
+
+ Maven uses several servers configuration to deploy snapshots and releases on the Apache servers.
+ You need to tell to Maven what your Apache username is.
+
+ <<It is highly recommended to use Maven's {{{../guides/mini/guide-encryption.html} password encryption capabilities}} for your passwords>>.
+
++-----+
+<settings>
+ ...
+ <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>
+</settings>
++-----+
+
+* Enable sending announcement e-mails
+
+ To be able to send out announcements of Maven releases you need to add a couple
+ of properties to the <<<apache-release>>> profile.
+
++-----+
+<settings>
+ ...
+ <profiles>
+ <profile>
+ <id>apache-release</id>
+ <properties>
+ <apache.availid> <!-- YOUR APACHE LDAP USERNAME --> </apache.availid>
+ <smtp.host> <!-- YOUR SMTP SERVER --> </smtp.host>
+ </properties>
+ </profile>
+ ...
+ </profiles>
+</settings>
++-----+
diff --git a/content/apt/developers/compatibility-plan.apt b/content/apt/developers/compatibility-plan.apt
new file mode 100644
index 00000000..1fce293f
--- /dev/null
+++ b/content/apt/developers/compatibility-plan.apt
@@ -0,0 +1,77 @@
+ ------
+ Maven Plugins Compatibility Plan
+ ------
+ Hervé Boutemy
+ ------
+ 2020-05-20
+ -------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ https://maven.apache.org/doxia/references/apt-format.html
+
+Maven Plugins Compatibility Plan
+
+* Scope
+
+ This page describes the system requirements plan, which consists of:
+
+ [[1]] minimum <<Java>> runtime prerequisite for Maven plugins, which can be extended to shared components,
+
+ [[2]] minimum <<Maven>> runtime prerequisite for plugins.
+
+ []
+
+ Such requirements are displayed as "System Requirements" in every plugin info report (see {{{/plugins/maven-clean-plugin/plugin-info.html}this example}}).
+
+ Consolidated view for all LATEST plugins release is visible in a {{{https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html}daily generated report}}.
+
+* Maven Plan
+
+ * Until 2012, Maven 2.2.1 + Java 5 prerequisites, with plugins versions in 2.x
+
+ * Since 2012, Maven 3.0 + Java 7 prerequisites, with plugins in 3.x.y
+
+ * Since June 2020, Maven Plugin API used by plugins >= 3.1.0 + Java 8 prerequisites {{{https://s.apache.org/MVN-PLUGIN-MIGRATION-3.1}Technical details}}
+
+ []
+
+* Context
+
+ * Maven core history with Java prerequisite is available in the {{{/docs/history.html}release notes}}
+
+ * JDK/JRE availability dates:
+
+ * Java 5 (2004) is closed source, End of Public Update in 2009
+
+ * Java 6 (2006) is Open Source, maintained at OpenJDK until 2018
+
+ * Java 7 (2011) is Open Source, maintained {{{https://wiki.openjdk.java.net/display/jdk7u}at OpenJDK}} at least until June 2020
+
+ * Java 8 (2014) is Open Source, maintained {{{https://wiki.openjdk.java.net/display/jdk8u}at OpenJDK}} at least until September 2023
+
+ * Java 11 (LTS, 2018) is Open Source, maintained {{{https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u}at OpenJDK}} at least until September 2025
+
+ * see {{{https://javaalmanac.io/jdk/}Java Version Almanac}} for updated JDK releases
+
+ []
+
+ see also {{{https://docs.google.com/document/d/1nFGazvrCvHMZJgFstlbzoHjpAVwv5DEdnaBr_5pKuHo}Java Is Still Free}} for more details
+
+ []
diff --git a/content/apt/developers/conventions/code.apt b/content/apt/developers/conventions/code.apt
new file mode 100644
index 00000000..aca633f8
--- /dev/null
+++ b/content/apt/developers/conventions/code.apt
@@ -0,0 +1,246 @@
+ ------
+ Maven Code Style And Code Conventions
+ ------
+ Vincent Siveton
+ ------
+ 2008-07-05
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ https://maven.apache.org/doxia/references/apt-format.html
+
+Maven Code Style And Code Conventions
+
+ This document describes the rules for how the sources should be formatted
+ in order to improve consistency, readability and maintainability.
+
+ As the formatting is automatically enforced or even applied with {{{https://github.com/diffplug/spotless/tree/main/plugin-maven}spotless-maven-plugin}} for all projects
+ using {{{/pom/maven/index.html}Maven Project Parent POM 38 or newer}} developers usually don't need to care and the following sections are just for informational purposes.
+
+ Optionally you can still import the code style formatter for your IDE from
+ {{{https://gitbox.apache.org/repos/asf?p=maven-shared-resources.git;a=tree;f=src/main/resources/config;hb=HEAD}shared-resources}}
+
+%{toc|section=1|fromDepth=2|toDepth=3}
+
+* Generic Code Style And Convention
+
+ All working files (java, xml, others) should respect the following conventions:
+
+ * <<License Header>>: Always add the current {{{https://www.apache.org/legal/src-headers.html#headers}ASF license header}}
+ in all files checked into the source code repository.
+
+ * <<Trailing Whitespace>>: No trailing whitespaces allowed.
+
+ []
+
+ and the following style:
+
+ * <<Indentation>>: <<Never>> use tabs!
+
+ * <<Line wrapping>>: Always use a 120-column line width.
+
+ []
+
+ <<Note>>: The specific styles and conventions, listed in the next sections, can override these generic rules.
+
+* {Java}
+
+** {Java Code Style}
+
+ Maven adopts the {{{https://github.com/palantir/palantir-java-format}palantir Java format}}.
+
+
+** {Java Code Convention}
+
+ For consistency reasons, our Java code convention is mainly:
+
+ * <<Naming>>: Constants (i.e. static final members) should always be in upper case.
+ Use short, descriptive names for classes and methods.
+
+ * <<Organization>>: Avoid using public inner classes. Prefer interfaces instead of default implementation.
+
+ * <<Modifier>>: Avoid using final modifier on all fields and arguments.
+ Prefer using private or protected fields instead of public fields.
+
+ * <<Exceptions>>: Throw meaningful exceptions to make debugging and testing easier.
+
+ * <<Documentation>>: Document public interfaces well, i.e. all non-trivial public and
+ protected functions should include Javadoc that indicates what they do.
+
+ * <<Testing>>: All non-trivial public classes should have corresponding unit or
+ integration tests.
+
+ []
+
+** {Java Code Convention - import layouts}
+
+ For consistency reasons, Java imports should be organized as:
+
+ * import <<javax.*>>
+
+ * import <<java.*>>
+
+ * blank line
+
+ * import <<all other imports>>
+
+ []
+
+ all imports in each group should be sorted alphabetically.
+
+ To ensure a package import order consistent with the layout described above, download
+ <<<{{{https://gitbox.apache.org/repos/asf?p=maven-shared-resources.git;a=blob_plain;f=src/main/resources/config/maven-eclipse-importorder.txt;hb=HEAD}maven-eclipse-importorder.txt}}>>>, select <Window \> Preferences> and
+ navigate to <Java \> Code Style \> Organize Imports>. Click on <Import...> and select the downloaded
+ file to change the import order.
+
+** {JavaDoc Convention}
+
+ TO BE DISCUSSED
+
+* {XML}
+
+** {XML Code Style}
+
+ The Maven style for XML files is mainly:
+
+ * <<Indentation>>: Always use 2 space indents, unless you're wrapping a new XML tags line in which case you should
+ indent 4 spaces.
+
+ * <<Line Breaks>>: Always use a new line with indentation for complex XML types and no line break for simple XML
+ types. Always use a new line to separate XML sections or blocks, for instance:
+
++-----+
+<aTag>
+ <simpleType>This is a simple type</simpleType>
+
+ <complexType>
+ <simpleType>This is a complex type</simpleType>
+ </complexType>
+</aTag>
++-----+
+
+ In some cases, adding comments could improve the readability of blocks, for instance:
+
++-----+
+ <!-- Simple XML documentation -->
++-----+
+
+ or
+
++-----+
+ <!-- ====================================================================== -->
+ <!-- Block documentation -->
+ <!-- ====================================================================== -->
++-----+
+
+ []
+
+** {Generic XML Code Convention}
+
+ No generic code convention exists yet for XML files.
+
+** {POM Code Convention}
+
+ The team has {{{https://lists.apache.org/thread/h8px5t6f3q59cnkzpj1t02wsoynr3ygk}voted}}
+ during the end of June 2008 to follow a specific POM convention to ordering POM elements.
+ The consequence of this vote is that the {{{https://maven.apache.org/ref/current/maven-model/maven.html}Maven project descriptor}}
+ is <<no more>> considered as the reference for the ordering.
+
+ The following is the recommended ordering for all Maven POM files:
+
++-----+
+<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
+ <modelVersion/>
+
+ <parent/>
+
+ <groupId/>
+ <artifactId/>
+ <version/>
+ <packaging/>
+
+ <name/>
+ <description/>
+ <url/>
+ <inceptionYear/>
+ <organization/>
+ <licenses/>
+
+ <developers/>
+ <contributors/>
+
+ <mailingLists/>
+
+ <prerequisites/>
+
+ <modules/>
+
+ <scm/>
+ <issueManagement/>
+ <ciManagement/>
+ <distributionManagement/>
+
+ <properties/>
+
+ <dependencyManagement/>
+ <dependencies/>
+
+ <repositories/>
+ <pluginRepositories/>
+
+ <build/>
+
+ <reporting/>
+
+ <profiles/>
+</project>
++-----+
+
+ <<Comments>>:
+
+ [[1]] The \<project/\> element is always on one line.
+
+ [[2]] The blocks are voluntary separated by a new line to improve the readingness.
+
+ [[3]] The dependencies in \<dependencies/\> and \<dependencyManagement/\> tags have no specific ordering. Developers
+ are free to choose the ordering, but grouping dependencies by topics (like groupId i.e. <<<org.apache.maven>>>) is a good practice.
+
+ []
+
+
+** {XDOC Code Convention}
+
+ For consistency and readability reasons, XDOC files should respect:
+
+ * <<Metadata>>: Always specify metadata in the \<properties/\> tag.
+
+ * <<Sections>>: Always use a new line with indentation for \<section/\> tags.
+
+ []
+
+** {FML Code Convention}
+
+ For readability reasons, FML files should respect:
+
+ * <<FAQ>>: Always use a new line with indentation for \<faq/\> tags.
+
+ []
+
+~~ * {APT} Do we need any specific APT style/convention?
diff --git a/content/apt/developers/conventions/git.apt b/content/apt/developers/conventions/git.apt
new file mode 100644
index 00000000..b08a99e3
--- /dev/null
+++ b/content/apt/developers/conventions/git.apt
@@ -0,0 +1,228 @@
+ ------
+ Maven Git Convention
+ ------
+ Olivier Lamy
+ ------
+ 2012-09-12
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ https://maven.apache.org/doxia/references/apt-format.html
+
+Maven Git Convention
+
+ This document describes how developers should use Git.
+
+* Git Configuration
+
+** For contributors who are not committers
+
+ Apache git repositories are at
+< <<git://git.apache.org>>>. However, the ASF
+ uses clones on github.com to make it easier for people to contribute
+ changes via pull requests.
+
+ To contribute to a Maven component that is maintained in git, please
+ follow these steps:
+
+ [[1]] create a JIRA for bug or improvement that you wish to work
+ on. The Maven project uses JIRA to organize and track our work,
+ and in particular to keep track of which changes are included in
+ which releases.
+
+ [[2]] Make a fork of the official ASF clone from github.com. For
+ example, <<<https://github.com/apache/maven-scm>>>.
+
+ [[3]] Make a branch named after your JIRA ticket. This is not <required>,
+ but it makes it easier for Maven committers to keep track of your
+ contribution.
+
+ [[4]] Make your changes. As always, unit or integration tests make
+ it much easier for us to accept your changes.
+
+ [[5]] Make a pull request to pull your changes to the official clone.
+ Add a link to your pull request to the JIRA. Committers will take it
+ from here.
+
+** For committers
+
+ Committers may, of course, commit directly to the ASF repositories.
+ For complex changes, you may find it valuable to make a pull request
+ at github to make it easier to collaborate with others.
+
+*** {Commit Message Template}
+
+ Commits should be focused on one issue at a time, because that makes it easier
+ for others to review the commit.
+
+ A commit message should use this template:
+
+-------
+[ISSUE-1] <<Summary field from JIRA>>
+Submitted by: <<Name of non-committer>>
+
+o Comments
+-------
+
+ Where:
+
+ * <<ISSUE-1>> can be omitted if there was no relevant JIRA issue, though you are strongly encouraged to create one for
+ significant changes.
+
+ * <<Submitted by>> only needs to be specified when a patch is being applied for a non-committer.
+
+ * <<Comments>> some optional words about the solution.
+
+ []
+
+ eg:
+
+-------
+[MNG-1456] Added the foo to the bar
+Submitted by: Baz Bazman
+
+o Applied without change
+-------
+
+* Apply User Patch
+
+ To keep the history of contributions clear,
+ The committer should usually apply the patch without any <<major>>
+ modifications, and then create his or her own commits for further
+ modifications. However, committers should never commit code to a live
+ branch which is not suitable to release. If a contribution requires
+ significant work to make it useful, commit it to a branch, fix it up,
+ and merge the branch.
+
+ If the user created a pull request, the committer is responsible for
+ closing that pull request. You do this by adding a note to a commit
+ message:
+
+------
+ Closes #NNN.
+------
+
+ where NNN is the number of the pull request.
+
+* Edit Commit Message
+
+ to edit last commit comment:
+
+---
+$ git commit --amend -m "new comment"
+---
+
+* Workflow
+
+ Workflow for svn folks is something like :
+
+---
+ $ git pull
+ $ hack hack hack
+ $ git push
+ // fails, because someone else has already pushed to master
+ $ git pull
+ // this creates some merges
+ $ git push
+---
+
+ A more quiet workflow :
+
+---
+$ git pull
+$ hack hack hack
+$ git push
+// fails, because someone else has already pushed to master
+$ git fetch
+// this moves 'origin/master'
+$ git rebase origin/master
+// this reapplies your local changes on top of origin/master
+$ git push
+---
+
+* Other useful Git commands while developing
+
+ If you've done a chunk of work and you would like to ditch your changes and start from scratch use this command to
+ revert to the original checkout:
+
+---
+$ git checkout .
+---
+
+ TODO .gitignore
+
+
+
+** power-git checkout
+
+ This checkout is typical for highly experienced git users, and may serve as inspiration for others; as usual the
+ best way to learn is by doing. Sample shown for maven-surefire
+
+ Go to https://github.com/apache/maven-surefire and fork surefire to your own github account.
+
+ Starting with nothing (no existing clone)
+
+---
+git clone https://github.com/<youraccount>/maven-surefire.git
+git remote add apache https://git-wip-us.apache.org/repos/asf/maven-surefire.git
+git remote add asfgithub https://github.com/apache/maven-surefire.git
+git config --add remote.asfgithub.fetch "+refs/pull/*/head:refs/remotes/asfgithub/pr/*"
+git fetch --all
+---
+ (You may consider adding --global to the git config statement above to always fetch
+ pull requests for any remote named "asfgithub")
+
+ In this setup, running "git push" will normally push to your personal github account.
+ Furthermore, all pull requests from github are also fetched to your local clone, use
+
+---
+gitk --all
+---
+
+ to try to make some sense of it all. This is an important command to understand! (gitk may need to be installed additionally)
+
+ gitk also has a quite excellent context menu that is far more context sensitive than most people realize at first impression. Right-clicking on a commit in a github pull-request will allow you to cherry-pick straight in the gui.
+
+
+ If you're working on the master branch, you can do stuff like this:
+
+---
+git push # your github account
+git push apache # the authoritative apache repo
+---
+
+ Using your github account as a storage for half-finished work is excellent if you switch between multiple computers,
+ always push to github before leaving your current computer and start by pulling at the next computer.
+
+ To merge a pull request
+
+---
+git merge pr/10 # merge pull request number 10 from asf@github into master
+git push apache # upload to apache
+---
+
+ Or if you're comfortable with rebasing;
+
+---
+
+git checkout pr/10
+git rebase apache/master
+git push apache
+---
diff --git a/content/apt/developers/dependency-policies.apt b/content/apt/developers/dependency-policies.apt
new file mode 100644
index 00000000..60ab6a42
--- /dev/null
+++ b/content/apt/developers/dependency-policies.apt
@@ -0,0 +1,78 @@
+ ------
+ Maven Dependency Policies
+ ------
+ Stephen Connolly
+ ------
+ 2011-02-01
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ https://maven.apache.org/doxia/references/apt-format.html
+
+Maven Dependency Policies
+
+* Scope
+
+ This page describes the policies around the use of dependencies by the Apache
+ Maven Developers in the process of developing Apache Maven itself.
+
+ This page does not apply to projects hosted outside of the Apache Maven
+ project. In order to remove all doubt, this page only applies to code
+ which has a Github URL that starts with
+ <<<https://github.com/apache/maven>>> or a Gitbox URL
+ starting with <<<https://gitbox.apache.org/repos/asf?p=maven>>>
+
+ If you have stumbled across this page and you are working on code that does
+ not have a Github URL starting with
+ <<<https://github.com/apache/maven>>> then this page does not apply
+ to you.
+
+* Background
+
+ The Apache Maven PMC is tasked with ensuring (among other things) that all
+ legal issues are addressed and that each and every release is the product
+ of the community as a whole.
+
+ The Apache Maven project consists of quite a number of components. For
+ the purposes of this policy, we will make a distinction between the
+ core Maven distribution and all the other components.
+
+ The core Maven distribution is the binary and source distributions made
+ available from the https://maven.apache.org/download page.
+
+* Applicability
+
+ This policy applies to all changes to dependencies as and from Subversion revision 1067464.
+
+* Core Maven Distribution Dependencies
+
+ All dependencies which are included in the Core Maven Distribution must either:
+
+ * be licensed under a {{{https://www.apache.org/legal/resolved.html#category-a}Category A license}}; or
+
+ * be licensed under a {{{https://www.apache.org/legal/resolved.html#category-b}Category B license}} and
+ approved by a majority vote of the Apache Maven PMC.
+
+ Votes for Category B licenses will be held on the dev@maven.apache.org mailing list. A majority of the PMC
+ must vote in favour of a Category B licensed dependency before a release can be made containing that dependency.
+
+* Non-Core Dependencies
+
+ Non-Core components may only use Category A or Category B licenses.
diff --git a/content/apt/developers/index.apt b/content/apt/developers/index.apt
new file mode 100644
index 00000000..6886ea21
--- /dev/null
+++ b/content/apt/developers/index.apt
@@ -0,0 +1,115 @@
+ ------
+ Maven Developer Centre
+ ------
+ Vincent Siveton
+ Brett Porter
+ ------
+ 2015-02-14
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ https://maven.apache.org/doxia/references/apt-format.html
+
+Maven Developer Centre
+
+ This documentation centre is for people who are Maven developers, or would like to contribute.
+
+ If you cannot find your answers here, feel free to ask the {{{mailto:dev@maven.apache.org}Maven Developer List}}.
+
+* Contributors Resources
+
+ * {{{../guides/development/guide-helping.html}Guide to helping with Maven}}
+
+ * {{{../guides/development/guide-maven-development.html}Developing Maven}}
+
+ * {{{../guides/development/guide-building-maven.html}Building Maven}}
+
+ * {{{../scm.html}Source Code}}
+
+ * {{{https://ci-maven.apache.org/job/Maven/job/maven-box/}Continuous Integration}}
+
+ * {{{../plugin-developers/common-bugs.html}Common Bugs and Pitfalls}}
+
+ * {{{../project-roles.html}Apache Maven Project Roles}}
+
+ []
+
+* Committers Resources
+
+** General Resources
+
+ * {{{./welcome-to-new-committers.html}Guide for new Maven committers}}
+
+ * {{{./committer-environment.html}Committer Environment}}
+
+ * {{{./committer-settings.html}Committer Settings}}
+
+ * {{{./retirement-plan-plugins.html}Retirement Plan for Plugins}}
+
+ * {{{./dependency-policies.html}Maven Dependency Policies}}
+
+ * {{{./compatibility-plan.html}Maven Plugins and Components Compatibility Plan}}
+
+ * {{{https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567}Maven Proposals/Backlog}}
+
+ []
+
+* Developers Conventions
+
+ There are a number of conventions used in the Maven projects, which contributors and developers alike should follow for
+ consistency's sake.
+
+ * {{{./conventions/code.html}Maven Code Style And Conventions}}
+
+ * {{{./conventions/jira.html}Maven JIRA Convention}}
+
+ * {{{./conventions/git.html}Maven Git Convention}}
+
+ []
+
+ <<Note>>: If you cannot find your answers here, feel free to ask the {{{mailto:dev@maven.apache.org}Maven Developer List}}.
+
+* Making Releases
+
+ * {{{./release/pmc-gpg-keys.html}Making GPG Keys}}
+
+ * {{{./release/index.html}Release Process}}
+
+ []
+
+* Maven Website
+
+ * {{{./website/index.html}Deploy Maven Website}}
+
+ []
+
+* Other Resources
+
+ * {{{https://www.apache.org/dev/}ASF Development Infrastructure Information}}
+
+ * {{{https://www.apache.org/foundation/}About the Apache Software Foundation}}
+
+ []
+
+~~TODO: tasks as buttons?
+
+~~TODO: de-dupe with existing documents in community
+
+~~TODO: clean up, have cookbook with more in depth documents like cutting releases, etc.
diff --git a/content/apt/developers/release/index.apt b/content/apt/developers/release/index.apt
new file mode 100644
index 00000000..385ac4ed
--- /dev/null
+++ b/content/apt/developers/release/index.apt
@@ -0,0 +1,48 @@
+ -----
+ Releasing A Maven Project
+ -----
+ Jason van Zyl
+ -----
+ 2010-07-26
+ -----
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+Releasing A Maven Project
+
+ What follows is a description of releasing a Maven project to a staging repository and its documentation, whereupon
+ it is scrutinized by the community, approved, and transferred to a production repository.
+
+ The steps involved are similar for any Apache project, with more specifics for parent POMs and
+ Maven itself. The steps involved, and the relevant documents for each, are listed below.
+
+~~ nothing specific: normal component * {{{./maven-plugin-release.html} Releasing a Maven plugin project}}
+
+~~ nothing specific: normal component * {{{./maven-shared-release.html} Releasing a Maven shared component or subproject}}
+
+ * {{{./maven-core-release.html} Releasing Maven Core}}
+
+ * {{{./parent-pom-release.html} Releasing a parent POM}}
+
+ []
+
+ The above links all provide specific information for those types of releases, but they all refer back to the common documentation:
+
+ * {{{./maven-project-release-procedure.html} Maven Project Common Release procedure}}
+
+ []
diff --git a/content/apt/developers/release/maven-project-release-procedure.apt b/content/apt/developers/release/maven-project-release-procedure.apt
new file mode 100644
index 00000000..3c827cd5
--- /dev/null
+++ b/content/apt/developers/release/maven-project-release-procedure.apt
@@ -0,0 +1,328 @@
+ -----
+ Releasing A Maven Project
+ -----
+ Jason van Zyl
+ Karl Heinz Marbaise
+ -----
+ 2018-04-07
+ -----
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+Performing a Maven Project Release
+
+ This document covers the common release procedures used by the Maven team to perform releases.
+
+* {Prerequisites}
+
+ Be sure that:
+
+ * you have a recent Git client installed and on your shell's path.
+
+ * you have JDK 8 installed and on your shell's path to build Maven 3.7.0+. Details about minimum JDK version to build an appropriate version
+ can be found here: {{{/docs/history.html}https://maven.apache.org/docs/history.html}}
+
+ * if you receive an OutOfMemoryError during the build, make sure to have set the environment variable <<<MAVEN_OPTS=-Xmx512m>>>
+
+ * you must use Maven 3.3.9+.
+
+ * follow Apache environment configuration steps outlined at: {{{https://www.apache.org/dev/publishing-maven-artifacts.html#dev-env}Publishing Maven Artifacts}}.
+
+ []
+
+* Before you begin
+
+ If you started here, you may first want to review one of the following documents that cover the specifics of various types of releases we have in the Maven Project:
+
+ * {{{./maven-core-release.html} Releasing Maven Core}}
+
+ * {{{./parent-pom-release.html} Releasing a parent POM}}
+
+ []
+
+* Consider updating the parent versions
+
+ If the item you are planning to release is not using the most recent version of its parent
+ (see {{{../../pom/}parent POMs}} index), consider taking this opportunity to update to it.
+
+* Make sure that site compilation works
+
+ Particularly if you update the parent or if you updated your javadoc,
+ the site compilation process may fail, or reveal a conspicuous error. It is stressful and time-consuming
+ to discover this *after* you stage a release and then try to follow
+ the procedure to deploy the site for review. So you may find it more
+ pleasant to check out the state of the site before you start:
+
+----
+mvn -Preporting site site:stage
+----
+
+* Stage the Release
+
+ [[1]] Follow the release preparation, staging and closing the repository steps outlined in
+ {{{https://infra.apache.org/publishing-maven-artifacts.html}Publishing Maven Releases}}.
+
+ [[2]] Stage the latest documentation as explained in {{{../website/deploy-component-reference-documentation.html}deploying Maven components reference documentation}}.
+
+* Call the vote
+
+ Propose a vote on the dev list with the closed issues, the issues left,
+ the staging repository and the staging site. For instance:
+
+-----
+To: "Maven Developers List" <de...@maven.apache.org>
+Subject: [VOTE] Release Apache Maven XXX Plugin version Y.Z
+
+Hi,
+
+We solved N issues:
+https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=XXXXXX&version=YYYYYYY&styleName=Text
+
+There are still a couple of issues left in JIRA:
+https://issues.apache.org/jira/issues/?jql=project%20%3D%20XXXXXXXXXX%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
+
+Staging repo:
+https://repository.apache.org/content/repositories/maven-[YOUR REPOSITORY ID]/
+https://repository.apache.org/content/repositories/maven-[YOUR REPOSITORY ID]/[PATH-TO]-source-release.zip
+
+Source release checksum(s):
+[NAME-OF]-source-release.zip sha512: [SHA512SUM]
+
+Staging site:
+https://maven.apache.org/plugins-archives/maven-XXX-plugin-LATEST/
+
+Guide to testing staged releases:
+https://maven.apache.org/guides/development/guide-testing-releases.html
+
+Vote open for at least 72 hours.
+
+[ ] +1
+[ ] +0
+[ ] -1
+
+-----
+
+ To get the JIRA release notes link, browse to the plugin's or component's JIRA page, select the <Road Map> link,
+ and use the link to <Release Notes> that is next to the version being released.
+
+ To get the list of issues left in JIRA, browse to the plugin's or component's JIRA page, and from the <Preset Filters>
+ on the right, use the link for <Outstanding> issues.
+
+ The vote is open for at least 72 hours means, that you need to wait at least 72 hours before proceeding.
+ This gives others time to test your release and check that everything is good. If you have received after that
+ not enough +1 votes to reach the quorum, this doesn't mean, the vote failed. It just takes a bit longer.
+
+* Check the vote results
+
+ Copied from {{{https://www.apache.org/foundation/voting.html#ReleaseVotes}Votes on Package Releases}}.
+
+-----
+Votes on whether a package is ready to be released use majority approval
+-- i.e. at least three PMC members must vote affirmatively for release,
+and there must be more positive than negative votes. Releases may not be vetoed.
+Generally the community will cancel the release vote if anyone identifies serious problems,
+but in most cases the ultimate decision, lies with the individual serving as release manager.
+The specifics of the process may vary from project to project,
+but the 'minimum quorum of three +1 votes' rule is universal.
+-----
+
+ The list of PMC members is available at {{https://people.apache.org/committers-by-project.html#maven-pmc}}.
+
+** Successful vote
+
+ Once a vote is <<successful>>, post the result to the <<<dev>>> list and cc the <<<PMC>>>. For instance:
+
+-----
+To: "Maven Developers List" <de...@maven.apache.org>
+CC: "Maven Project Management Committee List" <pr...@maven.apache.org>
+Subject: [RESULT] [VOTE] Release Apache Maven XXX Plugin version Y.Z
+
+Hi,
+
+The vote has passed with the following result:
+
++1 : <<list of names>>
+
+PMC quorum: ...
+
+I will promote the source release zip file to Apache distribution area and the artifacts to the central repo.
+-----
+
+ Follow the procedure to the end.
+
+** Unsuccessful vote
+
+ Once a vote is <<unsuccessful>>, post the result to the <<<dev>>> list, For instance:
+
+-----
+To: "Maven Developers List" <de...@maven.apache.org>
+Subject: [CANCEL] [VOTE] Release Apache Maven XXX Plugin version Y.Z
+
+Hi,
+
+The vote has been canceled.
+-----
+
+ For canceled vote the process will need to be restarted.
+
+ Be sure to:
+
+ * drop your staging repository as described in {{{https://www.apache.org/dev/publishing-maven-artifacts.html}Drop a repository}}
+
+ * create new version for next round <<<Y.Z+1>>>
+
+ * assign issues from version <<<Y.Z>>> also to version <<<Y.Z+1>>>
+
+ * mark the <<<Y.Z>>> version as <<archived>>
+
+ * report found issues and assign them to version <<<Y.Z+1>>>
+
+ * fix found issues
+
+ []
+
+ Start the process for version <<<Y.Z+1>>> from the beginning.
+
+* Copy the source release to the Apache Distribution Area
+
+ The official Apache release is the 'source-release' bundle distributed in <<<www.apache.org/dist>>>,
+ as described in {{{https://www.apache.org/dev/release-distribution}Apache Release Distribution Policy}}.
+ All releases for Maven must be copied to {{{https://www.apache.org/dist/maven/}the official Maven release area}}.
+
+ The release area is maintained with svnpubsub. To deliver a release, you add it to
+ {{{https://dist.apache.org/repos/dist/release/maven}the subversion repository for the dist area}}:
+ add the release, its signature and sha512 checksum files, copying them from
+ <<<target/checkout/target/>>> directory created during <<<mvn release:perform>>> step.
+ Currently this requires to be in maven-pmc group (see {{{https://issues.apache.org/jira/browse/INFRA-5945}INFRA-5945}}).
+ If you are not a PMC member, drop a line to <pr...@maven.apache.org> and ask them to do this step (and the next one) for you: the PMC member will
+ get the source release bundle and its signature from Nexus staging repository and will create sha512 checksum file by hand, for example using shell:
+
+--------
+for f in *.zip ; do echo -n $(sha512sum $f | cut -c -128) > $f.sha512 ; done
+--------
+
+ For example:
+
+--------
+wagon/wagon-2.2-source-release.zip
+wagon/wagon-2.2-source-release.zip.asc
+wagon/wagon-2.2-source-release.zip.sha512
+--------
+
+ You should also run 'svn rm' as needed to clear out older releases. As per {{{https://www.apache.org/legal/release-policy.html#where-do-releases-go}Apache Release Policy}},
+ only the latest release on a branch should stay in the main dist areas. So long as the previous release is at least a day old, the automatic archiver
+ will have copied it to the archive.
+
+ To check that everything is ok in the dist area, dist-tool-plugin has been written and run once a day to produce
+ {{{https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/}"Check Source Release" and "Check Errors" reports}}.
+
+* Add the release for next board report
+
+ After committing the 3 source-release files, visit {{{https://reporter.apache.org/addrelease.html?maven}Apache Committee Report Helper}} to add your release data with the Full Version Name and Date of Release.
+ (You will receive an e-mail for it as well).
+
+ If you are not a PMC member, drop a line to <pr...@maven.apache.org> and ask them to do this step for you if they did not do the update while adding to release area.
+
+* Promote the release
+
+ Once the release is deemed fit for public consumption it can be transfered to a production repository where it will
+ be available to all users.
+
+ [[1]] See {{{https://www.apache.org/dev/publishing-maven-artifacts.html#promote}Promoting a Repo}} for details on promotion.
+
+ [[2]] Deploy the current website
+
+ As above, deploy the web site if appropriate and update the project site for the
+ new release: use {{{../website/component-reference-documentation-helper.html}Component Reference Documentation Helper}} to generate commands or see
+ {{{../website/deploy-component-reference-documentation.html#Publishing_versioned_component_reference_documentation}Publishing versioned component reference documentation}}
+ for explanations.
+ Note that not all projects follow these conventions exactly.
+
+ In case there's an overview table with version (e.g. {{{/plugins/index.html}plugins}} and {{{/shared/index.html}shared}}) you can directly edit it on the github page.
+
+ [[3]] Update the version tracking in JIRA
+
+ In the relevant project, go to Administration, then Versions. Mark
+ the <<<Y.Z>>> version as 'released'. Create version <<<Y.Z+1>>>, if that hasn't already
+ been done. You may also archive any deprecated releases (milestones or alphas) at this time.
+
+ Note: Currently this requires to be in the maven-pmc group. So, if you don't see the Administration option in JIRA, kindly ask <pr...@maven.apache.org> to do this step for you.
+
+
+ [[4]] Wait for everything to sync
+
+ [[a]] Sync to {{{https://repo.maven.apache.org/maven2/org/apache/maven/}Maven Central}}
+
+ The sync into central staging from repository.apache.org occurs every 4 hours.
+ There is a separate hourly schedule that runs which pushes from staging to the other central machines, and then updates the indexes.
+
+ [[b]] Sync to Maven Website
+
+ If the project you are releasing doesn't yet use svnpubsub for site deployment, the deployment of the Maven website will {{{https://www.apache.org/dev/release-publishing.html#sync-delay}take an hour or so to sync}}.
+
+ []
+
+ [[5]] Create an announcement.
+
+ Following instructions are done for plugins: if you are releasing anything else than a plugin, you should adapt email content to match what you are releasing.
+
+ <<Note:>> You must send this email from your apache email account, e.g. YOUR_APACHE_USERNAME@apache.org otherwise
+ the email to <<<...@maven.apache.org>>> will bounce.
+
+-----
+From: YOUR_APACHE_USERNAME@apache.org
+To: announce@maven.apache.org, users@maven.apache.org
+Cc: dev@maven.apache.org
+Subject: [ANN] Apache Maven XXX Plugin Y.Z Released
+
+The Apache Maven team is pleased to announce the release of the Apache Maven XXX Plugin, version Y.Z
+
+This plugin (insert short description of the plugin's purpose).
+
+https://maven.apache.org/plugins/maven-XXX-plugin/
+
+You should specify the version in your project's plugin configuration:
+
+<plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-XXX-plugin</artifactId>
+ <version>Y.Z</version>
+</plugin>
+
+You can download the appropriate sources etc. from the download page:
+
+https://maven.apache.org/plugins/maven-XXX-plugin/download.cgi
+
+Release Notes - Maven XXX Plugin - Version Y.Z
+
+(Copy Here Release Notes in Text Format from JIRA)
+
+Enjoy,
+
+-The Apache Maven team
+
+-----
+
+ [[6]] If releasing the Apache Parent POM, notify <<<...@apache.org>>>:
+ Several projects follow this list, and should be made aware of changes to the common parent.
+ This might also be a step to take if other shared resources are released, or if plugin releases are
+ of particular interest to that group.
+
+ If releasing Maven Core, notify <<<...@apache.org>>>
+
+ [[7]] Celebrate :o)
diff --git a/content/apt/developers/release/parent-pom-release.apt b/content/apt/developers/release/parent-pom-release.apt
new file mode 100644
index 00000000..3e357916
--- /dev/null
+++ b/content/apt/developers/release/parent-pom-release.apt
@@ -0,0 +1,101 @@
+ -----
+ Releasing A Parent POM
+ -----
+ Hervé Boutemy
+ Dennis Lundberg
+ -----
+ 2013-12-07
+ -----
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+Releasing A Parent POM
+
+ Releasing a Parent POM is much the same as any other Maven project. The following
+ guide walks through most of the steps:
+
+ * {{{./maven-project-release-procedure.html} Maven Project Common Release procedure}}
+
+ Note that Parent POMs have particular conventions for managing and deploying the documentation.
+
+* Rationale
+
+ To be able to publish a documentation for the parent POM without affecting released <<<pom.xml>>> and <<<site.xml>>>,
+ parent POM projects have a specific structure, with the addition of <<<site-pom.xml>>> and <<<src/site-docs>>>
+ to provide <<<mvn -f site-pom.xml site>>> with useful documentation content:
+
+------
+|-- pom.xml
+|-- site-pom.xml
+`-- src
+ |-- site
+ | `-- site.xml
+ `-- site-docs
+ |-- apt
+ | `-- index.apt
+ `-- site.xml
+------
+
+ And the <<<index.apt>>> page not only contains instructions about the content of the parent POM, but
+ it maintains a history of POM releases links and diffs.
+
+ Each specific step is done to maintain <<<site-pom.xml>>> and <<<index.apt>>> in sync with the release being released.
+
+* Stage the release
+
+ Before staging the release with usual procedure, you need to update <<<site-pom.xml>>> and <<<index.apt>>> to
+ take the future release into account:
+
+ [[1]] update <<<site-pom.xml>>> parent POM version to match the version being released,
+
+ [[2]] update <<<src/site-docs/index.apt.vm>>>: add a line in the history of <<<pom.xml>>> for the version being released, referring
+ to the future git release tag and date.
+
+ []
+
+ Once these modifications are done, you can follow {{{../website/deploy-component-reference-documentation.html}standard component documentation staging steps}},
+ taking care to use the <<<site-pom.xml>>> POM, with <<<mvn -f site-pom.xml ...>>> command, each time the parent POM's site is
+ generated or published.
+
+ Then the only difference is with commands to stage the site:
+
+--------
+cd target/checkout
+mvn -f site-pom.xml site
+mvn -f site-pom.xml scm-publish:publish-scm
+--------
+
+* Call the vote
+
+ In the vote, instead of providing links to JIRA, the parent POMs should include a link to the Git changes since the
+ last release:
+
+-------
+...
+Hi,
+
+Changes since the last release:
+for Maven Apache Parent POM:
+https://github.com/apache/maven-apache-parent/compare/apache-<VERSION-OF-PREVIOUS-RELEASE>...apache-<VERSION-OF-CURRENT-RELEASE>
+
+or for Maven Projects Parent POM:
+https://github.com/apache/maven-parent/compare/maven-parent-<VERSION-OF-PREVIOUS-RELEASE>...maven-parent-<VERSION-OF-CURRENT-RELEASE>
+
+Staging repo:
+...
+-------
diff --git a/content/markdown/developers/release/pmc-gpg-keys.md b/content/apt/developers/release/pmc-gpg-keys.apt
similarity index 51%
rename from content/markdown/developers/release/pmc-gpg-keys.md
rename to content/apt/developers/release/pmc-gpg-keys.apt
index 4d7d3351..edb8d751 100644
--- a/content/markdown/developers/release/pmc-gpg-keys.md
+++ b/content/apt/developers/release/pmc-gpg-keys.apt
@@ -1,37 +1,39 @@
-title: Developers centre - Making GPG Keys
-author: Vincent Siveton
-date: 2006-10-01
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## Introduction
-
-
- You need to add your GPG keys in [https://svn.apache.org/repos/asf/maven/project/KEYS](https://svn.apache.org/repos/asf/maven/project/KEYS) before a release. Here are some useful [GnuPG](http://www.gnupg.org/) commands to generate your Keys.
-
-
-### gpg --gen-key
-
-
-
-```
+ ------
+ Developers centre - Making GPG Keys
+ ------
+ Vincent Siveton
+ ------
+ 2006-10-01
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction
+
+ You need to add your GPG keys in {{https://svn.apache.org/repos/asf/maven/project/KEYS}} before a release. Here are some
+ useful {{{http://www.gnupg.org/}GnuPG}} commands to generate your Keys.
+
+* gpg --gen-key
+
+-------
>gpg --gen-key
gpg (GnuPG) 1.4.5; Copyright (C) 2006 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
@@ -106,14 +108,11 @@ pub 1024D/07DDB702 2006-10-10
uid Vincent Siveton <vs...@apache.org>
sub 2048g/D2814A59 2006-10-10
-```
-
-
-### gpg --list-sigs && gpg --armor --export
+-------
+* gpg --list-sigs && gpg --armor --export
-
-```
+----------------
>gpg --list-sigs "Vincent Siveton" && gpg --armor --export "Vincent Siveton"
pub 1024D/07DDB702 2006-10-10
uid Vincent Siveton <vs...@apache.org>
@@ -121,39 +120,54 @@ sig 3 07DDB702 2006-10-10 Vincent Siveton <vs...@apache.org>
sub 2048g/D2814A59 2006-10-10
sig 07DDB702 2006-10-10 Vincent Siveton <vs...@apache.org>
-```
-
-
-
-## Version: GnuPG v1.4.5 (MingW32)
-
-
-
-## mQGiBEUrnAsRBACQDiYGc1IQmkENLO9iznBg8otGPEbzqQozT5tsip5mB30f6Mc/ uuLxJkLdna7Ul3goIXDtCeLJq38gHvruNtVNR6S\+juJFkd5sLEH8UJ18PbKuo/9I KGlzjtCYUUDC48czRr0efhqd54NH8ydNdpaZ76NGPPYfpXtk7kKgH/nPiwCgxozK IG2frMuWIvdFafbqdAl7y/sD/1Csf0r9jtHEeXOuyhm8jCGrSwzLbHUGKPUQP37P ajECHoWp6HnvHEEEpgVl\+UjfZvrcVhzUoP\+3r5HAugqERfkzK8AWc7qjIRjf64kU sjvto31G2KYz17Y8K9y4LkRkUspu8uw903pKnW/QELg4vvPVaEYpVVIdS6\+cUreu V0hOA/4tW7T/GpzSbQmjvnIRQ7GVHbQeXsANwrS6NmGYIxafN9P9dfHV\+eUieTu6 rvMP9coOhTYyEKZksrXw2MmXx5Szg [...]
-
-
- You need to append this result to [https://svn.apache.org/repos/asf/maven/project/KEYS](https://svn.apache.org/repos/asf/maven/project/KEYS).
-
-
- You also need to upload your key to the public server: [http://pgp.mit.edu/](http://pgp.mit.edu/) by copying the same you appended in the text field and submit. You can ensure by searching your email in key search engine.
-
-
-### gpg --fingerprint
-
-
-
-```
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: GnuPG v1.4.5 (MingW32)
+
+mQGiBEUrnAsRBACQDiYGc1IQmkENLO9iznBg8otGPEbzqQozT5tsip5mB30f6Mc/
+uuLxJkLdna7Ul3goIXDtCeLJq38gHvruNtVNR6S+juJFkd5sLEH8UJ18PbKuo/9I
+KGlzjtCYUUDC48czRr0efhqd54NH8ydNdpaZ76NGPPYfpXtk7kKgH/nPiwCgxozK
+IG2frMuWIvdFafbqdAl7y/sD/1Csf0r9jtHEeXOuyhm8jCGrSwzLbHUGKPUQP37P
+ajECHoWp6HnvHEEEpgVl+UjfZvrcVhzUoP+3r5HAugqERfkzK8AWc7qjIRjf64kU
+sjvto31G2KYz17Y8K9y4LkRkUspu8uw903pKnW/QELg4vvPVaEYpVVIdS6+cUreu
+V0hOA/4tW7T/GpzSbQmjvnIRQ7GVHbQeXsANwrS6NmGYIxafN9P9dfHV+eUieTu6
+rvMP9coOhTYyEKZksrXw2MmXx5SzgxsXT0g4wDXbwxPYFfIdGUzFMobnVXiZ3G8l
+JEl9cML0cg3ZL1SoDmVf2iG3e3Yxxsne4AE1SU+0bbq0t7rqALQlVmluY2VudCBT
+aXZldG9uIDx2c2l2ZXRvbkBhcGFjaGUub3JnPohgBBMRAgAgBQJFK5wLAhsDBgsJ
+CAcDAgQVAggDBBYCAwECHgECF4AACgkQhPTUcAfdtwLP3gCbB/V1afp8hzxgirCS
+d2r6zCkJQ2IAoLKD/RIkkerNintYzrubJliJKBsRuQINBEUrnBgQCAD1+Sx+sBDL
+1XCDtxQGsrZmMnJJVK/w4TPa/8weJkuZ1GSpINOjInmqESuehvCLoOoyfcuDVXlR
+PUZhKZLPEKfJlFptGNK19oTO/CoQN+SJLwR41FoumsBaf1YSSRpAukyx2J6cUxqf
+uWrK/T8PmgDw4YzmY96tev//41eZ5tSOxpoUM8ypnTaShtS9pjgHijEG0b7wBqeU
+e1OGOiLHgKyjEJUmlTaLm1SxJ84eq0uAvYb+rb/QoWWLpjvr2/mo1kzUvCPgo3fh
+kgOxCxsC9QD836Mi5HFK6CRYU3yAFu5+/jM+LJzELy3u7uMuOSP6yuiK8WXopdbN
+WHOiJQfdc2gTAAMFCADdljjAG7L+8de6JzsEduKErKqWlTEWa99n1knaGKzdUUOP
+WrKxwqgI6PAJbxOfG4vBdDa6M6+nySJDMybQsOCFyNx91/7jYkgkmv8Jkt8CTW4z
+P4HKlFYMAFpU95ftpTAAMAlr+t+nZRTHi94/VHMv4yLGzB/xapbzToHKuUt1Yqom
+Ncio5px7RVoicn13/i/GeY72fIdC2LRGo6PXlmmDQemoAnUw0RJoEtzapb0j/tWd
+BdAtQQX/Ks7qhk4aDDHGgO+CdHAB8PLHDpMpUX5Zc9JX1xhyJcS8d/LPUpXtt9WN
+eekqDpx+jNmySJr6os7rPAkjx6jDUvHPiuKdT4aviEkEGBECAAkFAkUrnBgCGwwA
+CgkQhPTUcAfdtwJL9ACgmLuDxE+oZaMhyFSmXWN0fM36Bd8AoLYrvwydB9+nNnhJ
+85TjkMPTgjp9
+=Hg4C
+-----END PGP PUBLIC KEY BLOCK-----
+----------------
+
+ You need to append this result to {{https://svn.apache.org/repos/asf/maven/project/KEYS}}.
+
+ You also need to upload your key to the public server: {{http://pgp.mit.edu/}}
+ by copying the same you appended in the text field and submit.
+ You can ensure by searching your email in key search engine.
+
+* gpg --fingerprint
+
+-------
>gpg --fingerprint vsiveton
pub 1024D/07DDB702 2006-10-10
Key fingerprint = 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
uid Vincent Siveton <vs...@apache.org>
sub 2048g/D2814A59 2006-10-10
-```
-
- Go to [https://id.apache.org](https://id.apache.org), log in and fill `OpenPGP Public Key Primary Fingerprint:` with the value of `Key fingerprint`.
-
-
- You can read more about [Checksums And Signatures](https://www.apache.org/dev/release-signing.html#faq).
-
+-------
+ Go to {{https://id.apache.org}}, log in and fill <<<OpenPGP Public Key Primary Fingerprint:>>> with the value of <<<Key fingerprint>>>.
+ You can read more about {{{https://www.apache.org/dev/release-signing.html#faq}Checksums And Signatures}}.
diff --git a/content/apt/developers/retirement-plan-plugins.apt b/content/apt/developers/retirement-plan-plugins.apt
new file mode 100644
index 00000000..1c15a4be
--- /dev/null
+++ b/content/apt/developers/retirement-plan-plugins.apt
@@ -0,0 +1,166 @@
+ ------
+ Retirement Plan for Plugins
+ ------
+ Dennis Lundberg
+ ------
+ 2013-07-26
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ https://maven.apache.org/doxia/references/apt-format.html
+
+Retirement Plan for Plugins
+
+* Decide to retire
+
+ Propose a vote on the dev-list to retire a plugin. The vote should be
+ open for the standard 72 hours to allow people to voice their opinions. Send a
+ cc to the users-list. Standard Apache voting rules apply. Only PMC votes are
+ binding.
+
+ The vote must contain one or more options on how to retire the plugin. There
+ are multiple scenarios available. Here are a couple that have been suggested:
+
+ [[A]] Move to our retired area in svn
+
+ [[A]] Move to another Apache project
+
+ [[A]] Move to www.mojohaus.org, apache-extras.org or another forge
+
+ []
+
+ Here's a template for scenario A that can be used for the vote email:
+
+------
+To: "Maven Developers List" <de...@maven.apache.org>
+Cc: "Maven Users List" <us...@maven.apache.org>
+Subject: [VOTE] Retire Maven Foo Plugin
+
+Hi,
+
+A paragraph giving the reasons why the plugin should be retired. Make a note of
+how long it has been since the latest release.
+
+I therefore propose that we retire maven-foo-plugin.
+
+If this vote is successful I will make one final release of the plugin, making
+it clear on the plugin site that it has been retired. After that the source code
+will be moved into the "retired" area in Subversion.
+
+The process for retiring a plugin is described here:
+https://maven.apache.org/developers/retirement-plan-plugins.html
+
+The vote is open for 72 hours.
+
+[ ] +1 Yes, it's about time
+[ ] -1 No, because...
+------
+
+ If the vote is successful, post the result to the dev list and cc the PMC and
+ users list. For instance:
+
+------
+To: "Maven Developers List" <de...@maven.apache.org>
+Cc: "Maven Users List" <us...@maven.apache.org>
+CC: "Maven Project Management Committee List" <pr...@maven.apache.org>
+Subject: [RESULT] [VOTE] Retire Maven Foo Plugin
+
+Hi,
+
+The vote has passed with the following result:
+
++1 (binding): <<list of names>>
++1 (non binding): <<list of names>>
+
+I will continue with the steps required to retire this plugin.
+------
+
+ If the vote passes, make one final release of the plugin (with its own standard 72h vote on source release) before it is
+ retired. This allows us to make a clean break. The person who wants to retire
+ a plugin is the one who does the final release. Below you will find the extra
+ steps that you need to follow when retiring a plugin, in addition to
+ {{{./release/maven-project-release-procedure.html}our standard release process}}.
+
+* Make the final release
+
+ [[1]] Create an issue in JIRA with the issue type "Task" and the summary
+ "Retire this plugin", and schedule it for the final release. If the plugin
+ includes a JIRA report in the generated site, you will need to close this
+ issue before you make the release.
+
+ [[1]] Add the description
+ "This is the final version of this plugin. It has been retired."
+ to the final version in JIRA.
+
+ [[1]] Add a prominent notice on the front page of the plugin's site,
+ informing that the plugin is retired. Suggested text:
+
+------
+Note: This plugin is retired. It is no longer maintained.
+------
+
+ If the plugin is moved elsewhere, that should also be added to the plugin's
+ site. Suggested text:
+
+------
+Note: This plugin has retired from the Apache Maven project,
+but has moved to the <Organization> <Project> project.
+------
+
+ [[1]] Add " (RETIRED)" at the end of <<<\<project\>>>>/<<<\<name\>>>> in the
+ plugin's <<<pom.xml>>>. This will show up on every page of the generated site.
+
+ [[1]] Go ahead with {{{./release/maven-project-release-procedure.html}the standard release process}},
+ making sure that you follow the exceptions mentioned above regarding the site deployment.
+
+ [[1]] When updating the plugins page, move Maven Foo Plugin to under the
+ "Retired" heading. Remove the SVN and JIRA links and add
+ the date of retirement.
+
+ [[1]] When updating the version in JIRA, do not add Y.Z+1 and make sure you
+ remove any future versions.
+
+* Clean up after the release
+
+ [[1]] Remove the <<<.Jenkinsfile>>> from all branches. This will remove the project from https://builds.apache.org/job/maven-box/
+
+ [[1]] Ask INFRA for archive git repos (gitbox + github)
+
+ [[1]] Republish documentation, postfix project name with (RETIRED)
+
+ [[1]] When relevant update summary pages for {{{https://maven.apache.org/plugins/index.html}plugins}} or {{{https://maven.apache.org/shared/index.html}shared components}}
+
+ [[1]] Add " (RETIRED)" at the end of the project name in JIRA.
+
+ [[1]] Put the JIRA project in read-only mode in case of standalone project (own Jira key): apply Maven Retired Project Permissions Scheme.
+ (Requires JIRA admin karma: e.g. ask Brian Fox)
+
+ [[1]] Comment the {{{https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool.conf.html}dist-tool configuration}} entry.
+
+ [[1]] Remove distribution from current {{{https://dist.apache.org/repos/dist/release/maven/}dist area}}
+ (history remains available in {{{https://archive.apache.org/dist/maven/}archive}}).
+
+ [[1]] Update board report
+
+ [[1]] Announce the fact that the plugin has been retired/moved on the
+ announce@m.a.o and users@m.a.o mailing lists. Explain to people what they
+ should do if they would like to continue development of the plugin.
+
+~~ Insert template for retirement email here
diff --git a/content/apt/developers/website/deploy-component-reference-documentation.apt b/content/apt/developers/website/deploy-component-reference-documentation.apt
new file mode 100644
index 00000000..2ada4474
--- /dev/null
+++ b/content/apt/developers/website/deploy-component-reference-documentation.apt
@@ -0,0 +1,165 @@
+ ------
+ Deploy Maven Component Reference Documentation
+ ------
+ Barrie Treloar
+ Hervé Boutemy
+ ------
+ 2015-03-30
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction
+
+ This document gives step-by-step instructions for deploying
+ Maven components reference documentation inside the Maven {{{/}https://maven.apache.org/}} website.
+
+ See {{{./index.html}Maven website introduction}} for instructions on the whole website publication (main site content + components).
+
+
+Overview
+
+ Since December 2012, the overall website uses svnpubsub mechanism:
+
+[component-reference-documentation.png] Components reference documentation mechanisms overview
+
+
+How components reference documentation publication works
+
+ Components don't use CMS: components reference documentation are versioned and generated from full sources, with both handwritten content (like Maven main site)
+ and content generated from sources (javadoc, unit-test results, integration test results...).
+
+
+* Staging component reference documentation
+
+ Reference documentation of a component is staged in <<<https://maven.apache.org/xxx-archives/yyy-LATEST/>>>, where <<<yyy>>> is the
+ component name and <<<xxx>>> can be:
+
+ * the component type, like <<<shared>>>, <<<plugins>>>, <<<skins>>>, ... (see
+ {{/shared-archives/}}, {{/plugins-archives/}}, {{/pom-archives/}}, {{/skins-archives/}})
+
+ * the component name for standalone components, like <<<archetype>>>, <<<plugin-tools>>>, <<<surefire>>>, <<<wagon>>>, ...
+ (see {{/archetype-archives/}}, {{/archetypes-archives/}}, {{/plugin-tools-archives/}}, {{/scm-archives/}}, {{/surefire-archives/}}, {{/wagon-archives/}})
+
+ []
+
+ To publish component reference documentation:
+
+ [[0]] prerequisite: eventually build the component if it has not been done previously, or some reports may miss build or integration information:
+
+ Notice: In cases where you have prepared a release you can simple change into <<<target/checkout>>> folder and continue with 2.
+
+------------
+mvn -Prun-its install
+------------
+
+ [[1]] build the reference documentation:
+
+------------
+mvn -Preporting site site:stage
+------------
+
+ Notice: <<<site:stage>>> is really necessary only for multi-modules components, but added unconditionally in these instructions
+ to keep them as straightforward as possible.
+
+ [[2]] stage the reference documentation to website production svn area, using
+ {{{/plugins/maven-scm-publish-plugin}maven-scm-publish-plugin}}: (TODO: explanations on configuration in pom to yyy-LATEST)
+
+------------
+mvn scm-publish:publish-scm
+------------
+
+ svnpubsub mechanism transfers svn production content to live production site
+
+ []
+
+ []
+
+ <<Notice>>: content is in fact published to {{/components/}} directory,
+ and symbolic links declared in <<<resources/**/components.links>>> in main site source are used by Ant to
+ create a reference from <<</xxx>>> (= what we want to be user-visible) to <<</components/xxx>>> (what what is
+ checked out).
+
+* Publishing versioned component reference documentation
+
+ When doing a release, <<<yyy-LATEST>>> content staged in previous section needs:
+
+ [[1]] to be archived to versioned directory before a newer revision is published into -LATEST,
+
+ [[2]] to replace the actual component reference documentation.
+
+ []
+
+ This is done with operations on website production svn area: you can use
+ {{{./component-reference-documentation-helper.html}Component Reference Documentation Helper}} to
+ easily prepare svnmucc command line.
+
+
+ If you prefer to do everything by hand from command templates, you can do either with <<<svn>>> command:
+
+ * Unix:
+
+------------
+SVNPUBSUB=https://svn.apache.org/repos/asf/maven/website/components
+
+svn cp $SVNPUBSUB/xxx-archives/yyy-LATEST $SVNPUBSUB/xxx-archives/yyy-$version -m "Archive versioned site."
+
+svn rm $SVNPUBSUB/xxx/yyy -m "Remove old site."
+svn cp $SVNPUBSUB/xxx-archives/yyy-$version $SVNPUBSUB/xxx/yyy -m "Publish new site."
+------------
+
+ * Windows:
+
+------------
+set SVNPUBSUB=https://svn.apache.org/repos/asf/maven/website/components
+
+svn cp %SVNPUBSUB%/xxx-archives/yyy-LATEST %SVNPUBSUB%/xxx-archives/yyy-$version -m "Archive versioned site."
+
+svn rm %SVNPUBSUB%/xxx/yyy -m "Remove old site."
+svn cp %SVNPUBSUB%/xxx-archives/yyy-$version %SVNPUBSUB%/xxx/yyy -m "Publish new site."
+------------
+
+ []
+
+ or with {{{http://svnbook.red-bean.com/en/1.8/svn.ref.svnmucc.re.html}<<<svnmucc>>> command}}:
+
+------------
+svnmucc -m "Publish yyy $version documentation" \
+ -U https://svn.apache.org/repos/asf/maven/website/components \
+ cp HEAD xxx-archives/yyy-LATEST xxx-archives/yyy-$version \
+ rm xxx/yyy \
+ cp HEAD xxx-archives/yyy-LATEST xxx/yyy
+------------
+
+* Updating index page in the Maven site
+
+ Some component types have an index page refering to each components of the same type. This is the case for
+ plugins (see {{{/plugins/}index}}), shared (see {{{/shared/}index}}), poms (see {{{/pom/}index}}) and
+ skins (see {{{/skins/}index}}).
+
+ Update the version number and release date for the component in the <<<content/apt/xxx/index.apt>>> page.
+
+ See {{{../website/deploy-maven-website.html}Deploy Maven website}} for more in-depth instructions on main
+ site content editing.
+
+ <<Notice>>: if you forget about updating the index page, dist-tool has a
+ {{{https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/}report run daily}}
+ that will gently send a failure notification on notifications@maven.a.o when "Check Errors" report is not empty.
diff --git a/content/apt/developers/website/deploy-maven-website.apt b/content/apt/developers/website/deploy-maven-website.apt
new file mode 100644
index 00000000..179e5365
--- /dev/null
+++ b/content/apt/developers/website/deploy-maven-website.apt
@@ -0,0 +1,117 @@
+ ------
+ Deploy Maven Main Website
+ ------
+ Barrie Treloar
+ Hervé Boutemy
+ ------
+ 2015-03-30
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction
+
+ This document gives step-by-step instructions for deploying the main Maven {{{/}https://maven.apache.org}} website.
+
+ <<Obsolete>> this documentation is obsolete: with the migration of site source to Git, Apache CMS is not used any more.
+ It is replaced by Git edit (eventually through GitHub with the "edit" link accessible from breadcrumb) followed
+ by Jenkins job to build and commit to svnpubsub.
+
+ See {{{./index.html}Maven website introduction}} for instructions on the whole website publication.
+
+
+Overview
+
+ Since December 2012, the overall website uses svnpubsub mechanism and the main website uses Apache CMS:
+
+[main-website.png] Main website mechanisms overview
+
+
+How main website publication works
+
+ Maven main website ({{https://maven.apache.org}}) is generated with {{{/plugins/maven-site-plugin}maven-site-plugin}} from a source tree
+ stored in svn: {{https://svn.apache.org/repos/asf/maven/site/trunk}}.
+
+
+* Edit source content
+
+ You can edit source content in 2 ways:
+
+ [[1]] use {{{https://cms.apache.org/maven/}the CMS UI}} through your web browser:
+
+ * Go to {{https://cms.apache.org/maven/}}.
+
+ * Click link "Get Maven Working Copy".
+
+ * Navigate to the content you want to modify.
+
+ * Once you have modified the content, commit with the button "Submit".
+
+ []
+
+ [[2]] checkout the source content locally, modify it with your favorite text editor, eventually test the result (<<<mvn site>>>), then check-in source modifications.
+
+ []
+
+ After source tree is modified in svn, {{{http://ci.apache.org/builders/maven-site-staging}a Buildbot job}} is triggered:
+
+ [[1]] it builds the HTML site using {{{/plugins/maven-site-plugin}maven-site-plugin}}: <<<mvn site>>>,
+
+ [[2]] it publishes generated HTML content to {{{https://svn.apache.org/repos/infra/websites/staging/maven/trunk/content/}CMS staging svn area}},
+
+ [[3]] svnpubsub mecanism transfers svn CMS staging content to live CMS staging site: {{http://maven.staging.apache.org}},
+
+ []
+
+
+* Publish site content
+
+ If everything is good, <<publish modifications>> using {{{https://cms.apache.org/maven/publish}CMS publish}} action.
+
+ Under the hood:
+
+ [[1]] CMS copies CMS staging svn area content to {{{https://svn.apache.org/repos/infra/websites/production/maven/content/}website production svn area}},
+
+ [[2]] svnpubsub mecanism transfers svn production content to live production site: {{http://maven.apache.org}}.
+
+ []
+
+
+How Doxia website publication works
+
+ Doxia uses the exact same mecanisms:
+
+ * you can edit {{{https://svn.apache.org/repos/asf/maven/doxia/site/trunk}svn source tree}} either locally or
+ through {{{https://cms.apache.org/maven-doxia/}CMS UI}},
+
+ * {{{http://ci.apache.org/builders/maven-doxia-site-staging}a Buildbot job}} builds the site and updates
+ {{{https://svn.apache.org/repos/infra/websites/staging/maven-doxia/trunk/content/}website staging svn area}},
+
+ * svnpubsub published to {{{http://maven-doxia.staging.apache.org}live staging site}},
+
+ * if everything is good, <<publish modifications>> using {{{https://cms.apache.org/maven-doxia/publish}CMS publish}} action,
+
+ * CMS copies CMS staging svn area content to {{{https://svn.apache.org/repos/infra/websites/production/maven-doxia/content/}website production svn area}},
+
+ * svnpubsub mecanism transfers svn production content to live production site: {{http://maven.apache.org/doxia}},
+ with its {{{/doxia/extpaths.txt}<<<extpaths.txt>>>}}
+
+ []
diff --git a/content/apt/developers/website/index.apt b/content/apt/developers/website/index.apt
new file mode 100644
index 00000000..a18de28b
--- /dev/null
+++ b/content/apt/developers/website/index.apt
@@ -0,0 +1,74 @@
+ ------
+ Deploy Maven Website
+ ------
+ Barrie Treloar
+ Hervé Boutemy
+ ------
+ 2013-09-23
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction
+
+ The Maven {{{https://maven.apache.org}https://maven.apache.org}} website is composed from:
+
+ * a main content,
+
+ * multiple components reference documentation, published for each component release.
+
+ []
+
+ And {{{https://maven.apache.org/doxia/}Doxia}} website has the same dual structure.
+
+ These contents are stored in svn, and svnpubsub/svnwcsub maintains a working copy on the webservers in <<</www/maven.apache.org/content>>>
+ (see {{{https://github.com/apache/infrastructure-puppet/blob/deployment/modules/svnwcsub/files/svnwcsub.conf#L123}<<<svnwcsub>>> configured in infra Puppet}}):
+
+ * <<</>>> comes from {{{https://svn.apache.org/viewvc/maven/website/content/}https://svn.apache.org/repos/asf/maven/website/content/}}
+
+ * {{{https://maven.apache.org/components}<<</components>>>}} comes from {{https://svn.apache.org/repos/asf/maven/website/components/}}
+
+ * <<</doxia>>> comes from {{{https://svn.apache.org/viewvc/maven/doxia/website/content/}https://svn.apache.org/repos/asf/maven/doxia/website/content/}}
+
+ * {{{https://maven.apache.org/doxia/components}<<</doxia/components>>>}} comes from {{https://svn.apache.org/repos/asf/maven/doxia/website/components/}}
+
+ []
+
+ and the link between main content and components reference documentation (for example from <<</plugins/maven-xxx-plugin>>> to internal <<</components/plugins/maven-xxx-plugin>>>)
+ is done with symbolic links. These links are configured in <<<components.links>>> files in <<<content/resources/>>> and subdirectories,
+ for example {{{https://github.com/apache/maven-site/blob/master/content/resources/plugins/components.links}plugins/components.links}}.
+
+How website publication works
+
+ Instructions on how to publish website content are split in separate documents:
+
+ * on every main content source commit ({{{https://github.com/apache/maven-site}maven-site.git}}
+ and {{{https://github.com/apache/maven-doxia-site}maven-doxia-site.git}}),
+ main content rebuild and publish is triggered through Jenkins jobs (
+ {{{https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-site/}maven-site job}}
+ and {{{https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-doxia-site/}doxia-site job}}),
+ which basically run <<<mvn site-deploy>>> (it can be run locally if CI is off...),
+
+ * on every Maven component release, release manager follows "{{{./deploy-component-reference-documentation.html}deploying Maven components reference documentation}}",
+ eventually using {{{./component-reference-documentation-helper.html}Component Reference Documentation Helper}} to
+ easily prepare <<<svnmucc>>> command line.
+
+ []
diff --git a/content/apt/developers/website/website-overview.apt b/content/apt/developers/website/website-overview.apt
new file mode 100644
index 00000000..63e11968
--- /dev/null
+++ b/content/apt/developers/website/website-overview.apt
@@ -0,0 +1,43 @@
+ ------
+ Deploy Maven Website
+ ------
+ Barrie Treloar
+ Hervé Boutemy
+ ------
+ 2013-09-23
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction
+
+ The Maven {{{/}https://maven.apache.org}} website is composed from:
+
+ * a main content
+
+ * multiple components reference documentation
+
+ []
+
+[website-overview.png] Website mechanisms overview
+
+
+ See {{{./index.html}Maven website introduction}} for instructions on website publication.
diff --git a/content/markdown/developers/website/website-overview.odg b/content/apt/developers/website/website-overview.odg
similarity index 100%
rename from content/markdown/developers/website/website-overview.odg
rename to content/apt/developers/website/website-overview.odg
diff --git a/content/apt/developers/welcome-to-new-committers.apt b/content/apt/developers/welcome-to-new-committers.apt
new file mode 100644
index 00000000..ad1400d4
--- /dev/null
+++ b/content/apt/developers/welcome-to-new-committers.apt
@@ -0,0 +1,70 @@
+ ------
+ Guide for new Maven committers
+ ------
+ The Maven Team
+ ------
+ 2006-04-03
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Guide for new Maven committers
+
+ First of all congratulations, thank you, and welcome to the fold! If you are reading this
+ you've recently been voted in as committer on an Apache Maven project and there are a few things
+ that need to be sorted out before you can participate fully.
+
+ The first thing to get out of the way is sending in your contributor's license agreement (CLA). You
+ can't participate at Apache until we have received your signed CLA, so go to the {{{http://www.apache.org/licenses/#clas}Apache website}},
+ print out the CLA, sign it, and send it in ASAP.
+
+ Once you've dealt with your CLA, there are a some documents that pertain to Apache as a whole you should
+ read:
+
+ * {{{http://www.apache.org/foundation/how-it-works.html}How the ASF works}}
+
+ * {{{http://www.apache.org/dev/new-committers-guide.html}Guide for new committers}}
+
+ * {{{http://www.apache.org/dev/committers.html}The committers FAQ}}
+
+ * {{{http://www.apache.org/foundation/voting.html}How voting works}}
+
+ []
+
+ Here are the documents that pertain to Maven specifically:
+
+ * {{{/guides/development/guide-maven-development.html}Guide to Maven development}}
+
+ * {{{/developers/committer-environment.html}Setup your committer environment}}
+
+ []
+
+ And here are the specifics on setting up your Git access:
+
+ * {{{http://www.apache.org/dev/version-control.html}Apache's Source Code Repository}}
+
+ []
+
+ If you have any questions just ask! We're here to help, and looking forward to working with you!
+
+ The Maven Team!
+
+
diff --git a/content/apt/examples/index.apt b/content/apt/examples/index.apt
new file mode 100644
index 00000000..ef4d66ef
--- /dev/null
+++ b/content/apt/examples/index.apt
@@ -0,0 +1,35 @@
+ ---
+ Summary of Maven Examples
+ ---
+ John Casey
+ ---
+ 2009-08-02
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Examples
+
+ * {{{./injecting-properties-via-settings.html}Injecting POM Properties via settings.xml}}
+
+ * {{{./maven-3-lifecycle-extensions.html}Maven 3 lifecycle extensions}}
+
+ []
diff --git a/content/apt/examples/injecting-properties-via-settings.apt b/content/apt/examples/injecting-properties-via-settings.apt
new file mode 100644
index 00000000..09498baa
--- /dev/null
+++ b/content/apt/examples/injecting-properties-via-settings.apt
@@ -0,0 +1,84 @@
+ ---
+ Example: Injecting POM Properties via Settings.xml
+ ---
+ John Casey
+ ---
+ 2006-04-20
+ ---
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Example: Injecting POM Properties via Settings.xml
+
+* Impetus
+
+ You have a plugin parameter that should contain a user-specific value. This
+ parameter has a common format (relative directory structure), but depends on
+ knowing the directory of the installed application or something.
+
+* Plugin Configuration
+
++---+
+<project>
+ [...]
+ <build>
+ <plugins>
+ <plugin>
+ <groupId>org.myproject.plugins</groupId>
+ <artifactId>my-cool-maven-plugin</artifactId>
+ <version>1.0</version>
+ <configuration>
+ <deploymentDirectory>${application-home}/deploy</deploymentDirectory>
+ </configuration>
+ </plugin>
+ </plugins>
+ </build>
++---+
+
+* <<<settings.xml>>>
+
++---+
+<settings>
+ [...]
+ <profiles>
+ <profile>
+ <id>inject-application-home</id>
+ <properties>
+ <application-home>/path/to/application</application-home>
+ </properties>
+ </profile>
+ </profiles>
+
+ <activeProfiles>
+ <activeProfile>inject-application-home</activeProfile>
+ </activeProfiles>
+</settings>
++---+
+
+* Explanation
+
+ When Maven loads the project's POM, it will pickup the activated profiles from
+ the <<<activeProfiles>>> section of the <<<settings.xml>>> file, and inject the
+ properties declared within the profile. When the POM is interpolated, the
+ <<<application-home>>> property will already have been injected, so will allow
+ the plugin's parameter value to be resolved.
+
+
diff --git a/content/apt/guides/development/guide-building-maven.apt b/content/apt/guides/development/guide-building-maven.apt
new file mode 100644
index 00000000..ce8bc8f3
--- /dev/null
+++ b/content/apt/guides/development/guide-building-maven.apt
@@ -0,0 +1,92 @@
+ ------
+ Guide to Building Maven
+ ------
+ Brett Porter
+ Jason van Zyl
+ ------
+ 2015-01-04
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Building Maven
+
+* Why would I want to build Maven?
+
+ Building Maven (or a plugin, or any component) yourself is for one of two reasons:
+
+ * to try out a bleeding edge feature or bugfix (issues can be found in
+ {{{/issue-management.html} JIRA}}),
+
+ * to fix a problem you are having and submit a patch to the developers team.
+
+* Checking out the sources
+
+ All of the source code for Maven and its related libraries is in managed in the ASF source code
+ repositories: for details, see {{{/scm.html}https://maven.apache.org/scm.html}}.
+
+* Building Maven
+
+** Building a Maven Plugin or Component
+
+ Building a Maven plugin or component is like any Maven build:
+
+-------
+mvn install
+-------
+
+*** Running Integration Tests
+
+ Before submitting a patch, it is advised to run the integration tests, which are available in the <<<run-its>>> profile:
+
+-------
+mvn -Prun-its install
+-------
+
+** Building Maven core
+
+ Until Maven 3.3, Maven core build could be boostrapped with an Ant build. This bootstrap has been removed in Maven 3.5:
+ you need a pre-built Maven to build Maven from source.
+
+ To do this, run from the source directory:
+
+-------
+mvn install
+-------
+
+ The assemblies will be created in <<<apache-maven>>>, and can be manually unzipped to the location where you'd like the resulting Maven installed.
+
+ If you want to have the resulting Maven directly copied to a directory, you can use the <<<distributionTargetDir>>> property:
+
+-------
+mvn -DdistributionTargetDir="$HOME/app/maven/apache-maven-SNAPSHOT" install
+-------
+
+*** Running the full Maven core integration tests
+
+ Before checking in a change or submitting a patch to Maven core, it is required to run the core integration tests.
+ Using your local build of Maven, run:
+
+-------
+mvn test -Prun-its
+-------
+
+ Consult {{{/core-its/}Core ITs documentation}} for more options.
diff --git a/content/apt/guides/development/guide-committer-school.apt b/content/apt/guides/development/guide-committer-school.apt
new file mode 100644
index 00000000..6c6aa22c
--- /dev/null
+++ b/content/apt/guides/development/guide-committer-school.apt
@@ -0,0 +1,157 @@
+ ------
+ Do you want to become a Maven Committer?
+ ------
+ Stephen Connolly
+ Robert Scholte
+ ------
+ 2012-07-11
+ 2017-07-21
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+~~ Original post: http://javaadventure.blogspot.nl/2012/07/do-you-want-to-become-maven-committer.html
+
+Do you want to become a Maven Committer?
+
+ The Apache Software Foundation is a meritocracy. By this we mean that you gain status based on the merit of your work and actions.
+ In fact the status that you gain is a recognition of the merit of your work and actions.
+
+ Maven is an Apache project, that means that we have to follow the Apache rules and way.
+ One of those rules is that we cannot hand out commit access to anyone who asks for it.
+
+ To gain commit access you must establish your merit by submitting patches that get picked up by existing committers.
+
+ After you have contributed enough patches to establish merit, the project management committee decides whether you can be trusted with commit access.
+
+ <The reality is that "It is what it is"TL;DR To become a Maven committer write good patches and get them applied.>
+
+What makes a good patch?
+
+ A good patch is a patch that applies cleanly and includes tests that cover both the positive and negative case and has documentation where relevant.
+
+ For example, if you were implementing a patch to fix {{{http://issues.apache.org/jira/browse/MNG-4612}MNG-4612}} you would first need to write a test case that is failing when trying to encrypt
+
+---
+{DESede}y+qq...==
+---
+
+ and a second test case that is passing when trying to encrypt
+
+---
+password
+---
+
+ This is in order to be sure that you have written an effective test case that can pass for good data.
+ Then you implement the fix and all the tests should pass.
+ You then take a Subversion compatible† diff of the source code and attach that to the issue in question.
+
+ To understand how your patch gets evaluated, here is how I apply patches:
+
+ [[1]] I look at the actual diff, if there is a whole lot of formatting changes irrelevant to the issue being fixed => <<Patch is no good, ask on JIRA for a clean patch>>
+
+ [[1]] I look at the list of files in the diff, if there are no tests => <<Patch is no good, ask on JIRA for test cases>>
+
+ [[1]] I look at the issue and if the issue requires documentation be updated and there is no documentation changes in the patch => <<Patch is no good, ask on JIRA for documentation changes in the patch>>
+
+ [[1]] I take a clean checkout of the source that the patch applies to and try to apply the patch... if it does not apply clean => <<Patch is no good, ask on JIRA for an updated patch>>
+
+ [[1]] I revert the src/main and run the tests. If the tests all pass, then there are no test cases to catch the bug => <<Patch is no good, ask on JIRA for proper tests>>
+
+ [[1]] I revert src and run the tests. If any tests fail, then there is something wrong with the existing code => <<If I have time I might try and fix the issue, otherwise I just move on>>
+
+ [[1]] I apply the patch a second time and run the tests. If the tests all pass => <<Patch is good, I commit the patch and mark the JIRA as resolved>>
+
+ []
+
+ So there you have it, my guide to writing good patches... now the next step is getting your patches noticed...
+
+How to get your patches noticed
+
+ The simplest way to get your patches noticed is to submit them to the JIRA issue that they fix.
+
+ Remember that the Maven project is run by volunteers in their spare time, so very often we may not notice your patch for a few days.
+
+ If you are certain that your patch is a good patch, and a week has passed with no comments on JIRA, then you should send <one and only one> email to the {{{mailto:dev@maven.apache.org}dev@maven.apache.org}} mailing list to see if your patch can get noticed.
+
+ <<Note:>> you need to be fairly confident that your patch is a good patch, because if you keep on pestering the Maven developers looking to have non-good patches applied, your merit will become negative and people will be less inclined to help you get your patches applied...
+ also this is why you should send one and <only one> email about your patch on any specific JIRA issue.
+
+Stephen, Arnaud & Barrie's school for potential Maven committers
+
+ To help people who are interested in becoming Maven committers fulfill their goals, myself, Arnaud Heritier and Barrie Treloar (along with any other current Maven committers who decide to help) will be running an assignment based class to help people become committers.
+
+ To register for the class you need to complete the following steps:
+
+ [[1]] Read the {{{http://www.apache.org/licenses/icla.txt}Apache Individual Contributor License Agreement}}. When you graduate from the class you will be required to sign this in order to become a committer.
+
+ [[1]] Subscribe to the {{{mailto:dev@maven.apache.org}dev@maven.apache.org}} mailing list.
+
+ [[1]] Send an email to the list with the Subject line: <<<[Committer School] I would like to become a committer>>> and the Message body:
+
+---
+I am interested in the following areas:
+ _______, _______ and ______
+If anyone knows any issues that I could take a look at I would be very much appreciated
+
+Thanks
+---
+
+ []
+
+ Once you have registered your class assignments are basically to find JIRA issues that you want to fix.
+ The issues can be in any part of Maven, but it is best to start with the areas you have the most interest in.
+ Once you have found a JIRA issue that you are interested in fixing, the process will work a little something like this:
+
+ [[1]] Make sure that nobody else is working on the issue and that the issue is one that should be fixed by sending an email to the list with a Subject line something like:
+ <<<[Committer School] Should I fix MNG-4612?>>>
+ The Message body should be something like:
+
+---
+I have had a look at MNG-4612 and I think this is a real issue because...
+
+I think I can fix it like so....
+
+Is that the correct way to go about fixing it and is it a real issue at all
+
+Thanks
+---
+
+ [[1]] Wait a couple of days. Arnaud, Barrie and I will do our best to respond quickly to all such emails, but please keep in mind that we are doing this in our spare time.
+
+ [[1]] If you get the all clear, develop your patch and upload it to the JIRA, after it is uploaded, send an email to the list with a subject line something like:
+ <<<[Committer School] Patch for review: MNG-4612>>> The Message body should be something like:
+
+---
+I have tested that this is a good patch and I would appreciate if a committer could review and apply
+
+Thanks
+---
+
+ []
+
+ Keep in mind that the Committer School is just a way for us to identify people who are committed to developing patches with a view to eventually becoming committers.
+
+ When we have enough evidence that we think we can get you accepted as a committer we will nominate you and hopefully your nomination will be accepted.
+
+ Personally, if I see somebody averaging a good patch a week for 2-3 months and being active helping out on the {{{mailto:users@maven.apache.org}users@maven.apache.org}} and {{{mailto:dev@maven.apache.org}dev@maven.apache.org}} mailing lists then I think I could make a strong case for such a person being given commit access.
+
+ So if you think you have the right stuff and want to become a Maven committer... class enrollment is open!
\ No newline at end of file
diff --git a/content/apt/guides/development/guide-documentation-style.apt b/content/apt/guides/development/guide-documentation-style.apt
new file mode 100644
index 00000000..09817584
--- /dev/null
+++ b/content/apt/guides/development/guide-documentation-style.apt
@@ -0,0 +1,136 @@
+ ------
+ Guide To Maven Documentation Style
+ ------
+ Dennis Lundberg
+ ------
+ 2008-07-12
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Guide To Maven Documentation Style
+
+* Where did the style came from?
+
+ The documentation style guide was created to make our documentation more
+ consistent and also to apply best practices to the documentation as well.
+ The standard has just been started and will expand over time based on the
+ suggestions made on the Maven dev mailing list. It is a community consensus
+ of how we should write our documentation.
+
+ Each rule in this guide should come with a motivation as to why it exists.
+ References to external sources are encouraged.
+
+* Date format
+
+ How people format a date varies around the world, sometimes making it hard
+ for people to understand each other. The solution to this problem comes in
+ the form of the ISO-8601 standard.
+
+ A date in our documentation must follow this standard:
+
+ <<YYYY-MM-DD>>
+
+ where <<YYYY>> is the year in the Gregorian calendar, <<MM>> is the month of
+ the year between 01 (January) and 12 (December), and <<DD>> is the day of the
+ month between 01 and 31.
+
+ <<Note>>: All documentation meta-data should respect this convention, for instance for this given APT document:
+
+-------
+ ------
+ Guide To Maven Documentation Style
+ ------
+ Dennis Lundberg
+ ------
+ 2008-07-03
+ ------
+-------
+
+** References
+
+ * {{{http://www.w3.org/QA/Tips/iso-date}W3C Quality Web Tips}}
+
+ * {{{http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26780}ISO-8601}}
+
+ * {{{http://en.wikipedia.org/wiki/ISO_8601}Wikipedia}}
+
+ []
+
+~~ NOTE: Add more rules here. Follow the heading style of the rule above.
+
+* POM Snippet
+
+ A POM file must use 2 spaces for each indentation. Because POM snippets are
+ often used in documentation to show the user how to configure something, it is
+ important that these snippets aren't too wide. If they are too wide,
+ the page is difficult to read on a smaller screen.
+
+ When you use a snippet of XML from the POM as an example in
+ documentation, make sure that the example is properly indented.
+ A user should be able to copy and paste the example into their own POM without
+ changing the indentation.
+
+ Also, you should declare all parent POM elements to improve the comprehension. You could use ellipsis (i.e. ...) if
+ you don't want to specify elements.
+
+** Example
+
+ The following is an example of how the distribution management of the Maven
+ site is configured.
+
++-----+
+<project>
+ ...
+ <distributionManagement>
+ <site>
+ <id>apache.website</id>
+ <url>scp://people.apache.org/www/maven.apache.org/</url>
+ </site>
+ </distributionManagement>
+ ...
+</project>
++-----+
+
+ As you can see above the <<<\<distributionManagement\>>>> element is indented
+ once (=2 spaces), the <<<\<site\>>>> element is indented twice (=4 spaces), and
+ the <<<\<id\>>>> is indented three times (=6 spaces).
+
+* Naming Documentation Files
+
+ All file names should replace space by a hyphen (-), for instance for this given APT document:
+
+-------
+ guide-documentation-style.apt
+-------
+
+* Updating Documentation Files
+
+ A good practice is to update the date (with the correct date format) when you are updating documentation files.
+
+* Write Thinking
+
+ Here are some pointers about English rules when typing material:
+
+ * {{{https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style}Wikipedia:Manual of Style}}, specifically
+ {{{https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Punctuation}Punctuation Part}}
+
+ []
diff --git a/content/apt/guides/development/guide-helping.apt b/content/apt/guides/development/guide-helping.apt
new file mode 100644
index 00000000..82c2237c
--- /dev/null
+++ b/content/apt/guides/development/guide-helping.apt
@@ -0,0 +1,106 @@
+ ------
+ Guide to helping with Maven
+ ------
+ Brett Porter
+ Jason van Zyl
+ ------
+ 2008-07-03
+ 2015-06-16
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Guide to helping with Maven
+
+ As with any open source project, there are several ways you can help:
+
+ * Join the {{{../../mailing-lists.html}mailing lists}} and answer other user's questions.
+
+ * Report bugs, feature requests and other issues in the {{{../../issue-management.html}issue management system}}.
+
+ * {{{./guide-building-maven.html} Build Maven}} for yourself, in order to fix bugs.
+
+ * {{{./guide-maven-development.html#Creating_and_submitting_a_patch}Submit patches}} to reported issues (both those you find,
+ or that others have filed)\
+ To ease your first contribution, we have a {{{https://s.apache.org/for-the-grabs_maven}list of "up for grabs" issues}}, meaning that they should be easy to work on.
+
+ * {{{./guide-testing-releases.html} test releases}} help test releases that are being voted on (see the dev@maven.apache.org {{{../../mailing-lists.html} mailing list}} for release votes)
+
+ * {{{./guide-testing-development-plugins.html} test snapshot plugins}} help test the latest development versions of plugins and report issues
+
+ * Help with the documentation by pointing out areas that are lacking or unclear, and if you can, submitting Pull Requests to correct it:
+ use the "edit" button in the breadcrumb, just after the page title.
+ You can also create appropriate issues {{{https://issues.apache.org/jira/browse/MNGSITE}by using the issue management system}}.
+
+ []
+
+ Your participation in the community is much appreciated!
+
+Why Would I Want to Help?
+
+ There are several reasons these are good things.
+
+ * By answering other people's questions, you can learn more for yourself
+
+ * By submitting your own fixes, they get incorporated faster
+
+ * By reporting issues, you ensure that bugs don't get missed, or forgotten
+
+ * You are giving back to a community that has given you software for free
+
+ []
+
+How do I Join the Project?
+
+ Projects at Apache operate under a meritocracy, meaning those that the developers notice participating to a
+ high extent will be invited to join the project as a committer.
+
+ This is as much based on personality and ability to work with other developers and the community as it is with
+ proven technical ability. Being unhelpful to other users, or obviously looking to become a committer for bragging
+ rights and nothing else is frowned upon, as is asking to be made a committer without having contributed
+ sufficiently to be invited.
+
+Developers Conventions
+
+ There are a number of conventions used in the project, which contributors and developers alike should follow for
+ consistency's sake.
+
+ * {{{../../developers/conventions/code.html}Maven Code Style And Convention}}
+
+ * {{{../../developers/conventions/jira.html}Maven Jira Convention}}
+
+ * {{{../../developers/conventions/git.html}Maven Git Convention}}
+
+ * {{{../../developers/release/index.html}Releasing a Maven project}}
+
+ * {{{https://cwiki.apache.org/confluence/display/MAVEN/Index}Apache Maven Wiki}}
+
+ []
+
+Resources for committers
+
+ * {{{http://www.apache.org/dev/} Developer Resources}}
+
+ * {{{http://www.apache.org/foundation/} About the Apache Software Foundation}}
+
+ * {{{http://www.apache.org/dev/committers.html} Committer FAQ}}
+
+ []
diff --git a/content/apt/guides/development/guide-maven-development.apt b/content/apt/guides/development/guide-maven-development.apt
new file mode 100644
index 00000000..1b919b67
--- /dev/null
+++ b/content/apt/guides/development/guide-maven-development.apt
@@ -0,0 +1,197 @@
+ ------
+ Guide to Developing Maven
+ ------
+ Emmanuel Venisse
+ Trygve Laugstol
+ Brett Porter
+ Maarten Mulders
+ ------
+ 2019-06-04
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Developing Maven
+
+ This document describes how to get started developing Maven itself. There is a separate page describing how
+ to {{{./guide-building-maven.html}build Maven}}.
+
+* Finding some work to do
+
+ First of all you need something to work on! Issues can be found in
+ {{{/issue-management.html}several JIRA projects}}.
+
+ Another good place to look for work is the {{{https://s.apache.org/up-for-grabs_maven} Up for grabs}} list.
+ This list contains relatively simple issues that can be worked on without a lot of prerequisite knowledge.
+
+ When you find a issue you would like to work on, add a comment in the issue log so the core developers and other
+ people looking for work know that someone is already working on it.
+
+* Where's the source?
+
+ See {{{/scm.html}https://maven.apache.org/scm.html}} for information.
+ The Maven project uses the Apache GitBox Repositories, and all of them are dual-mirrored to
+ {{{https://github.com/apache/} GitHub}}.
+
+* Don't forget tests!
+~~ TODO move details to guide-building-maven.apt, keep only principles here
+
+ You will find many unit tests. If at all possible, create or modify a unit test to demonstrate
+ the problem, and then validate your fix.
+
+ If you need to mock a class to write a test, use the Mockito framework.
+ Parts of the Maven codebase predate Mockito so you will encounter existing tests
+ that use EasyMock, PowerMock, and JMock. However, all newly written mocks
+ should use Mockito, even if this means a module or a single class
+ uses multiple mocking frameworks. If an existing test class has complicated
+ legacy mock setup, you can add new Mockito based tests in a new test class.
+ There is no requirement that all tests for a single model class must be in
+ the same test class. It is OK to have multiple test classes per model class.
+
+ If the problem case can't be set up in the unit tests, add an integration test. Before submitting a patch, in any
+ case, you should run all of the integration tests. The tests require an empty local repository.
+ See {{{/core-its/core-it-suite/}Core IT Suite documentation}} for more details.
+
+* {Creating and submitting a patch}
+
+ The most convenient way is to create a GitHub fork from the Git repository you are working with.
+ When you have either completed an issue or just want some feedback on the work you have done, create a pull request.
+ We have a couple of guidelines when submitting contributions:
+
+ * Verify the status of the <<<master>>> branch on {{{https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-master-jobs.html}Maven CI}}.
+ If it is not SUCCCESS, then first try to figure out the problem, don't start with your own issue yet! You can use <<<git bisect>>> to figure out the problematic commit and help
+ with that committer to solve the problem.
+
+ * Create your branch from <<<master>>>, not from a tag. Otherwise, your patch is outdated the moment you create it and might not be applicable
+ to the development head.
+
+ * If this was a new piece of work without a JIRA issue, create a JIRA issue for it now.
+
+ * Name the branch after the issue number; the branch name would start with <<<\<jira-project-id>-<ticket-id\>>>>.
+
+ * Push your branch with the commit(s) to your fork.
+
+ * Create a {{{https://help.github.com/en/articles/about-pull-requests} pull request}} to submit your contribution.
+ Shortly after, someone will review the pull request and give you feedback on it.
+
+ []
+
+ A short note:
+
+ * Make sure that you follow our code style, see {{{Further_Links}Further Links}}.
+
+ []
+
+* Pull request acceptance criteria
+
+ There are a number of criteria that a pull request will be judged on:
+
+ * Whether it works and does what is intended. This one is probably obvious!
+
+ * Whether it fits the spirit of the project. Some pull requests may be rejected as they take the project in a different
+ direction than the current development community has chosen. This is usually discussed on an issue well
+ before a pull request is contributed, so if you are unsure, discuss it there or on the mailing lists first. Feel free to
+ continue discussing it (with new justification) if you disagree, or appeal to a wider audience on the mailing lists.
+
+ * Whether it contains tests. It is expected that any pull request relating to functionality will be accompanied by unit tests
+ and/or integration tests. It is strongly desired (and will be requested) for bug fixes too, but will not be the basis
+ for not applying it. At a bare minimum, the change should not decrease the amount of automated test coverage.
+ As a community, we are focusing on increasing the current coverage, as there are several areas that do not receive automated testing.
+
+ * Whether it contains documentation. All new functionality needs to be documented for users, even if it is very rough
+ for someone to expand on later. While rough is acceptable, incomplete is not. As with automated testing, as a community
+ we are striving to increase the current coverage of documentation.
+
+ []
+
+ Above all, don't be discouraged. These are the same requirements the current committers should hold each other to as well.
+ And remember, your contributions are always welcome!
+
+* Related Projects
+
+ Maven has a few dependencies on other projects:
+
+ * <<Plexus>>
+
+ Plexus is a full-fledged container supporting different kinds of component lifecycles. Its native lifecycle
+ is like any other modern IoC container, using field injection of both requirements and configuration. All
+ core Maven functionality are Plexus components.
+
+ You can {{{https://codehaus-plexus.github.io/}read more about Plexus}}.
+
+ * <<Modello>>
+
+ Modello is a simple tool for representing an object model and generating code and resources from the model.
+ Maven uses Modello to generate all Java objects, XML readers and writers, XML Schema, and HTML documentation.
+
+ You can {{{https://codehaus-plexus.github.io/modello/}read more about Modello}}.
+
+ * <<Mojo>>
+
+ "Mojo" is really two things when it comes to Maven: it is both {{{/ref/current/maven-plugin-api/}Maven's plug-in API}}
+ and also {{{http://www.mojohaus.org}a separate Mojohaus project}} hosting a lot of plugins.
+
+ {{{http://www.mojohaus.org}The MojoHaus Project}} is a plugin forge for non-core Maven plugins.
+ There is also a lower bar for becoming a part of the project.
+
+ []
+
+* Sub Projects
+
+ ** <<Maven Surefire>>
+
+ Surefire is a testing framework. It can run regular JUnit tests so you won't have to change anything in your code to
+ use it. It supports scripting tests in BeanShell and Jython and has special "batteries" for writing acceptance and
+ functional tests for the web and for testing XML-RPC code.
+
+ You can {{{/surefire/}read more about Surefire}}.
+
+ ** <<Maven Doxia>>
+
+ Doxia is Maven's documentation engine. It has a sink and parser API that can be used to plug in support for input
+ and output documents.
+
+ You can read more about {{{/doxia/}Doxia}} and the currently supported
+ {{{/doxia/references/index.html}document formats}}.
+
+
+ ** <<Maven SCM>>
+
+ Maven SCM (Source Control Management) is a reusable API which is independent of Maven itself. It is used by the
+ SCM related Maven Plugins. The core part of Maven doesn't depend on Maven SCM.
+
+ You can {{{/scm/}read more about Scm}}.
+
+ ** <<Maven Wagon>>
+
+ Maven Wagon is a standalone API that dealt with transporting files and directories in Maven 2.x. Maven Core today
+ uses the Resolver Transport API, that among other implementations, contains a wrapper for Wagon as well.
+ Also, the site plug-in uses it to publish the site.
+
+ You can {{{/wagon/}read more about Wagon}}.
+
+* {Further Links}
+
+ * {{{../../developers/conventions/code.html}Maven Code Style And Code Convention}}
+
+ * {{{../../developers/conventions/jira.html}Maven JIRA Convention}}
+
+ []
diff --git a/content/apt/guides/development/guide-plugin-documentation.apt b/content/apt/guides/development/guide-plugin-documentation.apt
new file mode 100644
index 00000000..3a7f4cae
--- /dev/null
+++ b/content/apt/guides/development/guide-plugin-documentation.apt
@@ -0,0 +1,410 @@
+ ------
+ Guide to the Plugin Documentation Standard
+ ------
+ Maven Team
+ ------
+ 2006-07-06
+ ------
+
+Introduction
+
+*Where did the standard come from?
+
+ The plugin documentation standard was created to address the frequent complain of lack of
+ documentation, specifically on the Maven plugins. The standard was based on the suggestions made
+ on the Maven dev mailing list with some refinements. It is a community consensus of what basic
+ documentation a Maven plugin should have.
+
+*Why do we need a documentation standard?
+
+ The standard is not a set of rules but a guide to help plugin developers document their plugins
+ better, for the benefit of the users of the plugin. The standard also reminds the plugin developers
+ of the important details that needs to be documented, to help speed up the adoption of the plugin.
+
+Generated Documentation
+
+ It is recommended that you let Maven generate the basic information for the plugin to make sure that
+ that the basic information is always accurate and synchronized with the plugin implementation.
+
+ Documentation is generated by running
+
+-----------------
+mvn site
+-----------------
+
+ It will generate a plugin site based on the information in the POM, <<<src/site>>> and other reporting
+ plugins configured in the POM. The most important reporting plugin is the
+ {{{/plugins/maven-plugin-plugin/}Maven Plugin Plugin}} which will generate
+ the documentation for each plugin goal based on the mojo annotations. But in order for the generated site to be
+ usable, the required information should be available to the Maven Site Plugin.
+
+*POM Elements
+
+ Maven extracts the information from the POM to generate the pages under Project Information.
+ The first step in having a good documentation is to have an accurate and visible basic project
+ information, Maven can provide this for the plugin as long as the information in the POM is
+ complete, descriptive and accurate.
+
+**Required Elements
+
+ Minimum elements for a valid POM:
+
+ * <<<\<modelVersion\>>>> - POM model version, currently 4.0.0
+
+ * <<<\<groupId\>>>> - the package name
+
+ * <<<\<artifactId\>>>> - artifact name
+
+ * <<<\<packaging\>>>> - type of artifact produced by the POM
+
+ * <<<\<version\>>>> - the plugin version
+
+**Optional Elements
+
+ These might be optional elements in a valid POM but they are important basic project information
+ required by the users to effectively use the plugin:
+
+ * <<<\<name\>>>> - plugin's name, <Maven NNN Plugin> for plugins hosted at the Maven project or
+ <NNN Maven Plugin> for all others
+
+ * <<<\<description\>>>> - project description, an overview of what the plugin can do
+
+ * <<<\<url\>>>> - the site of the plugin, normally <maven.apache.org> or <org.mojohaus>
+
+ * <<<\<prerequisites\>>>> - the minimum version of Maven required to use this plugin
+
+ * <<<\<issueManagement\>>>> - describes the system used for reporting problems and modification requests
+
++--------------+
+<project>
+ [...]
+ <issueManagement>
+ <system>jira</system>
+ <url>http://jira.someproject.org</url>
+ </issueManagement>
+ [...]
+</project>
++--------------+
+
+ * <<<\<inceptionYear\>>>> - year the plugin was first created
+
+ * <<<\<mailingLists\>>>> - lists where other users or the developers can be contacted for help and discussions
+
++--------------+
+<project>
+ [...]
+ <mailingLists>
+ <mailingList>
+ <name>Project users</name>
+ <post>announce@noonecares.com</post>
+ <subscribe>users-subscribe@noonecares.com</subscribe>
+ <unsubscribe>users-unsubscribe@noonecares.com</unsubscribe>
+ <archive>http://noonecares.archive.org</archive>
+ </mailingList>
+ <mailingList>
+ [...]
+ </mailingList>
+ </mailingLists>
+ [...]
+</project>
++--------------+
+
+ * <<<\<licenses\>>>> - plugin license
+
++--------------+
+<project>
+ [...]
+ <licenses>
+ <license>
+ <name>Apache License, Version 2.0</name>
+ <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
+ <distribution>repo</distribution>
+ </license>
+ </licenses>
+ [...]
+</project>
++--------------+
+
+ * <<<\<scm\>>>> - the source code management configuration - a plugin without this would raise suspicion, might not be OSS
+
++--------------+
+<project>
+ [...]
+ <scm>
+ <connection>scm:svn:http://noonecares.com/some/plugin/project/trunk</connection>
+ <developerConnection>scm:svn:https://noonecares.com/some/plugin/project/trunk</developerConnection>
+ <url>http://noonecares.com/viewvc/some/project/trunk/</url>
+ </scm>
+ [...]
+</project>
++--------------+
+
+ * <<<\<organization\>>>> - the organization maintaining the plugin, just in case we need someone to blame
+
++--------------+
+<project>
+ [...]
+ <organization>
+ <name>Noone Care Software Foundation</name>
+ <url>http://noonecare.org/</url>
+ </organization>
+ [...]
+</project>
++--------------+
+
+*Plugin Configuration Parameters
+
+ The Maven Plugin Plugin is responsible for generating the Plugin Info site and needs to be added to the <<<\<reporting\>>>>
+ section unless it is already inherited from a parent POM:
+
++--------------+
+<project>
+ [...]
+ <reporting>
+ <plugins>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-plugin-plugin</artifactId>
+ <version>2.5.1</version>
+ </plugin>
+ </plugins>
+ </reporting>
+ [...]
+</project>
++--------------+
+
+ The comments, annotations and plugin parameter
+ names are extracted from the plugin source and rendered in the Plugin Info page. In order for the generated site to
+ be useful here are some guidelines you can follow when documenting your plugin.
+
+ * all <<<...@parameter>>> fields should have a descriptive comment, informative enough that even a regular user can understand
+
++--------------+
+ [...]
+ /**
+ * Put something informative here that a regular user can understand.
+ *
+ * @parameter
+ */
+ private boolean someparameter;
+ [...]
++--------------+
+
+ * class level comment should explain what the goal does
+
++--------------+
+[...]
+/**
+ * Everything here will show up on the top of the generated plugin info page.
+ *
+ * @goal somegoal
+ * @phase compile
+ */
+public class ExampleMojo
+ extends AbstractWarMojo
+{
+ public void execute()
+ throws MojoExecutionException, MojoFailureException
+ {
+[...]
++--------------+
+
+ * the <<<...@component>>> and <<<...@readonly>>> parameters are not required to have any comments but it's still a good practice to provide one
+
+*Site Organization
+
+ Visibility of the information is also crucial, having uniform navigation links will greatly improve the visibility of the
+ documentations. The index page can also help emphasize important sections and pages of the plugin documentation.
+
+**Site Descriptor
+
+ The site descriptor describes the navigation links and can be found in <<<src/site/site.xml>>>. Below is the suggested site
+ descriptor template.
+
++--------------+
+<?xml version="1.0" encoding="UTF-8"?>
+<project>
+ <body>
+ <menu name="Overview">
+ <item name="Introduction" href="index.html"/>
+ <item name="Goals" href="plugin-info.html"/>
+ <item name="Usage" href="usage.html"/>
+ <item name="FAQ" href="faq.html"/>
+ </menu>
+
+ <menu name="Examples">
+ <item name="description1" href="examples/example-one.html"/>
+ <item name="description2" href="examples/example-two.html"/>
+ </menu>
+ </body>
+</project>
++--------------+
+
+***Navigation Links
+
+ * Introduction
+
+ The introduction is the front page of the plugin documentation. This is a good place to place any section and pages that needs
+ to be emphasized. It is also suggested that the generated plugin parameter configuration be linked here. Below is the suggested
+ <<<src/site/apt/index.apt>>> template
+
+----------------
+ ------
+ Introduction
+ ------
+ Author
+ ------
+ YYYY-MM-DD
+ ------
+
+
+Plugin Name
+
+ Plugin introduction, description, and other relevant information.
+
+* Goals Overview
+
+ General information about the goals.
+
+ * {{{<goal>.html}prefix:goal}} short description for this plugin goal.
+
+* Usage
+
+ General instructions on how to use the Plugin Name can be found on the {{{usage.html}usage page}}. Some more
+ specific use cases are described in the examples given below. Last but not least, users occasionally contribute
+ additional examples, tips or errata to the
+ {{{http://docs.codehaus.org/display/MAVENUSER/Plugin+Name}plugin's wiki page}}.
+
+ In case you still have questions regarding the plugin's usage, please have a look at the {{{faq.html}FAQ}} and feel
+ free to contact the {{{mailing-lists.html}user mailing list}}. The posts to the mailing list are archived and could
+ already contain the answer to your question as part of an older thread. Hence, it is also worth browsing/searching
+ the {{{mailing-lists.html}mail archive}}.
+
+ If you feel like the plugin is missing a feature or has a defect, you can fill a feature request or bug report in our
+ {{{issue-management.html}issue management system}}. When creating a new issue, please provide a comprehensive description of your
+ concern. Especially for fixing bugs it is crucial that the developers can reproduce your problem. For this reason,
+ entire debug logs, POMs or most preferably little demo projects attached to the issue are very much appreciated.
+ Of course, patches are welcome, too. Contributors can check out the project from our
+ {{{scm.html}source repository}} and will find supplementary information in the
+ {{{/guides/development/guide-helping.html}guide to helping with Maven}}.
+
+* Examples
+
+ To provide you with better understanding of some usages of the Plugin Name,
+ you can take a look into the following examples:
+
+ * {{{./examples/example-one.html}Example Description One}}
+
+ * {{{./examples/example-two.html}Example Description Two}}
+
+----------------
+
+ * Goals
+
+ <<<plugin-info.html>>> is generated by the Maven Plugin Plugin. Until the Maven Site Plugin is updated it would be better to pull it out
+ to the main menu for greater visibility. This contains the goals and their descriptions with a link to the configuration parameters.
+ The information is based on the comments and annotations of the plugin.
+
+ * Usage (this was previously called Howto)
+
+ The usage page describes the the basic use cases for the plugin goals which includes sample POM configurations and explanation of
+ how the goals work.
+
+ * FAQ
+
+ A well documented project always collates frequently asked questions which are usually located in <<<src/site/fml/faq.fml>>>.
+ The example below provides a template for your FAQ:
+
++--------------+
+<?xml version="1.0" encoding="UTF-8"?>
+<faqs id="FAQ" title="Frequently Asked Questions">
+ <part id="General">
+ <faq id="question">
+ <question>Question?</question>
+ <answer>
+ <p>
+ Answer
+ </p>
+ </answer>
+ </faq>
+ </part>
+</faqs>
++--------------+
+
+ * Examples
+
+ The advanced configurations and examples not covered in the usage page is located here. Advanced users who wants to maximize the use
+ of a plugin can check the items here. Tips on how to use the plugin effectively is also a good thing to put here.
+
+ For examples of items under "Examples" check these plugin sites:
+
+ * {{{/plugins/maven-javadoc-plugin/}Maven Javadoc Plugin Examples}}
+
+ * {{{/plugins/maven-war-plugin/}Maven War Plugin Examples}}
+
+*Recommended Configured Reports
+
+ There are 2 recommended report plugins to enhance the plugin documentation, Javadoc and JXR.
+
+ * Maven Javadoc Plugin
+
+ Javadocs provide documentation that makes it easier for developers to know how to use a particular class. Instead of reading and
+ understanding the actual source code, the developer can use the Javadocs instead to lookup the class attributes and methods.
+
+ To enable javadoc for your plugin add the following to your <<<pom.xml>>>
+
++--------------+
+<project>
+ [...]
+ <build>
+ [...]
+ </build>
+ <reporting>
+ <plugins>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-javadoc-plugin</artifactId>
+ <version>2.4</version>
+ <configuration>
+ <minmemory>128m</minmemory>
+ <maxmemory>512</maxmemory>
+ ...
+ </configuration>
+ </plugin>
+ </plugins>
+ [...]
+ </reporting>
+ [...]
+</project>
++--------------+
+
+ Check the documentation about the plugin's {{{/plugins/maven-javadoc-plugin/javadoc-mojo.html}<<<javadoc:javadoc>>>}} goal for the advanced configurations.
+
+ * Maven JXR Plugin
+
+ The Maven JXR Plugin generates a cross-reference of the project sources. The generated cross-references are also linked to the corresponding
+ javadoc if javadoc is generated. The cross-references is great for those who wants to better understand the inner workings of the
+ plugin.
+
+ To enable source code cross-references add the following to your <<<pom.xml>>>
+
++--------------+
+<project>
+ [...]
+ <build>
+ [...]
+ </build>
+ <reporting>
+ <plugins>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-jxr-plugin</artifactId>
+ <version>2.1</version>
+ </plugin>
+ </plugins>
+ </reporting>
+ [...]
+</project>
++--------------+
+
+ Check the {{{/plugins/maven-jxr-plugin/jxr-mojo.html}JXR configuration page}} for the possible configuration parameters.
diff --git a/content/apt/guides/development/guide-testing-development-plugins.apt b/content/apt/guides/development/guide-testing-development-plugins.apt
new file mode 100644
index 00000000..22e87db7
--- /dev/null
+++ b/content/apt/guides/development/guide-testing-development-plugins.apt
@@ -0,0 +1,141 @@
+ ------
+ Guide to Testing Development Versions of Plugins
+ ------
+ Brett Porter
+ ------
+ 2009-08-02
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Guide to Testing Development Versions of Plugins
+
+* Why would I want to do this?
+
+ If a bug you are encountering has been reported as fixed but not yet released, you can confirm that it has been fixed
+ for you. Or perhaps you just like to live on the bleeding edge.
+
+ You are highly encouraged to join the development list for the project and provide your feedback, or help promote release
+ of the plugin in question.
+
+ <Note:> This is <<not>> recommended as an everyday or in production practice! Snapshots are for testing purposes only and
+ are not official releases. For more information, see {{{http://www.apache.org/dev/release.html#what} the Releases FAQ}}.
+
+* How do I do this?
+
+ Development versions of Maven plugins are periodically published to the repository: {{https://repository.apache.org/snapshots/}}.
+
+ <Note:> Currently, this is not done automatically by our continuous integration setup. This is coming soon.
+
+ Other sites may publish there own - for example, the MojoHaus project hosts theirs at {{https://oss.sonatype.org/content/repositories/snapshots/}}
+
+ The first step is to include this in your project:
+
++-------
+<project>
+ ...
+ <pluginRepositories>
+ <pluginRepository>
+ <id>apache.snapshots</id>
+ <url>https://repository.apache.org/snapshots/</url>
+ </pluginRepository>
+ </pluginRepositories>
+ ...
+</project>
++-------
+
+ After this is included, there are three ways to use the updated versions:
+
+ * Set the appropriate version in the plugin, eg <<<2.0.1-SNAPSHOT>>>
+
+ * If you have not specified a version, use the <<<-U>>> switch to update plugins for the given Maven run
+
+ * You can have Maven automatically check for updates on a given interval, for example:
+
++-------
+<project>
+ ...
+ <pluginRepositories>
+ <pluginRepository>
+ <id>apache.snapshots</id>
+ <url>https://repository.apache.org/snapshots/</url>
+ </pluginRepository>
+ </pluginRepositories>
+ ...
+</project>
++-------
+
+ <Note:> These last two techniques mean that <every> plugin will be updated to the latest snapshot version.
+
+ The development version will stop being used if the <<<\<pluginRepository\>>>> element is removed from your POM
+ and the version is set back to the release version. If you are using the command line or an unspecified version,
+ you will also need to remove the version from the local repository.
+
+* Using Settings without Modifying the Project
+
+ If you are using the goals from the command line on a number of projects, you should include this in your
+ <<<settings.xml>>> file instead.
+
+ You need to modify your <<<$\{user.home\}/.m2/settings.xml>>> file to include two new profiles
+ and then when you need access to the plugin snapshots use <<<-Papache>>>.
+ The profile only needs to be enabled once so that the plugins can be downloaded into you local repository. Once
+ in your local repository Maven can successfully resolve the dependencies and
+ the profile no longer needs to be activated.
+
++---
+<settings>
+ ...
+ <profiles>
+ <profile>
+ <id>apache</id>
+ <pluginRepositories>
+ <pluginRepository>
+ <id>apache.snapshots</id>
+ <name>Maven Plugin Snapshots</name>
+ <url>https://repository.apache.org/snapshots/</url>
+ <releases>
+ <enabled>false</enabled>
+ </releases>
+ <snapshots>
+ <enabled>true</enabled>
+ </snapshots>
+ </pluginRepository>
+ </pluginRepositories>
+ </profile>
+ </profiles>
+ ...
+</settings>
++---
+
+ When invoking Maven for Apache profile, do it like this:
+
+----
+mvn -Papache <phase|goal>
+----
+
+* Using a Repository Manager
+
+ In addition to the above you may want to use a repository manager so that you can retain the builds you have been using.
+ For information on this technique, see the {{{./guide-testing-releases.html} Guide to Testing Staged Releases}}.
+
+* How do I make changes to the source and test development versions of the plugins?
+
+ For information on this, see the {{{./guide-maven-development.html}Guide to Maven Development}}.
diff --git a/content/apt/guides/development/guide-testing-releases.apt b/content/apt/guides/development/guide-testing-releases.apt
new file mode 100644
index 00000000..7b5cc24f
--- /dev/null
+++ b/content/apt/guides/development/guide-testing-releases.apt
@@ -0,0 +1,153 @@
+ ------
+ Guide to Testing Staged Releases
+ ------
+ Maven Team
+ ------
+ 2007-12-21
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Guide to Testing Staged Releases
+
+ As part of the release process, the artifacts are staged in a temporary repository
+ for testing and evaluation before voting. Such repositories are not available by
+ default, so to use them your project must be configured appropriately.
+
+ The steps are as follows:
+
+ * add the repository or plugin repository to your POM or settings (see below)
+
+ * ensure you are using the version being released of the artifacts in your project,
+ e.g. by setting the <<<\<version\>>>> in the <<<\<plugin\>>>> tag.
+
+ * test the release
+
+ * remove the repository from your POM if it was specified there
+
+ * remove the artifacts from your local repository when you have completed testing
+
+ The repository configuration for testing a plugin will typically look something like this (it will be provided in the vote email):
+
++----
+ ...
+ <pluginRepositories>
+ <pluginRepository>
+ <id>staged-releases</id>
+ <url>https://repository.apache.org/content/groups/staging/</url>
+ </pluginRepository>
+ </pluginRepositories>
+ ...
++----
+
+ The important thing is that the staged release does not pollute your eventual environment as it may change if the vote fails and the
+ release is made again. This is why clearing the local repository is necessary, but if you are using a repository manager this is also
+ important to clear. The following provides instructions for setting Archiva up in such a way that the artifacts are isolated already.
+
+* Setting up Archiva to Test Staged Releases
+
+ These steps will be similar for any repository manager - please refer to their individual documentation for instructions on how to
+ configure remote proxies.
+
+ For Archiva, the first step is to create a new managed repository for the staged releases. This will ensure they remain isolated from your
+ environment. On the repositories tab, add a new managed repository with the settings:
+
+ * Identifier = <<<staged-releases>>>
+
+ * Name = Staged Releases
+
+ * Directory = <<</path/to/repositories/staged-releases>>>
+
+ * Uncheck 'Scannable'
+
+ Next add a remote repository with settings similar to the following:
+
+ * Identifier = <<<dfabulich.staged.releases>>>
+
+ * Name = dfabulich Staged Releases
+
+ * URL = <<<http://people.apache.org/~dfabulich/staging-repo/>>>
+
+ Finally, add a proxy connector to connect the two repositories:
+
+ * Managed repository = <<<staged-releases>>>
+
+ * Remote repository = <<<dfabulich.staged>>>
+
+ * Release policy = <<<once>>>
+
+ * Snapshot policy = <<<never>>>
+
+ * White list = <<<org/apache/maven/**>>>
+
+ You can then utilise this repository from your POM or settings in the same way, but with the alternate URL of
+ <<<http://localhost:8080/archiva/repository/staged-releases/>>>.
+
+ The advantage of this approach is that you can usually remove your entire local repository afterwards and after removing the staged repository
+ from your POM the artifacts will no longer be used. There is no need to remove the repository or artifacts from Archiva itself - unless a
+ staged release is updated for further testing.
+
+ It is also quite easy to test another staged release at a later date by reusing the repository, or adding a proxy connector and remote
+ repository for a different staging repository.
+
+ If you are using the repository mirroring technique to lock down to the repository manager in your environment, you would add an additional
+ mirror to correspond to the additional repository in the POM, such as:
+
++----
+ ...
+ <mirror>
+ <id>staged-releases-mirror</id>
+ <url>http://localhost:8080/archiva/repository/staged-releases/</url>
+ <mirrorOf>staged-releases</mirrorOf>
+ </mirror>
+ ...
++----
+
+* Using a Settings Profile
+
+ If you regularly test staged releases and want to have a more convenient way to add the repository to a build without
+ modifying your POM, you may add a profile to your <<<~/.m2/settings.xml>>>:
+
++----
+ ...
+ <profiles>
+ <profile>
+ <id>staged-releases</id>
+ <pluginRepositories>
+ <pluginRepository>
+ <id>staged-releases</id>
+ <url>https://repository.apache.org/content/groups/staging/</url>
+ </pluginRepository>
+ </pluginRepositories>
+ </profile>
+ ...
++----
+
+ With this in place, you can activate it by simply changing the plugin version to the one you are testing in the POM as above, then
+ run the build with the following command:
+
+-----
+mvn verify -Pstaged-releases
+-----
+
+ Note that the same conditions apply as above about cleaning out the local repository to prevent pollution of your local build
+ environment.
+
diff --git a/content/apt/guides/getting-started/index.apt b/content/apt/guides/getting-started/index.apt
new file mode 100644
index 00000000..ba3fb02c
--- /dev/null
+++ b/content/apt/guides/getting-started/index.apt
@@ -0,0 +1,1241 @@
+ ----
+ Maven Getting Started Guide
+ -----
+ Jason van Zyl
+ Vincent Siveton
+ -----
+ 2006-11-01
+ -----
+
+Maven Getting Started Guide
+
+ This guide is intended as a reference for those working with Maven for the first time, but is also intended to serve as
+ a cookbook with self-contained references and solutions for common use cases. For first time users, it is recommended
+ that you step through the material in a sequential fashion. For users more familiar with Maven, this guide endeavours
+ to provide a quick solution for the need at hand. It is assumed at this point that you have downloaded Maven and
+ installed Maven on your local machine. If you have not done so please refer to the
+ {{{../../download.html}Download and Installation}} instructions.
+
+ Ok, so you now have Maven installed and we're ready to go. Before we jump into our examples we'll very briefly go over
+ what Maven is and how it can help you with your daily work and collaborative efforts with team members. Maven will, of
+ course, work for small projects, but Maven shines in helping teams operate more effectively by allowing team members
+ to focus on what the stakeholders of a project require. You can leave the build infrastructure to Maven!
+
+Sections
+
+ * {{{./index.html#What_is_Maven}What is Maven?}}
+
+ * {{{./index.html#How_can_Maven_benefit_my_development_process}How can Maven benefit my development process?}}
+
+ * {{{./index.html#How_do_I_setup_Maven}How do I setup Maven?}}
+
+ * {{{./index.html#How_do_I_make_my_first_Maven_project}How do I make my first Maven project?}}
+
+ * {{{./index.html#How_do_I_compile_my_application_sources}How do I compile my application sources?}}
+
+ * {{{./index.html#How_do_I_compile_my_test_sources_and_run_my_unit_tests}How do I compile my test sources and run my unit tests?}}
+
+ * {{{./index.html#How_do_I_create_a_JAR_and_install_it_in_my_local_repository}How do I create a JAR and install it in my local repository?}}
+
+ * {{{./index.html#What_is_a_SNAPSHOT_version}What is a SNAPSHOT version?}}
+
+ * {{{./index.html#How_do_I_use_plugins}How do I use plugins?}}
+
+ * {{{./index.html#How_do_I_add_resources_to_my_JAR}How do I add resources to my JAR?}}
+
+ * {{{./index.html#How_do_I_filter_resource_files}How do I filter resource files?}}
+
+ * {{{./index.html#How_do_I_use_external_dependencies}How do I use external dependencies?}}
+
+ * {{{./index.html#How_do_I_deploy_my_jar_in_my_remote_repository}How do I deploy my jar in my remote repository?}}
+
+ * {{{./index.html#How_do_I_create_documentation}How do I create documentation?}}
+
+ * {{{./index.html#How_do_I_build_other_types_of_projects}How do I build other types of projects?}}
+
+ * {{{./index.html#How_do_I_build_more_than_one_project_at_once}How do I build more than one project at once?}}
+
+ []
+
+* {What is Maven?}
+
+ At first glance Maven can appear to be many things, but in a nutshell Maven is an attempt <to apply patterns to
+ a project's build infrastructure in order to promote comprehension and productivity by providing a clear path in the
+ use of best practices>. Maven is essentially a project management and comprehension tool and as such provides a way to
+ help with managing:
+
+
+ * Builds
+
+ * Documentation
+
+ * Reporting
+
+ * Dependencies
+
+ * SCMs
+
+ * Releases
+
+ * Distribution
+
+ []
+
+ If you want more background information on Maven you can check out {{{../../background/philosophy-of-maven.html}The Philosophy of Maven}} and
+ {{{../../background/history-of-maven.html}The History of Maven}}. Now let's move on to how you, the user, can benefit from
+ using Maven.
+
+* {How can Maven benefit my development process?}
+
+ Maven can provide benefits for your build process by employing standard conventions and practices to accelerate your development
+ cycle while at the same time helping you achieve a higher rate of success.
+
+ Now that we have covered a little bit of the history and purpose of Maven let's get into some real examples to
+ get you up and running with Maven!
+
+* {How do I setup Maven?}
+
+ The defaults for Maven are often sufficient, but if you need to change the cache location or are behind a HTTP proxy,
+ you will need to create configuration. See the {{{../mini/guide-configuring-maven.html} Guide to Configuring Maven}} for
+ more information.
+
+* {How do I make my first Maven project?}
+
+ We are going to jump headlong into creating your first Maven project!
+ To create our first Maven project we are going to use Maven's archetype mechanism. An archetype is defined as
+ <an original pattern or model from which all other things of the same kind are made>. In Maven, an archetype is a template
+ of a project which is combined with some user input to produce a working Maven project that has been tailored to the
+ user's requirements. We are going to show you how the archetype mechanism works now, but if you would like to know more
+ about archetypes please refer to our {{{../introduction/introduction-to-archetypes.html}Introduction to Archetypes}}.
+
+ On to creating your first project! In order to create the simplest of Maven projects, execute the following from
+ the command line:
+
+-----
+mvn -B archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
+-----
+
+ Once you have executed this command, you will notice a few things have happened. First, you will notice that
+ a directory named <<<my-app>>> has been created for the new project, and this directory contains a file named
+ <<<pom.xml>>> that should look like this:
+
++-----+
+<project 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/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1.0-SNAPSHOT</version>
+
+ <name>my-app</name>
+ <!-- FIXME change it to the project's website -->
+ <url>http://www.example.com</url>
+
+ <properties>
+ <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <maven.compiler.source>1.7</maven.compiler.source>
+ <maven.compiler.target>1.7</maven.compiler.target>
+ </properties>
+
+ <dependencies>
+ <dependency>
+ <groupId>junit</groupId>
+ <artifactId>junit</artifactId>
+ <version>4.11</version>
+ <scope>test</scope>
+ </dependency>
+ </dependencies>
+
+ <build>
+ <pluginManagement><!-- lock down plugins versions to avoid using Maven defaults (may be moved to parent pom) -->
+ ... lots of helpful plugins
+ </pluginManagement>
+ </build>
+</project>
++-----+
+
+ <<<pom.xml>>> contains the Project Object Model (POM) for this project. The POM is the basic unit
+ of work in Maven. This is important to remember because Maven is inherently project-centric in that everything revolves
+ around the notion of a project. In short, the POM contains every important piece of information about your project and
+ is essentially one-stop-shopping for finding anything related to your project. Understanding the POM is important and
+ new users are encouraged to refer to the {{{../introduction/introduction-to-the-pom.html}Introduction to the POM}}.
+
+ This is a very simple POM but still displays the key elements every POM contains, so let's walk through each of them
+ to familiarize you with the POM essentials:
+
+ * <<project>> This is the top-level element in all Maven pom.xml files.
+
+ * <<modelVersion>> This element indicates what version of the object model this POM is using. The version of the
+ model itself changes very infrequently but it is mandatory in order to ensure stability of use if and when
+ the Maven developers deem it necessary to change the model.
+
+ * <<groupId>> This element indicates the unique identifier of the organization or group that created the project.
+ The groupId is one of the key identifiers of a project and is typically based on the fully qualified
+ domain name of your organization. For example <<<org.apache.maven.plugins>>> is the designated groupId for
+ all Maven plugins.
+
+ * <<artifactId>> This element indicates the unique base name of the primary artifact being generated by this project.
+ The primary artifact for a project is typically a JAR file. Secondary artifacts like source bundles also use
+ the artifactId as part of their final name. A typical artifact produced by Maven would have the form
+ \<artifactId\>-\<version\>.\<extension\> (for example, <<<myapp-1.0.jar>>>).
+
+ * <<version>> This element indicates the version of the artifact generated by the project. Maven goes a long way
+ to help you with version management and you will often see the <<<SNAPSHOT>>> designator in a version, which
+ indicates that a project is in a state of development. We will discuss the use of
+ {{{./index.html#What_is_a_SNAPSHOT_version}snapshots}} and how they work further on in this guide.
+
+ * <<name>> This element indicates the display name used for the project. This is often used in Maven's
+ generated documentation.
+
+ * <<url>> This element indicates where the project's site can be found. This is often used in Maven's
+ generated documentation.
+
+ * <<properties>> This element contains value placeholders accessible anywhere within a POM.
+
+ * <<dependencies>> This element's children list {{{/pom.html#dependencies}dependencies}}. The cornerstone of the POM.
+
+ * <<build>> This element handles things like declaring your project's directory structure and managing plugins.
+
+ []
+
+ For a complete reference of what elements are available for use in the POM please refer to our {{{/ref/current/maven-model/maven.html}POM Reference}}.
+ Now let's get back to the project at hand.
+
+ After the archetype generation of your first project you will also notice that the following directory structure
+ has been created:
+
+-----
+my-app
+|-- pom.xml
+`-- src
+ |-- main
+ | `-- java
+ | `-- com
+ | `-- mycompany
+ | `-- app
+ | `-- App.java
+ `-- test
+ `-- java
+ `-- com
+ `-- mycompany
+ `-- app
+ `-- AppTest.java
+-----
+
+ As you can see, the project created from the archetype has a POM, a source tree for your application's sources and
+ a source tree for your test sources. This is the standard layout for Maven projects (the application sources
+ reside in <<<$\{basedir\}/src/main/java>>> and test sources reside in <<<$\{basedir\}/src/test/java>>>, where $\{basedir\}
+ represents the directory containing <<<pom.xml>>>).
+
+ If you were to create a Maven project by hand this is the directory structure that we recommend using. This is a
+ Maven convention and to learn more about it you can read our
+ {{{../introduction/introduction-to-the-standard-directory-layout.html}Introduction to the Standard Directory Layout}}.
+
+ Now that we have a POM, some application sources, and some test sources you are probably asking...
+
+* {How do I compile my application sources?}
+
+ Change to the directory where pom.xml is created by archetype:generate and execute the following command to compile
+ your application sources:
+
+-------
+mvn compile
+-------
+
+ Upon executing this command you should see output like the following:
+
+-----
+[INFO] Scanning for projects...
+[INFO]
+[INFO] ----------------------< com.mycompany.app:my-app >----------------------
+[INFO] Building my-app 1.0-SNAPSHOT
+[INFO] --------------------------------[ jar ]---------------------------------
+[INFO]
+[INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @ my-app ---
+[INFO] Using 'UTF-8' encoding to copy filtered resources.
+[INFO] skip non existing resourceDirectory <dir>/my-app/src/main/resources
+[INFO]
+[INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ my-app ---
+[INFO] Changes detected - recompiling the module!
+[INFO] Compiling 1 source file to <dir>/my-app/target/classes
+[INFO] ------------------------------------------------------------------------
+[INFO] BUILD SUCCESS
+[INFO] ------------------------------------------------------------------------
+[INFO] Total time: 0.899 s
+[INFO] Finished at: 2020-07-12T11:31:54+01:00
+[INFO] ------------------------------------------------------------------------
+-----
+
+ The first time you execute this (or any other) command, Maven will need to download all the plugins and related
+ dependencies it needs to fulfill the command. From a clean installation of Maven, this can take quite a while (in
+ the output above, it took almost 4 minutes). If you execute the command again, Maven will now have what it needs,
+ so it won't need to download anything new and will be able to execute the command much more quickly.
+
+ As you can see from the output, the compiled classes were placed in <<<$\{basedir\}/target/classes>>>, which is
+ another standard convention employed by Maven. So, if you're a keen observer, you'll notice that by using the
+ standard conventions, the POM above is very small and you haven't had to tell Maven explicitly where any of
+ your sources are or where the output should go. By following the standard Maven conventions, you can get
+ a lot done with very little effort! Just as a casual comparison, let's take a look at what you might have had to do
+ in {{{http://ant.apache.org}Ant}} to accomplish the same {{{../../ant/build-a1.xml}thing}}.
+
+ Now, this is simply to compile a single tree of application sources and the Ant script shown is pretty much the same
+ size as the POM shown above. But we'll see how much more we can do with just that simple POM!
+
+* {How do I compile my test sources and run my unit tests?}
+
+ Now you're successfully compiling your application's sources and now you've got some unit tests that you want to compile
+ and execute (because every programmer always writes and executes their unit tests *nudge nudge wink wink*).
+
+ Execute the following command:
+
+------
+mvn test
+------
+
+ Upon executing this command you should see output like the following:
+
+----
+[INFO] Scanning for projects...
+[INFO]
+[INFO] ----------------------< com.mycompany.app:my-app >----------------------
+[INFO] Building my-app 1.0-SNAPSHOT
+[INFO] --------------------------------[ jar ]---------------------------------
+[INFO]
+[INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @ my-app ---
+[INFO] Using 'UTF-8' encoding to copy filtered resources.
+[INFO] skip non existing resourceDirectory <dir>/my-app/src/main/resources
+[INFO]
+[INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ my-app ---
+[INFO] Nothing to compile - all classes are up to date
+[INFO]
+[INFO] --- maven-resources-plugin:3.0.2:testResources (default-testResources) @ my-app ---
+[INFO] Using 'UTF-8' encoding to copy filtered resources.
+[INFO] skip non existing resourceDirectory <dir>/my-app/src/test/resources
+[INFO]
+[INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @ my-app ---
+[INFO] Changes detected - recompiling the module!
+[INFO] Compiling 1 source file to <dir>/my-app/target/test-classes
+[INFO]
+[INFO] --- maven-surefire-plugin:2.22.1:test (default-test) @ my-app ---
+[INFO]
+[INFO] -------------------------------------------------------
+[INFO] T E S T S
+[INFO] -------------------------------------------------------
+[INFO] Running com.mycompany.app.AppTest
+[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.025 s - in com.mycompany.app.AppTest
+[INFO]
+[INFO] Results:
+[INFO]
+[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
+[INFO]
+[INFO] ------------------------------------------------------------------------
+[INFO] BUILD SUCCESS
+[INFO] ------------------------------------------------------------------------
+[INFO] Total time: 1.881 s
+[INFO] Finished at: 2020-07-12T12:00:33+01:00
+[INFO] ------------------------------------------------------------------------
+----
+
+ Some things to notice about the output:
+
+ * Maven downloads more dependencies this time. These are the dependencies and plugins necessary for executing the tests
+ (it already has the dependencies it needs for compiling and won't download them again).
+
+ * Before compiling and executing the tests Maven compiles the main code (all these classes are up to date because
+ we haven't changed anything since we compiled last).
+
+ If you simply want to compile your test sources (but not execute the tests), you can execute the following:
+
+------
+ mvn test-compile
+------
+
+ Now that you can compile your application sources, compile your tests, and execute the tests, you'll want to move
+ on to the next logical step so you'll be asking ...
+
+* {How do I create a JAR and install it in my local repository?}
+
+ Making a JAR file is straight forward enough and can be accomplished by executing the following command:
+
+~~ How to skip tests ... jvz
+
+------
+mvn package
+------
+
+ You can now take a look in the <<<$\{basedir\}/target>>> directory and you will see the generated JAR file.
+
+ Now you'll want to install the artifact you've generated (the JAR file) in your local repository
+ (<<<$\{user.home\}/.m2/repository>>> is the default location). For more information on repositories you can refer to our
+ {{{../introduction/introduction-to-repositories.html}Introduction to Repositories}} but let's move on to installing our artifact!
+ To do so execute the following command:
+
+------
+mvn install
+------
+
+ Upon executing this command you should see the following output:
+
+----
+[INFO] Scanning for projects...
+[INFO]
+[INFO] ----------------------< com.mycompany.app:my-app >----------------------
+[INFO] Building my-app 1.0-SNAPSHOT
+[INFO] --------------------------------[ jar ]---------------------------------
+[INFO]
+[INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @ my-app ---
+...
+[INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ my-app ---
+[INFO] Nothing to compile - all classes are up to date
+[INFO]
+[INFO] --- maven-resources-plugin:3.0.2:testResources (default-testResources) @ my-app ---
+...
+[INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @ my-app ---
+[INFO] Nothing to compile - all classes are up to date
+[INFO]
+[INFO] --- maven-surefire-plugin:2.22.1:test (default-test) @ my-app ---
+[INFO]
+[INFO] -------------------------------------------------------
+[INFO] T E S T S
+[INFO] -------------------------------------------------------
+[INFO] Running com.mycompany.app.AppTest
+[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.025 s - in com.mycompany.app.AppTest
+[INFO]
+[INFO] Results:
+[INFO]
+[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
+[INFO]
+[INFO]
+[INFO] --- maven-jar-plugin:3.0.2:jar (default-jar) @ my-app ---
+[INFO] Building jar: <dir>/my-app/target/my-app-1.0-SNAPSHOT.jar
+[INFO]
+[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ my-app ---
+[INFO] Installing <dir>/my-app/target/my-app-1.0-SNAPSHOT.jar to <local-repository>/com/mycompany/app/my-app/1.0-SNAPSHOT/my-app-1.0-SNAPSHOT.jar
+[INFO] Installing <dir>/my-app/pom.xml to <local-repository>/com/mycompany/app/my-app/1.0-SNAPSHOT/my-app-1.0-SNAPSHOT.pom
+[INFO] ------------------------------------------------------------------------
+[INFO] BUILD SUCCESS
+[INFO] ------------------------------------------------------------------------
+[INFO] Total time: 1.678 s
+[INFO] Finished at: 2020-07-12T12:04:45+01:00
+[INFO] ------------------------------------------------------------------------
+----
+
+ Note that the surefire plugin (which executes the test) looks for tests contained in files with a particular naming convention. By default
+ the tests included are:
+
+ * <<<\*\*/\*Test.java>>>
+
+ * <<<\*\*/Test\*.java>>>
+
+ * <<<\*\*/\*TestCase.java>>>
+
+ []
+
+ And the default excludes are:
+
+ * <<<\*\*/Abstract\*Test.java>>>
+
+ * <<<\*\*/Abstract\*TestCase.java>>>
+
+ []
+
+ You have walked through the process for setting up, building, testing, packaging, and installing a typical Maven project.
+ This is likely the vast majority of what projects will be doing with Maven and if you've noticed, everything you've been
+ able to do up to this point has been driven by an 18-line file, namely the project's model or POM. If you look at
+ a typical Ant {{{../../ant/build-a1.xml}build file}} that provides the same functionality that we've achieved thus
+ far you'll notice it's already twice the size of the POM and we're just getting started! There is far more
+ functionality available to you from Maven without requiring any additions to our POM as it currently stands. To
+ get any more functionality out of our example Ant build file you must keep making error-prone additions.
+
+ So what else can you get for free? There are a great number of Maven plugins that work out of the box with
+ even a simple POM like we have above. We'll mention one here specifically as it is one of the highly
+ prized features of Maven: without any work on your part this POM has enough information to generate
+ a web site for your project! You will most likely want to customize your Maven site but if you're pressed for
+ time all you need to do to provide basic information about your project is execute the following command:
+
+------
+mvn site
+------
+
+ There are plenty of other standalone goals that can be executed as well, for example:
+
+------
+mvn clean
+------
+
+ This will remove the <<<target>>> directory with all the build data before starting so that it is fresh.
+
+* {What is a SNAPSHOT version?}
+
+ Notice the value of the <<version>> tag in the <<<pom.xml>>> file shown below has the suffix: <<<-SNAPSHOT>>>.
+
++-----+
+<project xmlns="http://maven.apache.org/POM/4.0.0"
+ ...
+ <groupId>...</groupId>
+ <artifactId>my-app</artifactId>
+ ...
+ <version>1.0-SNAPSHOT</version>
+ <name>Maven Quick Start Archetype</name>
+ ...
++-----+
+
+ The <<<SNAPSHOT>>> value refers to the 'latest' code along a development branch, and provides no guarantee the
+ code is stable or unchanging. Conversely, the code in a 'release' version (any version value without the suffix <<<SNAPSHOT>>>)
+ is unchanging.
+
+ In other words, a SNAPSHOT version is the 'development' version before the final 'release' version.
+ The SNAPSHOT is "older" than its release.
+
+ During the {{{../../plugins/maven-release-plugin/}release}} process, a version of <<x.y-SNAPSHOT>> changes to
+ <<x.y>>. The release process also increments the development version to <<x.(y+1)-SNAPSHOT>>.
+ For example, version <<1.0-SNAPSHOT>> is released as version <<1.0>>, and the new development version is
+ version <<1.1-SNAPSHOT>>.
+
+* {How do I use plugins?}
+
+ Whenever you want to customise the build for a Maven project, this is done by adding or reconfiguring plugins.
+
+ For this example, we will configure the Java compiler to allow JDK 5.0 sources. This is as simple as
+ adding this to your POM:
+
++----+
+...
+<build>
+ <plugins>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-compiler-plugin</artifactId>
+ <version>3.3</version>
+ <configuration>
+ <source>1.5</source>
+ <target>1.5</target>
+ </configuration>
+ </plugin>
+ </plugins>
+</build>
+...
++----+
+
+ You'll notice that all plugins in Maven look much like a dependency - and in some ways they are.
+ This plugin will be automatically downloaded and used - including a specific version if you request it
+ (the default is to use the latest available).
+
+ The <<<configuration>>> element applies the given parameters to every goal from the compiler plugin.
+ In the above case, the compiler plugin is already used as part of the build process and this just changes the
+ configuration. It is also possible to add new goals to the process, and configure specific goals. For information on
+ this, see the {{{../introduction/introduction-to-the-lifecycle.html} Introduction to the Build Lifecycle}}.
+
+ To find out what configuration is available for a plugin, you can see the {{{../../plugins/} Plugins List}} and navigate
+ to the plugin and goal you are using. For general information about how to configure the available parameters of a
+ plugin, have a look at the {{{../mini/guide-configuring-plugins.html}Guide to Configuring Plugins}}.
+
+* {How do I add resources to my JAR?}
+
+ Another common use case that can be satisfied which requires no changes to the POM that we have
+ above is packaging resources in the JAR file. For this common task, Maven again relies on the
+ {{{../introduction/introduction-to-the-standard-directory-layout.html}Standard Directory Layout}}, which means by using
+ standard Maven conventions you can package resources within JARs simply by placing those resources in a standard
+ directory structure.
+
+ You see below in our example we have added the directory <<<$\{basedir\}/src/main/resources>>> into which we place
+ any resources we wish to package in our JAR. The simple rule employed by Maven is this: any directories or files
+ placed within the <<<$\{basedir\}/src/main/resources>>> directory are packaged in your JAR with the exact same
+ structure starting at the base of the JAR.
+
+----
+my-app
+|-- pom.xml
+`-- src
+ |-- main
+ | |-- java
+ | | `-- com
+ | | `-- mycompany
+ | | `-- app
+ | | `-- App.java
+ | `-- resources
+ | `-- META-INF
+ | `-- application.properties
+ `-- test
+ `-- java
+ `-- com
+ `-- mycompany
+ `-- app
+ `-- AppTest.java
+----
+
+ So you can see in our example that we have a <<<META-INF>>> directory with an <<<application.properties>>> file
+ within that directory. If you unpacked the JAR that Maven created for you and took a look at it you would
+ see the following:
+
+----
+|-- META-INF
+| |-- MANIFEST.MF
+| `-- application.properties
+| `-- maven
+| `-- com.mycompany.app
+| `-- my-app
+| |-- pom.properties
+| `-- pom.xml
+`-- com
+ `-- mycompany
+ `-- app
+ `-- App.class
+----
+
+ As you can see, the contents of <<<$\{basedir\}/src/main/resources>>> can be found starting at the base of the
+ JAR and our <<<application.properties>>> file is there in the <<<META-INF>>> directory. You will also notice some other files there
+ like <<<META-INF/MANIFEST.MF>>> as well as a <<<pom.xml>>> and <<<pom.properties>>> file. These come standard with
+ generation of a JAR in Maven. You can create your own manifest if you choose, but Maven will generate one by
+ default if you don't. (You can also modify the entries in the default manifest. We will touch on this
+ later.) The <<<pom.xml>>> and <<<pom.properties>>> files are packaged up in the JAR so that each artifact
+ produced by Maven is self-describing and also allows you to utilize the metadata in your own application
+ if the need arises. One simple use might be to retrieve the version of your application. Operating on the POM
+ file would require you to use some Maven utilities but the properties can be utilized using the standard
+ Java API and look like the following:
+
+----
+#Generated by Maven
+#Tue Oct 04 15:43:21 GMT-05:00 2005
+version=1.0-SNAPSHOT
+groupId=com.mycompany.app
+artifactId=my-app
+----
+
+ To add resources to the classpath for your unit tests, you follow the same pattern as you do for adding resources to the JAR
+ except the directory you place resources in is $\{basedir\}/src/test/resources. At this point you would have a
+ project directory structure that would look like the following:
+
+-----
+my-app
+|-- pom.xml
+`-- src
+ |-- main
+ | |-- java
+ | | `-- com
+ | | `-- mycompany
+ | | `-- app
+ | | `-- App.java
+ | `-- resources
+ | `-- META-INF
+ | |-- application.properties
+ `-- test
+ |-- java
+ | `-- com
+ | `-- mycompany
+ | `-- app
+ | `-- AppTest.java
+ `-- resources
+ `-- test.properties
+-----
+
+ In a unit test you could use a simple snippet of code like the following to access the resource required for
+ testing:
+
++----+
+...
+
+// Retrieve resource
+InputStream is = getClass().getResourceAsStream( "/test.properties" );
+
+// Do something with the resource
+
+...
++----+
+
+* {How do I filter resource files?}
+
+ Sometimes a resource file will need to contain a value that can only be supplied at build time. To accomplish this in
+ Maven, put a reference to the property that will contain the value into your resource file using the syntax <<<$\{<property name>\}>>>.
+ The property can be one of the values defined in your pom.xml, a value defined in the user's settings.xml, a property
+ defined in an external properties file, or a system property.
+
+ To have Maven filter resources when copying, simply set <<<filtering>>> to true for the resource directory in your <<<pom.xml>>>:
+
++----+
+<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <packaging>jar</packaging>
+
+ <name>Maven Quick Start Archetype</name>
+ <url>http://maven.apache.org</url>
+
+ <dependencies>
+ <dependency>
+ <groupId>junit</groupId>
+ <artifactId>junit</artifactId>
+ <version>4.11</version>
+ <scope>test</scope>
+ </dependency>
+ </dependencies>
+
+ <build>
+ <resources>
+ <resource>
+ <directory>src/main/resources</directory>
+ <filtering>true</filtering>
+ </resource>
+ </resources>
+ </build>
+</project>
++----+
+
+ You'll notice that we had to add the <<<build>>>, <<<resources>>>, and <<<resource>>> elements which weren't there before.
+ In addition, we had to explicitly state that the resources are located in the src/main/resources directory. All of this
+ information was provided as default values previously, but because the default value for <<<filtering>>> is false, we had
+ to add this to our pom.xml in order to override that default value and set <<<filtering>>> to true.
+
+ To reference a property defined in your pom.xml, the property name uses the names of the XML elements that define the value,
+ with "pom" being allowed as an alias for the project (root) element. So <<<$\{project.name\}>>> refers to the name of the project,
+ <<<$\{project.version\}>>> refers to the version of the project, <<<$\{project.build.finalName\}>>> refers to the final name of the file created
+ when the built project is packaged, etc. Note that some elements of the POM have default values, so don't need to be explicitly
+ defined in your <<<pom.xml>>> for the values to be available here. Similarly, values in the user's <<<settings.xml>>> can be referenced
+ using property names beginning with "settings" (for example, <<<$\{settings.localRepository\}>>> refers to the path of the user's
+ local repository).
+
+ To continue our example, let's add a couple of properties to the <<<application.properties>>> file (which we put in the
+ <<<src/main/resources>>> directory) whose values will be supplied when the resource is filtered:
+
+------
+# application.properties
+application.name=${project.name}
+application.version=${project.version}
+------
+
+ With that in place, you can execute the following command (process-resources is the build lifecycle phase where the resources are
+ copied and filtered):
+
+------
+mvn process-resources
+------
+
+ and the <<<application.properties>>> file under <<<target/classes>>> (and will eventually go into the jar) looks like this:
+
+------
+# application.properties
+application.name=Maven Quick Start Archetype
+application.version=1.0-SNAPSHOT
+------
+
+ To reference a property defined in an external file, all you need to do is add a reference to this external file in your pom.xml.
+ First, let's create our external properties file and call it <<<src/main/filters/filter.properties>>>:
+
+------
+# filter.properties
+my.filter.value=hello!
+------
+
+ Next, we'll add a reference to this new file in the <<<pom.xml>>>:
+
++----+
+<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <packaging>jar</packaging>
+
+ <name>Maven Quick Start Archetype</name>
+ <url>http://maven.apache.org</url>
+
+ <dependencies>
+ <dependency>
+ <groupId>junit</groupId>
+ <artifactId>junit</artifactId>
+ <version>4.11</version>
+ <scope>test</scope>
+ </dependency>
+ </dependencies>
+
+ <build>
+ <filters>
+ <filter>src/main/filters/filter.properties</filter>
+ </filters>
+ <resources>
+ <resource>
+ <directory>src/main/resources</directory>
+ <filtering>true</filtering>
+ </resource>
+ </resources>
+ </build>
+</project>
++----+
+
+ Then, if we add a reference to this property in the <<<application.properties>>> file:
+
+------
+# application.properties
+application.name=${project.name}
+application.version=${project.version}
+message=${my.filter.value}
+------
+
+ the next execution of the <<<mvn process-resources>>> command will put our new property value into <<<application.properties>>>.
+ As an alternative to defining the my.filter.value property in an external file, you could also have defined it in the <<<properties>>>
+ section of your <<<pom.xml>>> and you'd get the same effect (notice I don't need the references to <<<src/main/filters/filter.properties>>> either):
+
++----+
+<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <packaging>jar</packaging>
+
+ <name>Maven Quick Start Archetype</name>
+ <url>http://maven.apache.org</url>
+
+ <dependencies>
+ <dependency>
+ <groupId>junit</groupId>
+ <artifactId>junit</artifactId>
+ <version>4.11</version>
+ <scope>test</scope>
+ </dependency>
+ </dependencies>
+
+ <build>
+ <resources>
+ <resource>
+ <directory>src/main/resources</directory>
+ <filtering>true</filtering>
+ </resource>
+ </resources>
+ </build>
+
+ <properties>
+ <my.filter.value>hello</my.filter.value>
+ </properties>
+</project>
++----+
+
+ Filtering resources can also get values from system properties; either the system properties built into Java (like <<<java.version>>> or
+ <<<user.home>>>) or properties defined on the command line using the standard Java -D parameter. To continue the example, let's change
+ our <<<application.properties>>> file to look like this:
+
+------
+# application.properties
+java.version=${java.version}
+command.line.prop=${command.line.prop}
+------
+
+ Now, when you execute the following command (note the definition of the command.line.prop property on the command line), the
+ <<<application.properties>>> file will contain the values from the system properties.
+
+------
+mvn process-resources "-Dcommand.line.prop=hello again"
+------
+
+
+* {How do I use external dependencies?}
+
+ You've probably already noticed a <<<dependencies>>> element in the POM we've been using as an example.
+ You have, in fact, been using an external dependency all this time, but here we'll talk about how this
+ works in a bit more detail. For a more thorough introduction, please refer to our
+ {{{../introduction/introduction-to-dependency-mechanism.html}Introduction to Dependency Mechanism}}.
+
+ The <<<dependencies>>> section of the pom.xml lists all of the external dependencies that our project needs
+ in order to build (whether it needs that dependency at compile time, test time, run time, or whatever). Right
+ now, our project is depending on JUnit only (I took out all of the resource filtering stuff for clarity):
+
++----+
+<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <packaging>jar</packaging>
+
+ <name>Maven Quick Start Archetype</name>
+ <url>http://maven.apache.org</url>
+
+ <dependencies>
+ <dependency>
+ <groupId>junit</groupId>
+ <artifactId>junit</artifactId>
+ <version>4.11</version>
+ <scope>test</scope>
+ </dependency>
+ </dependencies>
+</project>
++----+
+
+ For each external dependency, you'll need to define at least 4 things: groupId, artifactId, version, and scope. The groupId,
+ artifactId, and version are the same as those given in the <<<pom.xml>>> for the project that built that dependency. The scope
+ element indicates how your project uses that dependency, and can be values like <<<compile>>>, <<<test>>>, and <<<runtime>>>.
+ For more information on everything you can specify for a dependency, see the {{{/ref/current/maven-model/maven.html}Project Descriptor Reference}}.
+ ~~DJ: Does this link work? I can't find the document.
+ For more information about the dependency mechanism as a whole, see
+ {{{../introduction/introduction-to-dependency-mechanism.html}Introduction to Dependency Mechanism}}.
+
+ With this information about a dependency, Maven will be able to reference the dependency when it builds the project. Where does
+ Maven reference the dependency from? Maven looks in your local repository (<<<$\{user.home\}/.m2/repository>>> is the default location) to find
+ all dependencies. In a {{{How_do_I_create_a_JAR_and_install_it_in_my_local_repository}previous section}}, we installed the artifact
+ from our project (my-app-1.0-SNAPSHOT.jar) into the local repository. Once it's installed there, another project can reference that jar
+ as a dependency simply by adding the dependency information to its pom.xml:
+
++----+
+<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-other-app</artifactId>
+ ...
+ <dependencies>
+ ...
+ <dependency>
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <scope>compile</scope>
+ </dependency>
+ </dependencies>
+</project>
++----+
+
+ What about dependencies built somewhere else? How do they get into my local repository? Whenever a project references a dependency
+ that isn't available in the local repository, Maven will download the dependency from a remote repository into the local repository. You
+ probably noticed Maven downloading a lot of things when you built your very first project (these downloads were dependencies for the
+ various plugins used to build the project). By default, the remote repository Maven uses can be found (and browsed) at
+ {{https://repo.maven.apache.org/maven2/}}. You can also set up your own remote repository (maybe a central repository for your company) to
+ use instead of or in addition to the default remote repository. For more information on repositories you can refer to the
+ {{{../introduction/introduction-to-repositories.html}Introduction to Repositories}}.
+
+ Let's add another dependency to our project. Let's say we've added some logging to the code and need to add log4j as a dependency.
+ First, we need to know what the groupId, artifactId, and version are for log4j. The appropriate directory on Maven Central is called
+ {{{https://repo.maven.apache.org/maven2/log4j/log4j/}/maven2/log4j/log4j}}. In that directory is a file called maven-metadata.xml. Here's what the maven-metadata.xml for
+ log4j looks like:
+
++----+
+<metadata>
+ <groupId>log4j</groupId>
+ <artifactId>log4j</artifactId>
+ <version>1.1.3</version>
+ <versioning>
+ <versions>
+ <version>1.1.3</version>
+ <version>1.2.4</version>
+ <version>1.2.5</version>
+ <version>1.2.6</version>
+ <version>1.2.7</version>
+ <version>1.2.8</version>
+ <version>1.2.11</version>
+ <version>1.2.9</version>
+ <version>1.2.12</version>
+ </versions>
+ </versioning>
+</metadata>
++----+
+
+ From this file, we can see that the groupId we want is "log4j" and the artifactId is "log4j". We see lots of different version values
+ to choose from; for now, we'll just use the latest version, 1.2.12 (some maven-metadata.xml files may also specify which version is
+ the current release version: see {{{/ref/current/maven-repository-metadata/repository-metadata.html}repository metadata reference}}).
+ Alongside the maven-metadata.xml file, we can see a directory corresponding to each version of the
+ log4j library. Inside each of these, we'll find the actual jar file (e.g. log4j-1.2.12.jar) as well as a pom file (this is the pom.xml
+ for the dependency, indicating any further dependencies it might have and other information) and another maven-metadata.xml file.
+ There's also an md5 file corresponding to each of these, which contains an MD5 hash for these files. You can use this to authenticate
+ the library or to figure out which version of a particular library you may be using already.
+
+ Now that we know the information we need, we can add the dependency to our pom.xml:
+
++----+
+<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <packaging>jar</packaging>
+
+ <name>Maven Quick Start Archetype</name>
+ <url>http://maven.apache.org</url>
+
+ <dependencies>
+ <dependency>
+ <groupId>junit</groupId>
+ <artifactId>junit</artifactId>
+ <version>4.11</version>
+ <scope>test</scope>
+ </dependency>
+ <dependency>
+ <groupId>log4j</groupId>
+ <artifactId>log4j</artifactId>
+ <version>1.2.12</version>
+ <scope>compile</scope>
+ </dependency>
+ </dependencies>
+</project>
++----+
+
+ Now, when we compile the project (<<<mvn compile>>>), we'll see Maven download the log4j dependency for us.
+
+~~DJ: Current
+
+* {How do I deploy my jar in my remote repository?}
+
+ For deploying jars to an external repository, you have to configure the repository url in the pom.xml
+ and the authentication information for connecting to the repository in the settings.xml.
+
+ Here is an example using scp and username/password authentication:
+
++----+
+<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <packaging>jar</packaging>
+
+ <name>Maven Quick Start Archetype</name>
+ <url>http://maven.apache.org</url>
+
+ <dependencies>
+ <dependency>
+ <groupId>junit</groupId>
+ <artifactId>junit</artifactId>
+ <version>4.11</version>
+ <scope>test</scope>
+ </dependency>
+ <dependency>
+ <groupId>org.apache.codehaus.plexus</groupId>
+ <artifactId>plexus-utils</artifactId>
+ <version>1.0.4</version>
+ </dependency>
+ </dependencies>
+
+ <build>
+ <filters>
+ <filter>src/main/filters/filters.properties</filter>
+ </filters>
+ <resources>
+ <resource>
+ <directory>src/main/resources</directory>
+ <filtering>true</filtering>
+ </resource>
+ </resources>
+ </build>
+ <!--
+ |
+ |
+ |
+ -->
+ <distributionManagement>
+ <repository>
+ <id>mycompany-repository</id>
+ <name>MyCompany Repository</name>
+ <url>scp://repository.mycompany.com/repository/maven2</url>
+ </repository>
+ </distributionManagement>
+</project>
++----+
+
++----+
+<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
+ ...
+ <servers>
+ <server>
+ <id>mycompany-repository</id>
+ <username>jvanzyl</username>
+ <!-- Default value is ~/.ssh/id_dsa -->
+ <privateKey>/path/to/identity</privateKey> (default is ~/.ssh/id_dsa)
+ <passphrase>my_key_passphrase</passphrase>
+ </server>
+ </servers>
+ ...
+</settings>
++----+
+
+ Note that if you are connecting to an openssh ssh server which has the parameter "PasswordAuthentication" set to "no"
+ in the sshd_confing, you will have to type your password each time for username/password authentication
+ (although you can log in using another ssh client by typing in the username and password).
+ You might want to switch to public key authentication in this case.
+
+ Care should be taken if using passwords in <<<settings.xml>>>. For more information, see {{{../mini/guide-encryption.html} Password Encryption}}.
+
+* {How do I create documentation?}
+
+ To get you jump started with Maven's documentation system you can use the archetype mechanism to generate a site
+ for your existing project using the following command:
+
+------
+mvn archetype:generate \
+ -DarchetypeGroupId=org.apache.maven.archetypes \
+ -DarchetypeArtifactId=maven-archetype-site \
+ -DgroupId=com.mycompany.app \
+ -DartifactId=my-app-site
+------
+
+ Now head on over to the {{{../mini/guide-site.html}Guide to creating a site}}
+ to learn how to create the documentation for your project.
+
+* {How do I build other types of projects?}
+
+ Note that the lifecycle applies to any project type. For example, back in the base directory we can create a
+ simple web application:
+
+------
+mvn archetype:generate \
+ -DarchetypeGroupId=org.apache.maven.archetypes \
+ -DarchetypeArtifactId=maven-archetype-webapp \
+ -DgroupId=com.mycompany.app \
+ -DartifactId=my-webapp
+------
+
+ Note that these must all be on a single line. This will create a directory called
+ <<<my-webapp>>> containing the following project descriptor:
+
++----+
+<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-webapp</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <packaging>war</packaging>
+
+ <dependencies>
+ <dependency>
+ <groupId>junit</groupId>
+ <artifactId>junit</artifactId>
+ <version>4.11</version>
+ <scope>test</scope>
+ </dependency>
+ </dependencies>
+
+ <build>
+ <finalName>my-webapp</finalName>
+ </build>
+</project>
++----+
+
+ Note the <<<\<packaging\>>>> element - this tells Maven to build as a WAR. Change into the webapp project's directory
+ and try:
+
+------
+mvn package
+------
+
+ You'll see <<<target/my-webapp.war>>> is built, and that all the normal steps were executed.
+
+* {How do I build more than one project at once?}
+
+ The concept of dealing with multiple modules is built in to Maven.
+ In this section, we will show how to build the WAR above, and include the previous JAR as well in one step.
+
+ Firstly, we need to add a parent <<<pom.xml>>> file in the directory above the other two, so it should look like this:
+
+----
++- pom.xml
++- my-app
+| +- pom.xml
+| +- src
+| +- main
+| +- java
++- my-webapp
+| +- pom.xml
+| +- src
+| +- main
+| +- webapp
+----
+
+ The POM file you'll create should contain the following:
+
++----+
+<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>app</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <packaging>pom</packaging>
+
+ <modules>
+ <module>my-app</module>
+ <module>my-webapp</module>
+ </modules>
+</project>
++----+
+
+ We'll need a dependency on the JAR from the webapp, so add this to <<<my-webapp/pom.xml>>>:
+
++----+
+ ...
+ <dependencies>
+ <dependency>
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ </dependency>
+ ...
+ </dependencies>
++----+
+
+ Finally, add the following <<<\<parent\>>>> element to both of the other <<<pom.xml>>> files in the subdirectories:
+
++----+
+<project 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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
+ <parent>
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>app</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ </parent>
+ ...
++----+
+
+ Now, try it... from the top level directory, run:
+
+------
+mvn verify
+------
+
+ The WAR has now been created in <<<my-webapp/target/my-webapp.war>>>, and the JAR is included:
+
+----
+$ jar tvf my-webapp/target/my-webapp-1.0-SNAPSHOT.war
+ 0 Fri Jun 24 10:59:56 EST 2005 META-INF/
+ 222 Fri Jun 24 10:59:54 EST 2005 META-INF/MANIFEST.MF
+ 0 Fri Jun 24 10:59:56 EST 2005 META-INF/maven/
+ 0 Fri Jun 24 10:59:56 EST 2005 META-INF/maven/com.mycompany.app/
+ 0 Fri Jun 24 10:59:56 EST 2005 META-INF/maven/com.mycompany.app/my-webapp/
+3239 Fri Jun 24 10:59:56 EST 2005 META-INF/maven/com.mycompany.app/my-webapp/pom.xml
+ 0 Fri Jun 24 10:59:56 EST 2005 WEB-INF/
+ 215 Fri Jun 24 10:59:56 EST 2005 WEB-INF/web.xml
+ 123 Fri Jun 24 10:59:56 EST 2005 META-INF/maven/com.mycompany.app/my-webapp/pom.properties
+ 52 Fri Jun 24 10:59:56 EST 2005 index.jsp
+ 0 Fri Jun 24 10:59:56 EST 2005 WEB-INF/lib/
+2713 Fri Jun 24 10:59:56 EST 2005 WEB-INF/lib/my-app-1.0-SNAPSHOT.jar
+----
+
+ How does this work? Firstly, the parent POM created (called <<<app>>>), has a packaging of <<<pom>>>
+ and a list of modules defined. This tells Maven to run all operations over the set of projects instead of
+ just the current one (to override this behaviour, you can use the <<<--non-recursive>>> command line option).
+
+ Next, we tell the WAR that it requires the <<<my-app>>> JAR. This does a few things: it makes it available
+ on the classpath to any code in the WAR (none in this case), it makes sure the JAR is always built before the
+ WAR, and it indicates to the WAR plugin to include the JAR in its library directory.
+
+ You may have noticed that <<<junit-4.11.jar>>> was a dependency, but didn't end up in the WAR. The
+ reason for this is the <<<\<scope\>test\</scope\>>>> element - it is only required for testing,
+ and so is not included in the web application as the compile time dependency <<<my-app>>> is.
+
+ The final step was to include a parent definition.
+ This ensures that the POM can always be located even if the project
+ is distributed separately from its parent by looking it up in the repository.
diff --git a/content/apt/guides/getting-started/maven-in-five-minutes.apt b/content/apt/guides/getting-started/maven-in-five-minutes.apt
new file mode 100644
index 00000000..3b9a7185
--- /dev/null
+++ b/content/apt/guides/getting-started/maven-in-five-minutes.apt
@@ -0,0 +1,294 @@
+ ----
+ Maven in 5 Minutes
+ -----
+ Eric Redmond
+ -----
+ 2008-01-01
+ -----
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Maven in 5 Minutes
+
+* Prerequisites
+
+ You must understand how to install software on your computer.
+ If you do not know how to do this, please ask someone at your office, school, etc.
+ or pay someone to explain this to you. The Maven mailing lists are not the best place to ask for this advice.
+
+* Installation
+
+ <Maven is a Java tool, so you must have {{{https://www.oracle.com/technetwork/java/javase/downloads/index.html}Java}}
+ installed in order to proceed.>
+
+ First, {{{../../download.html}download Maven}} and follow the {{{../../install.html}installation instructions}}.
+ After that, type the following in a terminal or in a command prompt:
+
+-----
+mvn --version
+-----
+
+ It should print out your installed version of Maven, for example:
+
+-----
+Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
+Maven home: D:\apache-maven-3.6.3\apache-maven\bin\..
+Java version: 1.8.0_232, vendor: AdoptOpenJDK, runtime: C:\Program Files\AdoptOpenJDK\jdk-8.0.232.09-hotspot\jre
+Default locale: en_US, platform encoding: Cp1250
+OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
+-----
+
+ Depending upon your network setup, you may require extra configuration. Check out the
+ {{{../mini/guide-configuring-maven.html}Guide to Configuring Maven}} if necessary.
+
+ <<If you are using Windows, you should look at>> {{{./windows-prerequisites.html}Windows Prerequisites}}
+ <<to ensure that you are prepared to use Maven on Windows.>>
+
+* Creating a Project
+
+ You need somewhere for your project to reside. Create a directory somewhere and start a shell in that directory.
+ On your command line, execute the following Maven goal:
+
+-----
+mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false
+-----
+
+ <If you have just installed Maven, it may take a while on the first run. This is because Maven is downloading
+ the most recent artifacts (plugin jars and other files) into your local repository. You may also need to
+ execute the command a couple of times before it succeeds. This is because the remote server may time out before
+ your downloads are complete. Don't worry, there are ways to fix that.>
+
+ You will notice that the <generate> goal created a directory with the same name given as the
+ artifactId. Change into that directory.
+
+-----
+cd my-app
+-----
+
+ Under this directory you will notice the following
+ {{{../introduction/introduction-to-the-standard-directory-layout.html}standard project structure}}.
+
+-----
+my-app
+|-- pom.xml
+`-- src
+ |-- main
+ | `-- java
+ | `-- com
+ | `-- mycompany
+ | `-- app
+ | `-- App.java
+ `-- test
+ `-- java
+ `-- com
+ `-- mycompany
+ `-- app
+ `-- AppTest.java
+-----
+
+ The <<<src/main/java>>> directory contains the project source code, the <<<src/test/java>>> directory contains
+ the test source, and the <<<pom.xml>>> file is the project's Project Object Model, or POM.
+
+** The POM
+
+ The <<<pom.xml>>> file is the core of a project's configuration in Maven. It is a single configuration
+ file that contains the majority of information required to build a project in just the way you want.
+ The POM is huge and can be daunting in its complexity, but it is not necessary to understand all
+ of the intricacies just yet to use it effectively. This project's POM is:
+
++-----+
+<project 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/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1.0-SNAPSHOT</version>
+
+ <properties>
+ <maven.compiler.source>1.7</maven.compiler.source>
+ <maven.compiler.target>1.7</maven.compiler.target>
+ </properties>
+
+ <dependencies>
+ <dependency>
+ <groupId>junit</groupId>
+ <artifactId>junit</artifactId>
+ <version>4.12</version>
+ <scope>test</scope>
+ </dependency>
+ </dependencies>
+</project>
++-----+
+
+** What did I just do?
+
+ You executed the Maven goal <archetype:generate>, and passed in various parameters to that goal.
+ The prefix <archetype> is the {{{../../plugins/index.html}plugin}} that provides the goal. If you are familiar with
+ {{{http://ant.apache.org}Ant}}, you
+ may conceive of this as similar to a task. This <archetype:generate> goal created a simple project based upon
+ a {{{/archetypes/maven-archetype-quickstart/}maven-archetype-quickstart}} archetype.
+ Suffice it to say for now that a <plugin> is a collection
+ of <goals> with a general common purpose. For example the jboss-maven-plugin, whose purpose is "deal with
+ various jboss items".
+
+** Build the Project
+
+-----
+mvn package
+-----
+
+ The command line will print out various actions, and end with the following:
+
+-----
+ ...
+[INFO] ------------------------------------------------------------------------
+[INFO] BUILD SUCCESS
+[INFO] ------------------------------------------------------------------------
+[INFO] Total time: 2.953 s
+[INFO] Finished at: 2019-11-24T13:05:10+01:00
+[INFO] ------------------------------------------------------------------------
+-----
+
+ Unlike the first command executed (<archetype:generate>), the second is simply
+ a single word - <package>. Rather than a <goal>, this is a <phase>. A phase is a step in the
+ {{{../introduction/introduction-to-the-lifecycle.html}build lifecycle}}, which is an ordered
+ sequence of phases. When a phase is given, Maven executes every phase in the sequence
+ up to and including the one defined. For example, if you execute the <compile> phase, the
+ phases that actually get executed are:
+
+ [[1]] validate
+
+ [[2]] generate-sources
+
+ [[3]] process-sources
+
+ [[4]] generate-resources
+
+ [[5]] process-resources
+
+ [[6]] compile
+
+ []
+
+ You may test the newly compiled and packaged JAR with the following command:
+
+-----
+java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App
+-----
+
+ Which will print the quintessential:
+
+-----
+Hello World!
+-----
+
+* Java 9 or later
+
+ By default your version of Maven might use an old version of the <<<maven-compiler-plugin>>>
+ that is not compatible with Java 9 or later versions. To target Java 9 or later,
+ you should at least use version 3.6.0 of the <<<maven-compiler-plugin>>> and set the
+ <<<maven.compiler.release>>> property to the Java release you are targetting (e.g. 9, 10, 11, 12, etc.).
+
+ In the following example, we have configured our Maven project to use version 3.8.1 of <<<maven-compiler-plugin>>>
+ and target Java 11:
+
++-----+
+ <properties>
+ <maven.compiler.release>11</maven.compiler.release>
+ </properties>
+
+ <build>
+ <pluginManagement>
+ <plugins>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-compiler-plugin</artifactId>
+ <version>3.8.1</version>
+ </plugin>
+ </plugins>
+ </pluginManagement>
+ </build>
++-----+
+
+ To learn more about <<<javac>>>'s <<<--release>>> option, see {{{https://openjdk.java.net/jeps/247}JEP 247}}.
+
+* Running Maven Tools
+
+** Maven Phases
+
+ Although hardly a comprehensive list, these are the most common <default> lifecycle phases executed.
+
+ * <<validate>>: validate the project is correct and all necessary information is available
+
+ * <<compile>>: compile the source code of the project
+
+ * <<test>>: test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
+
+ * <<package>>: take the compiled code and package it in its distributable format, such as a JAR.
+
+ * <<integration-test>>: process and deploy the package if necessary into an environment where integration tests can be run
+
+ * <<verify>>: run any checks to verify the package is valid and meets quality criteria
+
+ * <<install>>: install the package into the local repository, for use as a dependency in other projects locally
+
+ * <<deploy>>: done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
+
+ []
+
+ There are two other Maven lifecycles of note beyond the <default> list above. They are
+
+ * <<clean>>: cleans up artifacts created by prior builds
+
+ []
+
+ * <<site>>: generates site documentation for this project
+
+ []
+
+ Phases are actually mapped to underlying goals. The specific goals executed per phase is dependant upon the
+ packaging type of the project. For example, <package> executes <jar:jar> if the project type is a JAR, and
+ <war:war> if the project type is - you guessed it - a WAR.
+
+ An interesting thing to note is that phases and goals may be executed in sequence.
+
+-----
+mvn clean dependency:copy-dependencies package
+-----
+
+ This command will clean the project, copy dependencies, and package the project (executing all phases up to
+ <package>, of course).
+
+** Generating the Site
+
+-----
+mvn site
+-----
+
+ This phase generates a site based upon information on the project's pom. You can look at the
+ documentation generated under <<<target/site>>>.
+
+* Conclusion
+
+ We hope this quick overview has piqued your interest in the versatility of Maven. Note that this is a very
+ truncated quick-start guide. Now you are ready for more comprehensive details concerning
+ the actions you have just performed. Check out the {{{./index.html}Maven Getting Started Guide}}.
diff --git a/content/apt/guides/getting-started/windows-prerequisites.apt b/content/apt/guides/getting-started/windows-prerequisites.apt
new file mode 100644
index 00000000..8fd7640b
--- /dev/null
+++ b/content/apt/guides/getting-started/windows-prerequisites.apt
@@ -0,0 +1,66 @@
+ ----
+ Maven on Windows
+ -----
+ Benson Margulies
+ -----
+ 2012-07-01
+ -----
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Maven on Windows
+
+ Maven is a command-line tool for building Java (and other) programs. The Maven project provides a simple ZIP
+ file containing a precompiled version of Maven for your convenience. There is no installer. It's up to you
+ to set up your prerequisites and environment to run Maven on Windows.
+
+
+* Prerequisites
+
+ Maven is written in Java (and primarily used to build Java programs). Thus, the major prerequisite is the Java SDK.
+ You need to install the Java SDK (e.g. from {{{https://www.oracle.com/technetwork/java/javase/downloads/index.html}Oracle's download site}}).
+
+ Once Java is installed, you must ensure that the commands from the Java SDK are in your PATH environment variable.
+ Running, for example,
+
+-------
+java -version
+-------
+
+ must show the right version number.
+
+* Maven Unpacked
+
+ You need to unpack the Maven distribution. Don't unpack it in the middle of your source code; pick some location
+ and unpack it there. Let's assume that the path is <<<$\{maven.home\}>>>.
+
+* Maven in PATH
+
+ You run Maven by invoking a command-line tool: <<<mvn.cmd>>> from the <<<bin>>> directory of the Maven. To do this conveniently,
+ <<<$\{maven.home\}\bin>>> must be in your PATH, just like the Java SDK commands. You can add directories to your <<<PATH>>>
+ in the control panel; the details vary by Windows version.
+
+* Firewalls and Anti-virus
+
+ Firewall and Anti-virus sometimes prevent Java from running properly, or Windows Firewall (and various other Firewalls) actively
+ prevent Java.exe from reaching out to the Internet to "download stuff" which is a key part of Maven.
+ You may need to configure the Firewall or Anti-virus to add exceptions to allow such actions.
+
diff --git a/content/apt/guides/introduction/introduction-to-archetypes.apt b/content/apt/guides/introduction/introduction-to-archetypes.apt
new file mode 100644
index 00000000..70c3c10c
--- /dev/null
+++ b/content/apt/guides/introduction/introduction-to-archetypes.apt
@@ -0,0 +1,102 @@
+ ------
+ Introduction to Archetypes
+ ------
+ Jason van Zyl
+ ------
+ 2009-08-26
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction to Archetypes
+
+What is Archetype?
+
+ In short, Archetype is a Maven project templating toolkit. An archetype is defined as <an original pattern or model
+ from which all other things of the same kind are made>. The name fits as we are trying to provide a system that
+ provides a consistent means of generating Maven projects. Archetype will help authors create
+ Maven project templates for users, and provides users with the means to generate parameterized versions
+ of those project templates.
+
+ Using archetypes provides a great way to enable developers quickly in a way consistent with best practices employed
+ by your project or organization. Within the Maven project, we use archetypes to try and get our users up and running
+ as quickly as possible by providing a sample project that demonstrates many of the features of Maven, while introducing
+ new users to the best practices employed by Maven. In a matter of seconds, a new user can have a working Maven project
+ to use as a jumping board for investigating more of the features in Maven. We have also tried to make the Archetype
+ mechanism additive, and by that we mean allowing portions of a project to be captured in an archetype so that pieces
+ or aspects of a project can be added to existing projects. A good example of this is the Maven site archetype.
+ If, for example, you have used the quick start archetype to generate a working project, you can then quickly
+ create a site for that project by using the site archetype within that existing project. You can do anything like
+ this with archetypes.
+
+ You may want to standardize J2EE development within your organization, so you may want to provide archetypes
+ for EJBs, or WARs, or for your web services. Once these archetypes are created and deployed in your organization's
+ repository, they are available for use by all developers within your organization.
+
+* Using an Archetype
+
+ To create a new project based on an Archetype, you need to call <<<mvn archetype:generate>>> goal, like the following:
+
+-----
+mvn archetype:generate
+-----
+
+ Please refer to {{{/archetype/maven-archetype-plugin/usage.html}Archetype Plugin page}}.
+
+* Provided Archetypes
+
+ Maven provides several Archetype artifacts:
+
+*-----------------------------+----------------+
+|| Archetype ArtifactIds || Description ||
+*-----------------------------+----------------+
+| maven-archetype-archetype | An archetype to generate a sample archetype project. |
+*-----------------------------+----------------+
+| maven-archetype-j2ee-simple | An archetype to generate a simplifed sample J2EE application. |
+*-----------------------------+----------------+
+| maven-archetype-mojo | An archetype to generate a sample a sample Maven plugin. |
+*-----------------------------+----------------+
+| maven-archetype-plugin | An archetype to generate a sample Maven plugin. |
+*-----------------------------+----------------+
+| maven-archetype-plugin-site | An archetype to generate a sample Maven plugin site. |
+*-----------------------------+----------------+
+| maven-archetype-portlet | An archetype to generate a sample JSR-268 Portlet. |
+*-----------------------------+----------------+
+| maven-archetype-quickstart | An archetype to generate a sample Maven project. |
+*-----------------------------+----------------+
+| maven-archetype-simple | An archetype to generate a simple Maven project. |
+*-----------------------------+----------------+
+| maven-archetype-site | An archetype to generate a sample Maven site which demonstrates some of the supported document types like APT, XDoc, and FML and demonstrates how to i18n your site. |
+*-----------------------------+----------------+
+| maven-archetype-site-simple | An archetype to generate a sample Maven site. |
+*-----------------------------+----------------+
+| maven-archetype-webapp | An archetype to generate a sample Maven Webapp project. |
+*-----------------------------+----------------+
+
+ For more information on these archetypes, please refer to the {{{/archetypes/index.html}Maven Archetype Bundles page}}.
+
+* What makes up an Archetype?
+
+ Archetypes are packaged up in a JAR and they consist of the archetype metadata which describes the contents of
+ archetype, and a set of {{{http://velocity.apache.org/}Velocity}} templates which make up the prototype
+ project. If you would like to know how to make your own archetypes, please refer to our
+ {{{../mini/guide-creating-archetypes.html}Guide to creating archetypes}}.
+
diff --git a/content/apt/guides/introduction/introduction-to-dependency-mechanism.apt b/content/apt/guides/introduction/introduction-to-dependency-mechanism.apt
new file mode 100644
index 00000000..c976d057
--- /dev/null
+++ b/content/apt/guides/introduction/introduction-to-dependency-mechanism.apt
@@ -0,0 +1,876 @@
+ ------
+ Introduction to the Dependency Mechanism
+ ------
+ Brett Porter
+ Trygve Laugstol
+ Karl Heinz Marbaise
+ ------
+ 2005-10-12
+ 2016-06-17
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction to the Dependency Mechanism
+
+ Dependency management is a core feature of Maven. Managing dependencies for a single project is easy.
+ Managing dependencies for multi-module projects and applications that consist of hundreds of modules
+ is possible. Maven helps a great deal in defining, creating, and maintaining reproducible builds
+ with well-defined classpaths and library versions.
+
+ Learn more about:
+
+ * {{{Transitive_Dependencies}Transitive Dependencies}}
+
+ * Excluded/Optional Dependencies
+
+ * {{{Dependency_Scope}Dependency Scope}}
+
+ * {{{Dependency_Management}Dependency Management}}
+
+ * {{{Importing_Dependencies}Importing Dependencies}}
+
+ * {{{bill-of-materials-bom-poms}Bill of Materials (BOM) POMs}}
+
+ * {{{System_Dependencies}System Dependencies}}
+
+ []
+
+* {Transitive Dependencies}
+
+ Maven avoids the need to discover and
+ specify the libraries that your own dependencies require by including transitive dependencies automatically.
+
+ This feature is facilitated by reading the project files of your dependencies from the remote repositories
+ specified. In general, all dependencies of those projects are used in your project, as are any that the
+ project inherits from its parents, or from its dependencies, and so on.
+
+ There is no limit to the number of levels that dependencies can be gathered from. A problem arises
+ only if a cyclic dependency is discovered.
+
+ With transitive dependencies, the graph of included libraries can quickly grow quite large. For this reason,
+ there are additional features that limit which dependencies are included:
+
+ * <Dependency mediation>
+ - this determines what version of an artifact will be chosen when multiple
+ versions are encountered as dependencies. Maven picks the "nearest definition". That is,
+ it uses the version of the closest dependency to your project in the tree of dependencies.
+ You can always guarantee a version by declaring it explicitly in your project's POM.
+ Note that if two dependency versions are at the same depth in the dependency tree,
+ the first declaration wins.
+
+ * "nearest definition" means that the version used will be the closest one to your project in the tree of dependencies. Consider this tree of dependencies:
+
+----
+ A
+ ├── B
+ │ └── C
+ │ └── D 2.0
+ └── E
+ └── D 1.0
+----
+
+ In text, dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0,
+ then D 1.0 will be used when building A because the path from A to D through E is shorter.
+ You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0, as shown here:
+
+----
+ A
+ ├── B
+ │ └── C
+ │ └── D 2.0
+ ├── E
+ │ └── D 1.0
+ │
+ └── D 2.0
+----
+
+ * <Dependency management>
+ - this allows project authors to directly specify the versions of artifacts to be used when they are encountered
+ in transitive dependencies or in dependencies where no version has been specified. In the example in
+ the preceding section a dependency was directly added to A even though it is not directly used by A. Instead,
+ A can include D as a dependency in its dependencyManagement section and directly control which version of
+ D is used when, or if, it is ever referenced.
+
+ * <Dependency scope>
+ - this allows you to only include dependencies appropriate for the current stage
+ of the build. This is described in more detail below.
+
+ * <Excluded dependencies>
+ - If project X depends on project Y, and project Y depends on project Z, the owner of project X can explicitly exclude project Z
+ as a dependency, using the "exclusion" element.
+
+ * <Optional dependencies>
+ - If project Y depends on project Z, the owner of project Y can mark project Z
+ as an optional dependency, using the "optional" element. When project X depends on project Y, X will
+ depend only on Y and not on Y's optional dependency Z. The owner of project X may then
+ explicitly add a dependency on Z, at her option. (It may be helpful to think of optional
+ dependencies as "excluded by default.")
+
+ []
+
+ Although transitive dependencies can implicitly include desired dependencies, it is a good practice to explicitly
+ specify the dependencies your source code uses directly. This best practice proves its value especially
+ when the dependencies of your project change their dependencies.
+
+ For example, assume that your project A specifies a
+ dependency on another project B, and project B specifies a dependency on project C. If you are directly using components
+ in project C, and you don't specify project C in your project A, it may cause build failure when project B suddenly
+ updates/removes its dependency on project C.
+
+ Another reason to directly specify dependencies is that it provides better
+ documentation for your project: one can learn more information by just reading the POM file in your project, or by executing <<mvn dependency:tree>>.
+
+ Maven also
+ provides {{{/plugins/maven-dependency-plugin/analyze-mojo.html}dependency:analyze}} plugin goal
+ for analyzing the dependencies: it helps making this best practice more achievable.
+
+* {Dependency Scope}
+
+ Dependency scope is used to limit the transitivity of a dependency and to determine when a dependency is
+ included in a classpath.
+
+ There are 6 scopes:
+
+ * <<compile>>\
+ This is the default scope, used if none is specified. Compile dependencies are available
+ in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
+
+ * <<provided>>\
+ This is much like <<<compile>>>, but indicates you expect the JDK or a container to provide the dependency at runtime.
+ For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the
+ Servlet API and related Java EE APIs to scope <<<provided>>> because the web container provides those classes.
+ A dependency with this scope is added to the classpath used for compilation and test, but not the
+ runtime classpath. It is not transitive.
+
+ * <<runtime>>\
+ This scope indicates that the dependency is not required for compilation, but is for
+ execution. Maven includes a dependency with this scope in the runtime and test classpaths,
+ but not the compile classpath.
+
+ * <<test>>\
+ This scope indicates that the dependency is not required for normal use of the application, and
+ is only available for the test compilation and execution phases. This scope is not transitive.
+ Typically this scope is used for test libraries such as JUnit and Mockito.
+ It is also used for non-test libraries such as Apache Commons IO if those libraries are used in
+ unit tests (src/test/java) but not in the model code (src/main/java).
+
+ * <<system>>\
+ This scope is similar to <<<provided>>> except that you have to provide the JAR
+ which contains it explicitly. The artifact is always available and is not
+ looked up in a repository.
+
+ * <<import>>\
+ This scope is only supported on a dependency of type <<<pom>>> in the <<<\<dependencyManagement\>>>> section. It
+ indicates the dependency is to be replaced with the effective list of dependencies in the specified POM's
+ <<<\<dependencyManagement\>>>> section. Since they are replaced, dependencies with a scope of <<<import>>> do not
+ actually participate in limiting the transitivity of a dependency.
+
+ []
+
+ Each of the scopes (except for <<<import>>>) affects transitive dependencies in different ways, as is demonstrated in the table below.
+ If a dependency is set to the scope in the left column, a transitive dependency of that dependency with the
+ scope across the top row results in a dependency in the main project with the scope listed at the
+ intersection. If no scope is listed, it means the dependency is omitted.
+
+*----------+------------+----------+----------+------+
+| | compile | provided | runtime | test
+*----------+------------+----------+----------+------+
+| compile | compile(*) | - | runtime | -
+*----------+------------+----------+----------+------+
+| provided | provided | - | provided | -
+*----------+------------+----------+----------+------+
+| runtime | runtime | - | runtime | -
+*----------+------------+----------+----------+------+
+| test | test | - | test | -
+*----------+------------+----------+----------+------+
+
+ <<(*) Note:>>
+ it is intended that this should be runtime scope instead, so that all compile dependencies must
+ be explicitly listed. However, if a library you depend on extends a class from another
+ library, both must be available at compile time. For this reason, compile time dependencies remain
+ as compile scope even when they are transitive.
+
+* {Dependency Management}
+
+ The dependency management section is a mechanism for centralizing dependency information. When you have
+ a set of projects that inherit from a common parent, it's possible to put all information about the dependency
+ in the common POM and have simpler references to the artifacts in the child POMs. The mechanism is best
+ illustrated through some examples. Given these two POMs which extend the same parent:
+
+ Project A:
+
++----+
+
+<project>
+ ...
+ <dependencies>
+ <dependency>
+ <groupId>group-a</groupId>
+ <artifactId>artifact-a</artifactId>
+ <version>1.0</version>
+ <exclusions>
+ <exclusion>
+ <groupId>group-c</groupId>
+ <artifactId>excluded-artifact</artifactId>
+ </exclusion>
+ </exclusions>
+ </dependency>
+ <dependency>
+ <groupId>group-a</groupId>
+ <artifactId>artifact-b</artifactId>
+ <version>1.0</version>
+ <type>bar</type>
+ <scope>runtime</scope>
+ </dependency>
+ </dependencies>
+</project>
+
++----+
+
+ Project B:
+
++----+
+
+<project>
+ ...
+ <dependencies>
+ <dependency>
+ <groupId>group-c</groupId>
+ <artifactId>artifact-b</artifactId>
+ <version>1.0</version>
+ <type>war</type>
+ <scope>runtime</scope>
+ </dependency>
+ <dependency>
+ <groupId>group-a</groupId>
+ <artifactId>artifact-b</artifactId>
+ <version>1.0</version>
+ <type>bar</type>
+ <scope>runtime</scope>
+ </dependency>
+ </dependencies>
+</project>
+
++----+
+
+ These two example POMs share a common dependency and each has one non-trivial dependency. This information
+ can be put in the parent POM like this:
+
++----+
+
+<project>
+ ...
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>group-a</groupId>
+ <artifactId>artifact-a</artifactId>
+ <version>1.0</version>
+
+ <exclusions>
+ <exclusion>
+ <groupId>group-c</groupId>
+ <artifactId>excluded-artifact</artifactId>
+ </exclusion>
+ </exclusions>
+
+ </dependency>
+
+ <dependency>
+ <groupId>group-c</groupId>
+ <artifactId>artifact-b</artifactId>
+ <version>1.0</version>
+ <type>war</type>
+ <scope>runtime</scope>
+ </dependency>
+
+ <dependency>
+ <groupId>group-a</groupId>
+ <artifactId>artifact-b</artifactId>
+ <version>1.0</version>
+ <type>bar</type>
+ <scope>runtime</scope>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+</project>
+
++----+
+
+ Then the two child POMs become much simpler:
+
++----+
+
+<project>
+ ...
+ <dependencies>
+ <dependency>
+ <groupId>group-a</groupId>
+ <artifactId>artifact-a</artifactId>
+ </dependency>
+
+ <dependency>
+ <groupId>group-a</groupId>
+ <artifactId>artifact-b</artifactId>
+ <!-- This is not a jar dependency, so we must specify type. -->
+ <type>bar</type>
+ </dependency>
+ </dependencies>
+</project>
+
++----+
+
++----+
+
+<project>
+ ...
+ <dependencies>
+ <dependency>
+ <groupId>group-c</groupId>
+ <artifactId>artifact-b</artifactId>
+ <!-- This is not a jar dependency, so we must specify type. -->
+ <type>war</type>
+ </dependency>
+
+ <dependency>
+ <groupId>group-a</groupId>
+ <artifactId>artifact-b</artifactId>
+ <!-- This is not a jar dependency, so we must specify type. -->
+ <type>bar</type>
+ </dependency>
+ </dependencies>
+</project>
+
++----+
+
+ <<NOTE:>> In two of these dependency references, we had to specify the \<type/\>
+ element. This is because the minimal set of information for matching a dependency
+ reference against a dependencyManagement section is actually
+ <<\{groupId, artifactId, type, classifier\}>>. In many cases, these dependencies
+ will refer to jar artifacts with no classifier. This allows us to shorthand the
+ identity set to <<\{groupId, artifactId\}>>, since the default for the type field
+ is <<<jar>>>, and the default classifier is null.
+
+ A second, and very important use of the dependency management section is to control the versions
+ of artifacts used in transitive dependencies. As an example consider these projects:
+
+ Project A:
+
++----+
+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>maven</groupId>
+ <artifactId>A</artifactId>
+ <packaging>pom</packaging>
+ <name>A</name>
+ <version>1.0</version>
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>a</artifactId>
+ <version>1.2</version>
+ </dependency>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>b</artifactId>
+ <version>1.0</version>
+ <scope>compile</scope>
+ </dependency>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>c</artifactId>
+ <version>1.0</version>
+ <scope>compile</scope>
+ </dependency>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>d</artifactId>
+ <version>1.2</version>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+</project>
+
++----+
+
+ Project B:
+
++----+
+
+<project>
+ <parent>
+ <artifactId>A</artifactId>
+ <groupId>maven</groupId>
+ <version>1.0</version>
+ </parent>
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>maven</groupId>
+ <artifactId>B</artifactId>
+ <packaging>pom</packaging>
+ <name>B</name>
+ <version>1.0</version>
+
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>d</artifactId>
+ <version>1.0</version>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+
+ <dependencies>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>a</artifactId>
+ <version>1.0</version>
+ <scope>runtime</scope>
+ </dependency>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>c</artifactId>
+ <scope>runtime</scope>
+ </dependency>
+ </dependencies>
+</project>
+
++----+
+
+ When maven is run on project B, version 1.0 of artifacts a, b, c, and d will be used regardless of
+ the version specified in their POM.
+
+ * a and c both are declared as dependencies of the project so version 1.0 is used due to
+ dependency mediation. Both also have runtime scope since it is directly specified.
+
+ * b is defined in B's parent's dependency management section and since dependency management
+ takes precedence over dependency mediation for transitive dependencies, version 1.0 will be
+ selected should it be referenced in a or c's POM. b will also have compile scope.
+
+ * Finally, since d is specified in B's dependency management section, should d be a dependency
+ (or transitive dependency) of a or c, version 1.0 will be chosen - again because dependency
+ management takes precedence over dependency mediation and also because the current POM's
+ declaration takes precedence over its parent's declaration.
+
+ []
+
+ The reference information about the dependency management tags is available from the
+ {{{../../ref/current/maven-model/maven.html#class_DependencyManagement}project descriptor reference}}.
+
+** {Importing Dependencies}
+
+ The examples in the previous section describe how to specify managed dependencies through inheritance. However,
+ in larger projects it may be impossible to accomplish this since a project can only inherit from a single parent.
+ To accommodate this, projects can import managed dependencies from other projects. This is accomplished by declaring a
+ POM artifact as a dependency with a scope of "import".
+
+ Project B:
+
++----+
+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>maven</groupId>
+ <artifactId>B</artifactId>
+ <packaging>pom</packaging>
+ <name>B</name>
+ <version>1.0</version>
+
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>maven</groupId>
+ <artifactId>A</artifactId>
+ <version>1.0</version>
+ <type>pom</type>
+ <scope>import</scope>
+ </dependency>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>d</artifactId>
+ <version>1.0</version>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+
+ <dependencies>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>a</artifactId>
+ <version>1.0</version>
+ <scope>runtime</scope>
+ </dependency>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>c</artifactId>
+ <scope>runtime</scope>
+ </dependency>
+ </dependencies>
+</project>
+
++----+
+
+ Assuming A is the POM defined in the preceding example, the end result would be the same. All of A's managed dependencies
+ would be incorporated into B except for d since it is defined in this POM.
+
+ Project X:
+
++----+
+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>maven</groupId>
+ <artifactId>X</artifactId>
+ <packaging>pom</packaging>
+ <name>X</name>
+ <version>1.0</version>
+
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>a</artifactId>
+ <version>1.1</version>
+ </dependency>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>b</artifactId>
+ <version>1.0</version>
+ <scope>compile</scope>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+</project>
+
++----+
+
+ Project Y:
+
++----+
+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>maven</groupId>
+ <artifactId>Y</artifactId>
+ <packaging>pom</packaging>
+ <name>Y</name>
+ <version>1.0</version>
+
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>a</artifactId>
+ <version>1.2</version>
+ </dependency>
+ <dependency>
+ <groupId>test</groupId>
+ <artifactId>c</artifactId>
+ <version>1.0</version>
+ <scope>compile</scope>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+</project>
+
++----+
+
+ Project Z:
+
++----+
+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>maven</groupId>
+ <artifactId>Z</artifactId>
+ <packaging>pom</packaging>
+ <name>Z</name>
+ <version>1.0</version>
+
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>maven</groupId>
+ <artifactId>X</artifactId>
+ <version>1.0</version>
+ <type>pom</type>
+ <scope>import</scope>
+ </dependency>
+ <dependency>
+ <groupId>maven</groupId>
+ <artifactId>Y</artifactId>
+ <version>1.0</version>
+ <type>pom</type>
+ <scope>import</scope>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+</project>
+
++----+
+
+ In the example above Z imports the managed dependencies from both X and Y. However, both X and Y contain dependency a. Here,
+ version 1.1 of a would be used since X is declared first and a is not declared in Z's dependencyManagement.
+
+ This process is recursive. For example, if X imports another POM, Q, when Z is processed it will simply appear that all
+ of Q's managed dependencies are defined in X.
+
+** {Bill of Materials (BOM) POMs}
+
+ Imports are most effective when used for defining a "library" of related artifacts that are generally part of a
+ multiproject build. It is fairly common for one project to use one or more artifacts from these libraries.
+ However, it has sometimes been difficult to keep the versions in the project using the artifacts in synch
+ with the versions distributed in the library. The pattern below illustrates how a "bill of materials" (BOM) can be
+ created for use by other projects.
+
+ The root of the project is the BOM POM. It defines the versions of all the artifacts that will be created
+ in the library. Other projects that wish to use the library should import this POM into the dependencyManagement
+ section of their POM.
+
++----+
+
+<project 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/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>com.test</groupId>
+ <artifactId>bom</artifactId>
+ <version>1.0.0</version>
+ <packaging>pom</packaging>
+ <properties>
+ <project1Version>1.0.0</project1Version>
+ <project2Version>1.0.0</project2Version>
+ </properties>
+
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>com.test</groupId>
+ <artifactId>project1</artifactId>
+ <version>${project1Version}</version>
+ </dependency>
+ <dependency>
+ <groupId>com.test</groupId>
+ <artifactId>project2</artifactId>
+ <version>${project2Version}</version>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+
+ <modules>
+ <module>parent</module>
+ </modules>
+</project>
+
++----+
+
+ The parent subproject has the BOM POM as its parent. It is a normal multiproject pom.
+
++----+
+
+<project 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/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+ <parent>
+ <groupId>com.test</groupId>
+ <version>1.0.0</version>
+ <artifactId>bom</artifactId>
+ </parent>
+
+ <groupId>com.test</groupId>
+ <artifactId>parent</artifactId>
+ <version>1.0.0</version>
+ <packaging>pom</packaging>
+
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>log4j</groupId>
+ <artifactId>log4j</artifactId>
+ <version>1.2.12</version>
+ </dependency>
+ <dependency>
+ <groupId>commons-logging</groupId>
+ <artifactId>commons-logging</artifactId>
+ <version>1.1.1</version>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+ <modules>
+ <module>project1</module>
+ <module>project2</module>
+ </modules>
+</project>
+
++----+
+
+ Next are the actual project POMs.
+
++----+
+
+<project 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/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+ <parent>
+ <groupId>com.test</groupId>
+ <version>1.0.0</version>
+ <artifactId>parent</artifactId>
+ </parent>
+ <groupId>com.test</groupId>
+ <artifactId>project1</artifactId>
+ <version>${project1Version}</version>
+ <packaging>jar</packaging>
+
+ <dependencies>
+ <dependency>
+ <groupId>log4j</groupId>
+ <artifactId>log4j</artifactId>
+ </dependency>
+ </dependencies>
+</project>
+
+<project 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/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+ <parent>
+ <groupId>com.test</groupId>
+ <version>1.0.0</version>
+ <artifactId>parent</artifactId>
+ </parent>
+ <groupId>com.test</groupId>
+ <artifactId>project2</artifactId>
+ <version>${project2Version}</version>
+ <packaging>jar</packaging>
+
+ <dependencies>
+ <dependency>
+ <groupId>commons-logging</groupId>
+ <artifactId>commons-logging</artifactId>
+ </dependency>
+ </dependencies>
+</project>
+
++----+
+
+ The project that follows shows how the library can now be used in another project without having to
+ specify the dependent project's versions.
+
++----+
+<project 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/maven-4.0.0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>com.test</groupId>
+ <artifactId>use</artifactId>
+ <version>1.0.0</version>
+ <packaging>jar</packaging>
+
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>com.test</groupId>
+ <artifactId>bom</artifactId>
+ <version>1.0.0</version>
+ <type>pom</type>
+ <scope>import</scope>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>com.test</groupId>
+ <artifactId>project1</artifactId>
+ </dependency>
+ <dependency>
+ <groupId>com.test</groupId>
+ <artifactId>project2</artifactId>
+ </dependency>
+ </dependencies>
+</project>
+
++----+
+
+ Finally, when creating projects that import dependencies, beware of the following:
+
+ * Do not attempt to import a POM that is defined in a submodule of the current POM.
+ Attempting to do that will result in the build failing since it won't be able to locate the POM.
+
+ * Never declare the POM importing a POM as the parent (or grandparent, etc) of the target POM.
+ There is no way to resolve the circularity and an exception will be thrown.
+
+ * When referring to artifacts whose POMs have transitive dependencies, the project needs to specify versions
+ of those artifacts as managed dependencies. Not doing so results in a build failure since the
+ artifact may not have a version specified. (This should be considered a best practice in any case as it
+ keeps the versions of artifacts from changing from one build to the next).
+
+* {System Dependencies}
+
+ <<<Important note: This is deprecated.>>>
+
+ Dependencies with the scope <system> are always available and are not looked
+ up in repository. They are usually used to tell Maven about dependencies which
+ are provided by the JDK or the VM. Thus, system dependencies are especially
+ useful for resolving dependencies on artifacts which are now provided by the
+ JDK, but were available as separate downloads earlier. Typical examples are
+ the JDBC standard extensions or the Java Authentication and Authorization
+ Service (JAAS).
+
+ A simple example would be:
+
++----+
+
+<project>
+ ...
+ <dependencies>
+ <dependency>
+ <groupId>javax.sql</groupId>
+ <artifactId>jdbc-stdext</artifactId>
+ <version>2.0</version>
+ <scope>system</scope>
+ <systemPath>${java.home}/lib/rt.jar</systemPath>
+ </dependency>
+ </dependencies>
+ ...
+</project>
+
++----+
+
+ If your artifact is provided by the JDK's <<<tools.jar>>>, the system path
+ would be defined as follows:
+
++----+
+<project>
+ ...
+ <dependencies>
+ <dependency>
+ <groupId>sun.jdk</groupId>
+ <artifactId>tools</artifactId>
+ <version>1.5.0</version>
+ <scope>system</scope>
+ <systemPath>${java.home}/../lib/tools.jar</systemPath>
+ </dependency>
+ </dependencies>
+ ...
+</project>
++----+
+
+
diff --git a/content/apt/guides/introduction/introduction-to-optional-and-excludes-dependencies.apt b/content/apt/guides/introduction/introduction-to-optional-and-excludes-dependencies.apt
new file mode 100644
index 00000000..4ecceba6
--- /dev/null
+++ b/content/apt/guides/introduction/introduction-to-optional-and-excludes-dependencies.apt
@@ -0,0 +1,320 @@
+ ------
+ Optional Dependencies and Dependency Exclusions
+ ------
+ Allan Ramirez
+ ------
+ 2006-01-23
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction
+
+ This section discusses optional dependencies and
+ dependency exclusions. This will help users to understand what they are and
+ when and how to use them. It also explains why exclusions are made on a
+ per dependency basis instead of at the POM level.
+
+* Optional Dependencies
+
+ Optional dependencies are used when it's not possible
+ (for whatever reason) to split a project into sub-modules.
+ The idea is that some of the dependencies are only used for certain features
+ in the project and will not be needed if that feature isn't used. Ideally,
+ such a feature would be split into a sub-module that depends on the core
+ functionality project. This new subproject would have only non-optional
+ dependencies, since you'd need them all if you decided to use the
+ subproject's functionality.
+
+ However, since the project cannot be split up (again, for whatever reason),
+ these dependencies are declared optional. If a user wants to use
+ functionality related to an optional dependency, they have to redeclare
+ that optional dependency in their own project. This is not the clearest
+ way to handle this situation, but both optional dependencies and
+ dependency exclusions are stop-gap solutions.
+
+** Why use optional dependencies?
+
+ Optional dependencies save space and memory. They prevent problematic jars
+ that violate a license agreement or cause classpath issues from being
+ bundled into a WAR, EAR, fat jar, or the like.
+
+** How do I use the optional tag?
+
+ A dependency is declared optional by setting the <<<\<optional\>>>> element
+ to true in its dependency declaration:
+
++---+
+
+<project>
+ ...
+ <dependencies>
+ <!-- declare the dependency to be set as optional -->
+ <dependency>
+ <groupId>sample.ProjectA</groupId>
+ <artifactId>Project-A</artifactId>
+ <version>1.0</version>
+ <scope>compile</scope>
+ <optional>true</optional> <!-- value will be true or false only -->
+ </dependency>
+ </dependencies>
+</project>
+
++---+
+
+** How do optional dependencies work?
+
+-----
+
+Project-A -> Project-B
+
+-----
+
+ The diagram above says that Project-A depends on Project-B. When A
+ declares B as an optional dependency in its POM, this relationship remains
+ unchanged. It's just like a normal build where Project-B will be added in
+ Project-A's classpath.
+
+-----
+
+Project-X -> Project-A
+
+-----
+
+ When another project (Project-X) declares Project-A as a dependency in
+ its POM, the optional nature of the dependency takes effect.
+ Project-B is not included in the classpath of Project-X. You
+ need to declare it directly in the POM of Project X for B to be included
+ in X's classpath.
+
+** Example
+
+ Suppose there is a project named <X2> that has similar functionality
+ to <Hibernate>. It supports many databases such as
+ MySQL, PostgreSQL, and several versions of Oracle.
+ Each supported database requires an additional dependency on a driver jar.
+ All of these dependencies are needed at compile time to build X2.
+ However your project only uses one specific database
+ and doesn't need drivers for the others. X2 can
+ declare these dependencies as optional, so that when your project
+ declares X2 as a direct dependency in its POM, all the drivers supported
+ by the X2 are not automatically included in your project's classpath.
+ Your project will have to include an explicit dependency on the specific
+ driver for the one database it does use.
+
+* Dependency Exclusions
+
+ Since Maven resolves dependencies transitively, it is possible
+ for unwanted dependencies to be included in your project's classpath.
+ For example, a certain older jar may have security issues or be incompatible with the Java
+ version you're using. To address this, Maven allows you to exclude specific dependencies.
+ Exclusions are set on a specific dependency in your POM, and are targeted
+ at a specific groupId and artifactId. When you build your project, that
+ artifact will not be added to your project's classpath <by way of the
+ dependency in which the exclusion was declared>.
+
+** How to use dependency exclusions
+
+ Add an <<<\<exclusions\>>>> element in the <<<\<dependency\>>>> element by which
+ the problematic jar is included.
+
++---+
+
+<project>
+ ...
+ <dependencies>
+ <dependency>
+ <groupId>sample.ProjectA</groupId>
+ <artifactId>Project-A</artifactId>
+ <version>1.0</version>
+ <scope>compile</scope>
+ <exclusions>
+ <exclusion> <!-- declare the exclusion here -->
+ <groupId>sample.ProjectB</groupId>
+ <artifactId>Project-B</artifactId>
+ </exclusion>
+ </exclusions>
+ </dependency>
+ </dependencies>
+</project>
+
++---+
+
+** How dependency exclusion works and when to use it <<( as a last resort! )>>
+
+-----
+
+Project-A
+ -> Project-B
+ -> Project-D <! -- This dependency should be excluded -->
+ -> Project-E
+ -> Project-F
+ -> Project C
+
+-----
+
+ The diagram shows that Project-A depends on both Project-B and C. Project-B
+ depends on Project-D. Project-D depends on both Project-E and F. By default,
+ Project A's classpath will include:
+
+-----
+B, C, D, E, F
+-----
+
+ Suppose you don't want project D and its dependencies to be added to
+ Project A's classpath because some of Project-D's dependencies
+ are missing from the repository, and you
+ don't need the functionality in Project-B that depends on Project-D
+ anyway. Project-B's developers could have marked the dependency on
+ Project-D <<<\<optional\>true\</optional\>>>>:
+
++---+
+<dependency>
+ <groupId>sample.ProjectD</groupId>
+ <artifactId>ProjectD</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <optional>true</optional>
+</dependency>
++---+
+
+ Unfortunately, they didn't. As a last resort, you can exclude it
+ on your own POM for Project-A like this:
+
++---+
+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>sample.ProjectA</groupId>
+ <artifactId>Project-A</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <packaging>jar</packaging>
+ ...
+ <dependencies>
+ <dependency>
+ <groupId>sample.ProjectB</groupId>
+ <artifactId>Project-B</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <exclusions>
+ <exclusion>
+ <groupId>sample.ProjectD</groupId> <!-- Exclude Project-D from Project-B -->
+ <artifactId>Project-D</artifactId>
+ </exclusion>
+ </exclusions>
+ </dependency>
+ </dependencies>
+</project>
+
++---+
+
+ If you deploy Project-A to a repository, and Project-X declares a
+ normal dependency on Project-A, will Project-D still be excluded from the
+ classpath?
+
+-----
+
+Project-X -> Project-A
+
+-----
+
+ The answer is <<Yes>>. Project-A has declared that it doesn't need
+ Project-D to run, so it won't be brought in as a transitive dependency
+ of Project-A.
+
+ Now, consider that Project-X depends on Project-Y, as in the diagram below:
+
+-----
+
+Project-X -> Project-Y
+ -> Project-B
+ -> Project-D
+ ...
+
+-----
+
+ Project-Y also has a dependency on Project-B, and it does need the features
+ supported by Project-D. Therefore, it will NOT place an exclusion on
+ Project-D in its dependency list. It may also supply an additional
+ repository, from which it can resolve Project-E. In this case, it's important
+ that Project-D <<is not>> excluded globally, since it is a legitimate
+ dependency of Project-Y.
+
+ As another scenario, suppose the dependency you don't want is Project-E
+ instead of Project-D. How do you exclude it? See the diagram below:
+
+-----
+
+Project-A
+ -> Project-B
+ -> Project-D
+ -> Project-E <!-- Exclude this dependency -->
+ -> Project-F
+ -> Project C
+
+-----
+
+ Exclusions work on the entire dependency graph below the point where they
+ are declared. If you want to exclude Project-E instead of Project-D,
+ simply change the exclusion to point at Project-E, but you don't
+ move the exclusion down to Project-D. You cannot change Project-D's POM.
+ If you could, you would use optional dependencies instead of exclusions,
+ or split Project-D up into multiple subprojects, each with nothing but
+ normal dependencies.
+
++---+
+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>sample.ProjectA</groupId>
+ <artifactId>Project-A</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <packaging>jar</packaging>
+ ...
+ <dependencies>
+ <dependency>
+ <groupId>sample.ProjectB</groupId>
+ <artifactId>Project-B</artifactId>
+ <version>1.0-SNAPSHOT</version>
+ <exclusions>
+ <exclusion>
+ <groupId>sample.ProjectE</groupId> <!-- Exclude Project-E from Project-B -->
+ <artifactId>Project-E</artifactId>
+ </exclusion>
+ </exclusions>
+ </dependency>
+ </dependencies>
+</project>
+
++---+
+
+** Why exclusions are made on a per-dependency basis, rather than at the POM level
+
+ This is mainly to be sure the dependency graph is predictable, and to
+ keep inheritance effects from excluding a dependency that should not be
+ excluded. If you get to the method of last resort and have to put in an
+ exclusion, you should be absolutely certain which of your dependencies is
+ bringing in that unwanted transitive dependency.
+
+ If you truly want to ensure that a particular dependency appears nowhere in
+ your classpath, regardless of path, the
+ {{{/enforcer/enforcer-rules/bannedDependencies.html}banned dependencies rule}}
+ can be configured to fail the build if a problematic dependency is found.
+ When the build fails, you'll need to add specific exclusions on each path
+ the enforcer finds.
diff --git a/content/apt/guides/introduction/introduction-to-plugin-prefix-mapping.apt b/content/apt/guides/introduction/introduction-to-plugin-prefix-mapping.apt
new file mode 100644
index 00000000..3980eb45
--- /dev/null
+++ b/content/apt/guides/introduction/introduction-to-plugin-prefix-mapping.apt
@@ -0,0 +1,167 @@
+ ---
+ Introduction to Plugin Prefix Resolution
+ ---
+ John Casey
+ ---
+ 2009-08-01
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction to Plugin Prefix Resolution
+
+ When you execute Maven using a standard lifecycle phase, resolving the
+ plugins that participate in that lifecycle is a relatively simple process.
+ However, when you directly invoke a mojo from the command line, as in the case
+ of <<clean>>, Maven must have some way of reliably resolving the
+ <<clean>> plugin prefix to the <<maven-clean-plugin>>. This provides brevity
+ for command-line invocations, while preserving the descriptiveness of the
+ plugin's real artifactId.
+
+ To complicate matters even more, not all plugins should be forced to have the
+ same groupId in the repository. Since groupIds are presumed to be controlled
+ by one project, and multiple projects may release plugins for Maven, it
+ follows that plugin-prefix mappings must also accommodate multiple plugin
+ groupIds.
+
+ To address these concerns, Maven provides a new piece of repository-level
+ metadata (not associated with any single artifact) for plugin groups, along
+ with a plugin mapping manager to organize multiple plugin groups and provide
+ search functionality.
+
+* Specifying a Plugin's Prefix
+
+ In order to give users a convenient prefix with which to reference your plugin
+ a prefix must be associated with your plugin when it is built. By default, Maven
+ will make a guess at the plugin-prefix to be used, by removing any instances of
+ "maven" or "plugin" surrounded by hyphens in the plugin's artifact ID. The
+ conventional artifact ID formats to use are:
+
+ * <<<maven-$\{prefix\}-plugin>>> - for official plugins maintained by the Apache Maven team itself (you <<must not>> use this naming pattern for your plugin, see {{{../plugin/guide-java-plugin-development.html#Plugin_Naming_Convention_and_Apache_Maven_Trademark}this note for more informations}})
+
+ * <<<$\{prefix\}-maven-plugin>>> - for plugins from other sources
+
+ If your plugin's artifactId fits this pattern, Maven will automatically map
+ your plugin to the correct prefix in the metadata stored within your plugin's
+ groupId path on the repository. However, if you want to customize the prefix
+ used to reference your plugin, you can specify the prefix directly through a
+ configuration parameter on the <<<maven-plugin-plugin>>> in your plugin's POM:
+
++---+
+<project>
+ ...
+ <build>
+ ...
+ <plugins>
+ ...
+ <plugin>
+ <artifactId>maven-plugin-plugin</artifactId>
+ <version>2.3</version>
+ <configuration>
+ ...
+ <goalPrefix>somePrefix</goalPrefix>
+ </configuration>
+ </plugin>
+ </plugins>
+ </build>
+</project>
++---+
+
+ The above configuration will allow users to refer to your plugin by the prefix
+ <<somePrefix>>, as in the following example:
+
+-----
+mvn somePrefix:goal
+-----
+
+* Mapping Prefixes to Plugins
+
+ For each groupId configured for searching, Maven will:
+
+ [[1]] Download <<<maven-metadata.xml>>> from each remote repository into the local repository,
+ and name it <<<maven-metadata-$\{repoId\}.xml>>> within the path of $\{groupId\}.
+
+ [[2]] Load these metadata files, along with <<<maven-metadata-local.xml>>> (if it exists),
+ within the path of $\{groupId\}. Merge them.
+
+ [[3]] Lookup the plugin prefix in the merged metadata. If it's mapped, it should refer to
+ a concrete groupId-artifactId pair. Otherwise, go on to #1 for the next groupId in the
+ user's plugin-groups.
+
+ []
+
+ These metadata files consist of the <<groupId>> it represents (for clarity when
+ the file is opened outside the context of the directory), and a group of
+ <<plugin>> elements. Each <<plugin>> in this list contains a <<prefix>>
+ element denoting the plugin's command-line prefix, and an <<artifactId>>
+ element, which provides the other side of the prefix mapping and provides
+ enough information to lookup and use the plugin. When a plugin is installed
+ or deployed, the appropriate metadata file is located - and if the prefix
+ mapping is missing - modified to include the plugin-prefix mapping.
+
+* Configuring Maven to Search for Plugins
+
+ By default, Maven will search the groupId <<org.apache.maven.plugins>>
+ for prefix-to-artifactId mappings for the plugins it needs to perform a given
+ build. However, as previously mentioned, the user may have a need for
+ third-party plugins. Since the Maven project is assumed to have control over
+ the default plugin groupId, this means configuring Maven to search other
+ groupId locations for plugin-prefix mappings.
+
+ As it turns out, this is simple. In the Maven settings file (per-user:
+ <<<$\{user.home\}/.m2/settings.xml>>>; global: <<<$\{maven.home\}/conf/settings.xml>>>), you can
+ provide a custom <<pluginGroups>> section, listing the plugin groupIds you
+ want to search (each groupId goes in its own <<pluginGroup>> sub-element).
+ For example, if my project uses a Modello model file, I might have the
+ following in my settings:
+
++---+
+<pluginGroups>
+ <pluginGroup>org.codehaus.modello</pluginGroup>
+</pluginGroups>
++---+
+
+ This allows me to execute the following, which will generate Java classes
+ from the model:
+
+-----
+mvn -Dversion=4.0.0 -Dmodel=maven.mdo modello:java
+-----
+
+ Maven will always search the following groupId's <<after>> searching any plugin groups
+ specified in the user's settings:
+
+ * org.apache.maven.plugins
+
+ * org.codehaus.mojo
+
+ []
+
+ <<NOTE:>> When specifying plugin groups to be used in searching for a prefix mapping,
+ order is critical! By specifying a pluginGroup of <<<com.myco.plugins>>> with a prefix
+ of <<<clean>>>, I can override the usage of the <<<maven-clean-plugin>>> when
+ <<<clean:clean>>> is invoked.
+
+ <<NOTE2:>> For more information on <<<settings.xml>>>, see \[{{{a1}1}}\].
+
+*Resources
+
+ {1} {{{../mini/guide-configuring-maven.html}Guide to Configuring Maven}}
diff --git a/content/apt/guides/introduction/introduction-to-plugins.apt b/content/apt/guides/introduction/introduction-to-plugins.apt
new file mode 100644
index 00000000..cde95074
--- /dev/null
+++ b/content/apt/guides/introduction/introduction-to-plugins.apt
@@ -0,0 +1,87 @@
+ ------
+ Introduction to Maven Plugin Development
+ ------
+ John Casey
+ ------
+ 2005-06-24
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction to Maven Plugin Development
+
+ Maven consists of a core engine which provides basic project-processing
+ capabilities and build-process management, and a host of plugins which are
+ used to execute the actual build tasks.
+
+* What is a Plugin?
+
+ "Maven" is really just a core framework for a collection of
+ Maven Plugins. In other words, plugins are where much of the real action is
+ performed, plugins are used to: create jar files, create war files, compile
+ code, unit test code, create project documentation, and on and on. Almost
+ any action that you can think of performing on a project is implemented as
+ a Maven plugin.
+
+ Plugins are the central feature of Maven that allow for the reuse of
+ common build logic across multiple projects. They do this by executing an
+ "action" (i.e. creating a WAR file or compiling unit tests) in the context
+ of a project's description - the Project Object Model (POM). Plugin behavior
+ can be customized through a set of unique parameters which are exposed by a
+ description of each plugin goal (or Mojo).
+
+ One of the simplest plugins in Maven is the Clean Plugin. The
+ {{{../../plugins/maven-clean-plugin/}Maven
+ Clean plugin}} (maven-clean-plugin) is responsible for removing the target
+ directory of a Maven project. When you run "mvn clean", Maven executes
+ the "clean" goal as defined in the Clean plug-in, and the target directory
+ is removed. The Clean plugin
+ {{{../../plugins/maven-clean-plugin/clean-mojo.html}defines
+ a parameter}} which can be used to customize plugin behavior, this parameter is
+ called outputDirectory and it defaults to $\{project.build.directory\}.
+
+* What is a Mojo (<And Why the H--- is it Named 'Mojo'>)?
+
+ A Mojo is really just a <<goal>> in Maven, and plug-ins consist of
+ any number of goals (Mojos). Mojos can be defined as annotated Java classes or
+ Beanshell script. A Mojo specifies
+ metadata about a goal: a goal name, which phase of the lifecycle it fits into,
+ and the parameters it is expecting.
+
+ MOJO is a play on POJO (Plain-old-Java-object), substituting "Maven" for
+ "Plain". Mojo is also an interesting word (see {{{http://www.answers.com/mojo&r=67}definition}}).
+ From {{{http://www.wikipedia.org}Wikipedia}}, a "mojo" is defined as:
+ "...a small bag worn by a person under the clothes (also known as a mojo hand).
+ Such bags were thought to have supernatural powers, such as protecting from evil,
+ bringing good luck, etc."
+
+* What is the Build Lifecycle? (Overview)
+
+ The build lifecycle is a series of common <<stage>>s through which all project
+ builds naturally progress. Plugin goals are bound to specific stages in the
+ lifecycle.
+
+Resources
+
+ [[1]] {{{/plugin-developers/index.html}Plugin Development Center}}
+
+ [[2]] {{{../mini/guide-configuring-plugins.html}Configuring plugins}}
+
diff --git a/content/apt/guides/introduction/introduction-to-profiles.apt b/content/apt/guides/introduction/introduction-to-profiles.apt
new file mode 100644
index 00000000..0208564b
--- /dev/null
+++ b/content/apt/guides/introduction/introduction-to-profiles.apt
@@ -0,0 +1,816 @@
+ ---
+ Introduction to build profiles
+ ---
+ John Casey/Allan Ramirez
+ ---
+ 2008-01-01
+ ---
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction to Build Profiles
+
+%{toc|section=0|fromDepth=2|toDepth=5}
+
+ Apache Maven goes to great lengths to ensure that builds are portable. Among
+ other things, this means allowing build configuration inside the POM,
+ avoiding <<all>> filesystem references (in inheritance, dependencies, and
+ other places), and leaning much more heavily on the local repository to
+ store the metadata needed to make this possible.
+
+ However, sometimes portability is not entirely possible. Under certain
+ conditions, plugins may need to be configured with local filesystem paths.
+ Under other circumstances, a slightly different dependency set will be
+ required, and the project's artifact name may need to be adjusted slightly.
+ And at still other times, you may even need to include a whole plugin in the
+ build lifecycle depending on the detected build environment.
+
+ To address these circumstances, Maven supports build profiles.
+ Profiles are specified using a subset of the elements available in
+ the POM itself (plus one extra section), and are triggered in any of a
+ variety of ways. They modify the POM at build time, and are meant to be used
+ in complementary sets to give equivalent-but-different parameters for a set
+ of target environments (providing, for example, the path of the appserver root
+ in the development, testing, and production environments). As such, profiles
+ can easily lead to differing build results from different members of your team.
+ However, used properly, profiles can be used while still preserving
+ project portability. This will also minimize the use of <<<-f>>> option of
+ maven which allows user to create another POM with different parameters or
+ configuration to build which makes it more maintainable since it is running
+ with one POM only.
+
+* What are the different types of profile? Where is each defined?
+
+ * Per Project
+
+ - Defined in the POM itself <<<(pom.xml)>>>.
+
+ * Per User
+
+ - Defined in the {{{/ref/current/maven-settings/settings.html} Maven-settings}}
+ <<<(%USER_HOME%/.m2/settings.xml)>>>.
+
+ * Global
+
+ - Defined in the {{{/ref/current/maven-settings/settings.html} global Maven-settings}}
+ <<<($\{maven.home\}/conf/settings.xml)>>>.
+
+ * Profile descriptor
+
+ - a descriptor located in
+ {{{/ref/2.2.1/maven-profile/profiles.html}project basedir <<<(profiles.xml)>>>}}
+ (no longer supported in Maven 3.0 and above; see
+ {{{https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-profiles.xml} Maven 3 compatibility notes}})
+
+* How can a profile be triggered? How does this vary according to the type of profile being used?
+
+ A profile can be activated in several ways:
+
+ * Explicitly
+
+ * Implicitly
+
+ ** Based on OS
+
+ ** Based on system properties
+
+ ** Based on presence of files
+
+ []
+
+ Refer to the sections below for details.
+
+** Details on profile activation
+
+*** Explicit profile activation
+
+ Profiles can be explicitly specified using the <<<-P>>> command line flag.
+
+ This flag is followed by a comma-delimited list of
+ profile IDs to use. The profile(s) specified in the option
+ are activated in addition to any profiles which are activated by their activation
+ configuration or the <<<\<activeProfiles\>>>> section in <<<settings.xml>>>.
+ From Maven 4 onward, Maven will refuse to activate or deactivate a profile that cannot be resolved.
+ To prevent this, prefix the profile identifier with an <<<?>>>, marking it as optional:
+
+-----
+mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
+-----
+
+ Profiles can be activated in the Maven settings, via the <<<\<activeProfiles\>>>>
+ section. This section takes a list of <<<\<activeProfile\>>>> elements, each
+ containing a profile-id inside.
+
++---+
+<settings>
+ ...
+ <activeProfiles>
+ <activeProfile>profile-1</activeProfile>
+ </activeProfiles>
+ ...
+</settings>
++---+
+
+ Profiles listed in the <<<\<activeProfiles\>>>> tag would be activated by default
+ every time a project use it.
+
+*** Implicit profile activation
+
+ Profiles can be automatically triggered based on the detected state of
+ the build environment. These triggers are specified via an <<<\<activation\>>>>
+ section in the profile itself. Currently, this detection is limited to
+ JDK version matching, operating system matching or
+ the presence/the value of a system property. Here are some examples.
+
+**** JDK
+
+ The following configuration will trigger the profile when the JDK's
+ version <starts with> "1.4" (eg. "1.4.0_08", "1.4.2_07", "1.4"), in particular it <won't be active>
+ for <<newer>> versions like "1.8" or "11":
+
++---+
+<profiles>
+ <profile>
+ <activation>
+ <jdk>1.4</jdk>
+ </activation>
+ ...
+ </profile>
+</profiles>
++---+
+
+ Ranges can also be used as of Maven 2.1 (refer to the {{{/enforcer/enforcer-rules/versionRanges.html} Enforcer Version Range Syntax}} for more information).
+ Range values must start with either <<<[>>> or <<<(>>> otherwise the value is interpreted as prefix.
+ The following honours versions 1.3, 1.4 and 1.5.
+
++---+
+<profiles>
+ <profile>
+ <activation>
+ <jdk>[1.3,1.6)</jdk>
+ </activation>
+ ...
+ </profile>
+</profiles>
++---+
+
+ <Note:> an upper bound such as <<<,1.5]>>> is likely not to include most releases of 1.5, since they will have an additional "patch" release such as <<<_05>>> that is not taken into consideration in the above range.
+
+
+**** OS
+
+ This next one will activate based on the detected operating system. See the {{{/enforcer/enforcer-rules/requireOS.html}Maven Enforcer Plugin}} for more details about OS values.
+
++---+
+<profiles>
+ <profile>
+ <activation>
+ <os>
+ <name>Windows XP</name>
+ <family>Windows</family>
+ <arch>x86</arch>
+ <version>5.1.2600</version>
+ </os>
+ </activation>
+ ...
+ </profile>
+</profiles>
++---+
+
+**** Property
+
+ The profile below will be activated when the system property "debug" is specified
+ with any value:
+
++---+
+<profiles>
+ <profile>
+ <activation>
+ <property>
+ <name>debug</name>
+ </property>
+ </activation>
+ ...
+ </profile>
+</profiles>
++---+
+
+ The following profile will be activated when the system property "debug" is not defined
+ at all:
+
++---+
+<profiles>
+ <profile>
+ <activation>
+ <property>
+ <name>!debug</name>
+ </property>
+ </activation>
+ ...
+ </profile>
+</profiles>
++---+
+
+ The following profile will be activated when the system property "debug" is not defined,
+ or is defined with a value which is not "true".
+
++---+
+<profiles>
+ <profile>
+ <activation>
+ <property>
+ <name>debug</name>
+ <value>!true</value>
+ </property>
+ </activation>
+ ...
+ </profile>
+</profiles>
++---+
+
+ To activate this you would type one of those on the command line:
+
+-----
+mvn groupId:artifactId:goal
+mvn groupId:artifactId:goal -Ddebug=false
+-----
+
+ The next example will trigger the profile when the system property
+ "environment" is specified with the value "test":
+
++---+
+<profiles>
+ <profile>
+ <activation>
+ <property>
+ <name>environment</name>
+ <value>test</value>
+ </property>
+ </activation>
+ ...
+ </profile>
+</profiles>
++---+
+
+ To activate this you would type this on the command line:
+
+-----
+mvn groupId:artifactId:goal -Denvironment=test
+-----
+
+ As of Maven 3.0, profiles in the POM can also be activated based on properties from active profiles from the
+ <<<settings.xml>>>.
+
+ <<Note>>: Environment variables like <<<FOO>>> are available as properties of the form <<<env.FOO>>>. Further note
+ that environment variable names are normalized to all upper-case on Windows.
+
+ Since Maven 3.9.0 one can also evaluate the POM's packaging value by referencing property <<<packaging>>>.
+ This is only useful where the profile activation is defined in a common parent POM which is reused among multiple Maven projects.
+ The next example will trigger the profile when a project with packaging <<<war>>> is built:
+
++---+
+<profiles>
+ <profile>
+ <activation>
+ <property>
+ <name>packaging</name>
+ <value>war</value>
+ </property>
+ </activation>
+ ...
+ </profile>
+</profiles>
++---+
+
+**** Files
+
+ This example will trigger the profile when the generated file
+ <<<target/generated-sources/axistools/wsdl2java/org/apache/maven>>> is missing.
+
++---+
+<profiles>
+ <profile>
+ <activation>
+ <file>
+ <missing>target/generated-sources/axistools/wsdl2java/org/apache/maven</missing>
+ </file>
+ </activation>
+ ...
+ </profile>
+</profiles>
++---+
+
+ As of Maven 2.0.9, the tags <<<\<exists\>>>> and <<<\<missing\>>>> could be interpolated. Supported variables are
+ system properties like <<<$\{user.home\}>>> and environment variables like <<<$\{env.HOME\}>>>. Please note that
+ properties and values defined in the POM itself are not available for interpolation here, e.g. the above example
+ activator cannot use <<<$\{project.build.directory\}>>> but needs to hard-code the path <<<target>>>.
+
+ Profiles can also be active by default using a configuration like the following:
+
++---+
+<profiles>
+ <profile>
+ <id>profile-1</id>
+ <activation>
+ <activeByDefault>true</activeByDefault>
+ </activation>
+ ...
+ </profile>
+</profiles>
++---+
+
+ This profile will automatically be active for all builds unless another profile in the same POM
+ is activated using one of the previously described methods. All profiles that are active by
+ default are automatically deactivated when a profile in the POM is activated on the command line
+ or through its activation config.
+
+** Deactivating a profile
+
+ Starting with Maven 2.0.10, one or more profiles can be deactivated using the command line by prefixing their
+ identifier with either the character '!' or '-' as shown below:
+
+-----
+mvn groupId:artifactId:goal -P !profile-1,!profile-2,!?profile-3
+-----
+
+ or
+
+-----
+mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
+-----
+
+ This can be used to deactivate profiles marked as activeByDefault or profiles that would
+ otherwise be activated through their activation config.
+
+* Which areas of a POM can be customized by each type of profile? Why?
+
+ Now that we've talked about where to specify profiles, and how to activate them,
+ it will be useful to talk about <what> you can specify in a profile. As with
+ the other aspects of profile configuration, this answer is not straightforward.
+
+ Depending on where you choose to configure your profile, you will have access
+ to varying POM configuration options.
+
+** Profiles in external files
+
+ Profiles specified in external files
+ (i.e in <<<settings.xml>>> or <<<profiles.xml>>>) are not portable in the
+ strictest sense. Anything that seems to stand a high chance of changing the result
+ of the build is restricted to the inline profiles in the POM. Things like
+ repository lists could simply be a proprietary repository of approved
+ artifacts, and won't change the outcome of the build. Therefore, you will
+ only be able to modify the <<<\<repositories\>>>> and <<<\<pluginRepositories\>>>>
+ sections, plus an extra <<<\<properties\>>>> section.
+
+ The <<<\<properties\>>>> section allows you to specify free-form key-value pairs
+ which will be included in the interpolation process for the POM. This allows
+ you to specify a plugin configuration in the form of <<<$\{profile.provided.path\}>>>.
+
+** Profiles in POMs
+
+ On the other hand, if your profiles can be reasonably specified <inside> the
+ POM, you have many more options. The trade-off, of course, is that you can
+ only modify <that> project and its sub-modules. Since these profiles are
+ specified inline, and therefore have a better chance of preserving portability,
+ it's reasonable to say you can add more information to them without the risk
+ of that information being unavailable to other users.
+
+ Profiles specified in the POM can modify
+ {{{/ref/current/maven-model/maven.html}the following POM elements}}:
+
+ * <<<\<repositories\>>>>
+
+ * <<<\<pluginRepositories\>>>>
+
+ * <<<\<dependencies\>>>>
+
+ * <<<\<plugins\>>>>
+
+ * <<<\<properties\>>>> (not actually available in the main POM, but used behind the
+ scenes)
+
+ * <<<\<modules\>>>>
+
+ * <<<\<reports\>>>>
+
+ * <<<\<reporting\>>>>
+
+ * <<<\<dependencyManagement\>>>>
+
+ * <<<\<distributionManagement\>>>>
+
+ * a subset of the <<<\<build\>>>> element, which consists of:
+
+ * <<<\<defaultGoal\>>>>
+
+ * <<<\<resources\>>>>
+
+ * <<<\<testResources\>>>>
+
+ * <<<\<directory\>>>>
+
+ * <<<\<finalName\>>>>
+
+ * <<<\<filters\>>>>
+
+ * <<<\<pluginManagement\>>>>
+
+ * <<<\<plugins\>>>>
+
+ []
+
+** POM elements outside \<profiles\>
+
+ We don't allow modification of some POM elements outside of POM-profiles
+ because these runtime modifications will not be distributed when the POM
+ is deployed to the repository system, making that person's build of that
+ project completely unique from others. While you can do this to some extent
+ with the options given for external profiles, the danger is limited.
+ Another reason is that this POM info is sometimes being reused from the
+ parent POM.
+
+ External files such as <<<settings.xml>>> and <<<profiles.xml>>> also does not support elements
+ outside the POM-profiles. Let us take this scenario for elaboration. When the
+ effective POM get deployed to a remote repository, any person can pickup
+ its info out of the repository and use it to build a Maven project directly.
+ Now, imagine that if we can set profiles in dependencies, which is very
+ important to a build, or in any other elements outside POM-profiles in
+ <<<settings.xml>>> then most probably we cannot expect someone else to use that
+ POM from the repository and be able to build it. And we have to also think about
+ how to share the <<<settings.xml>>> with others. Note that too many files to
+ configure is very confusing and very hard to maintain.
+ Bottom line is that since this is build data, it should be in the POM.
+ One of the goals in Maven 2 is to consolidate all the information needed to
+ run a build into a single file, or file hierarchy which is the POM.
+
+* Profile Order
+
+ All profile elements in a POM from active profiles overwrite the global elements with the same name of the POM or extend those in case of collections.
+ In case multiple profiles are active in the same POM or external file, the ones which are defined <<later>> take precedence over the ones defined <<earlier>> (independent of their profile id and activation order).
+
+ Example:
+
++---+
+<project>
+ ...
+ <repositories>
+ <repository>
+ <id>global-repo</id>
+ ...
+ </repository>
+ </repositories>
+ ...
+ <profiles>
+ <profile>
+ <id>profile-1</id>
+ <activation>
+ <activeByDefault>true</activeByDefault>
+ </activation>
+ <repositories>
+ <repository>
+ <id>profile-1-repo</id>
+ ...
+ </repository>
+ </repositories>
+ </profile>
+ <profile>
+ <id>profile-2</id>
+ <activation>
+ <activeByDefault>true</activeByDefault>
+ </activation>
+ <repositories>
+ <repository>
+ <id>profile-2-repo</id>
+ ...
+ </repository>
+ </repositories>
+ </profile>
+ ...
+ </profiles>
+ ...
+</project>
++---+
+
+ This leads to the repository list: <<<profile-2-repo, profile-1-repo, global-repo>>>.
+
+* Profile Pitfalls
+
+ We've already mentioned the fact that adding profiles to your build has the
+ potential to break portability for your project. We've even gone so far as to
+ highlight circumstances where profiles are likely to break project portability.
+ However, it's worth reiterating those points as part of a more coherent
+ discussion about some pitfalls to avoid when using profiles.
+
+ There are two main problem areas to keep in mind when using profiles.
+ First are external properties, usually used in plugin configurations. These pose
+ the risk of breaking portability in your project. The other, more subtle area
+ is the incomplete specification of a natural set of profiles.
+
+** External Properties
+
+ External property definition concerns any property value defined outside
+ the <<<pom.xml>>> but not defined in a corresponding profile inside it.
+ The most obvious usage of properties in the POM is in plugin configuration.
+ While it is certainly possible to break project portability without properties,
+ these critters can have subtle effects that cause builds to fail. For example,
+ specifying appserver paths in a profile that is specified in the
+ <<<settings.xml>>> may cause your integration test plugin to fail when another
+ user on the team attempts to build without a similar <<<settings.xml>>>.
+ Consider the following <<<pom.xml>>> snippet for a web application project:
+
++---+
+<project>
+ ...
+ <build>
+ <plugins>
+ <plugin>
+ <groupId>org.myco.plugins</groupId>
+ <artifactId>spiffy-integrationTest-plugin</artifactId>
+ <version>1.0</version>
+ <configuration>
+ <appserverHome>${appserver.home}</appserverHome>
+ </configuration>
+ </plugin>
+ ...
+ </plugins>
+ </build>
+ ...
+</project>
++---+
+
+ Now, in your local <<<$\{user.home\}/.m2/settings.xml>>>, you have:
+
++---+
+<settings>
+ ...
+ <profiles>
+ <profile>
+ <id>appserverConfig</id>
+ <properties>
+ <appserver.home>/path/to/appserver</appserver.home>
+ </properties>
+ </profile>
+ </profiles>
+
+ <activeProfiles>
+ <activeProfile>appserverConfig</activeProfile>
+ </activeProfiles>
+ ...
+</settings>
++---+
+
+ When you build the <<integration-test>> lifecycle phase, your integration
+ tests pass, since the path you've provided allows the test plugin to install
+ and test this web application.
+
+ <However>, when your colleague attempts to build to <<integration-test>>,
+ his build fails spectacularly, complaining that it cannot resolve the plugin
+ configuration parameter <<<\<appserverHome\>>>>, or worse, that the value of that
+ parameter - literally <<<$\{appserver.home\}>>> - is invalid (if it warns you at all).
+
+ Congratulations, your project is now non-portable. Inlining this profile in
+ your <<<pom.xml>>> can help alleviate this, with the obvious drawback that
+ each project hierarchy (allowing for the effects of inheritance) now have to
+ specify this information. Since Maven provides good support for project
+ inheritance, it's possible to stick this sort of configuration in the
+ <<<\<pluginManagement\>>>> section of a team-level POM or similar, and simply
+ inherit the paths.
+
+ Another, less attractive answer might be standardization of development
+ environments. However, this will tend to compromise the productivity
+ gain that Maven is capable of providing.
+
+** Incomplete Specification of a Natural Profile Set
+
+ In addition to the above portability-breaker, it's easy to fail to cover all
+ cases with your profiles. When you do this, you're usually leaving one of
+ your target environments high and dry. Let's take the example <<<pom.xml>>>
+ snippet from above one more time:
+
++---+
+<project>
+ ...
+ <build>
+ <plugins>
+ <plugin>
+ <groupId>org.myco.plugins</groupId>
+ <artifactId>spiffy-integrationTest-plugin</artifactId>
+ <version>1.0</version>
+ <configuration>
+ <appserverHome>${appserver.home}</appserverHome>
+ </configuration>
+ </plugin>
+ ...
+ </plugins>
+ </build>
+ ...
+</project>
++---+
+
+ Now, consider the following profile, which would be specified inline in the
+ <<<pom.xml>>>:
+
++---+
+<project>
+ ...
+ <profiles>
+ <profile>
+ <id>appserverConfig-dev</id>
+ <activation>
+ <property>
+ <name>env</name>
+ <value>dev</value>
+ </property>
+ </activation>
+ <properties>
+ <appserver.home>/path/to/dev/appserver</appserver.home>
+ </properties>
+ </profile>
+
+ <profile>
+ <id>appserverConfig-dev-2</id>
+ <activation>
+ <property>
+ <name>env</name>
+ <value>dev-2</value>
+ </property>
+ </activation>
+ <properties>
+ <appserver.home>/path/to/another/dev/appserver2</appserver.home>
+ </properties>
+ </profile>
+ </profiles>
+ ..
+</project>
++---+
+
+ This profile looks quite similar to the one from the last example, with a few
+ important exceptions: it's plainly geared toward a development environment,
+ a new profile named <<<appserverConfig-dev-2>>> is added and it has an
+ activation section that will trigger its inclusion when the system
+ properties contain "env=dev" for a profile named <<<appserverConfig-dev>>> and
+ "env=dev-2" for a profile named <<<appserverConfig-dev-2>>>. So, executing:
+
+-----
+mvn -Denv=dev-2 integration-test
+-----
+
+ will result in a successful build, applying the properties given
+ by profile named <<<appserverConfig-dev-2>>>. And when we execute
+
+-----
+mvn -Denv=dev integration-test
+-----
+
+ it will result in a successful build applying the properties given
+ by the profile named <<<appserverConfig-dev>>>. However, executing:
+
+-----
+mvn -Denv=production integration-test
+-----
+
+ will not do a successful build. Why? Because, the resulting non-interpolated
+ literal value of <<<$\{appserver.home\}>>> will not be a valid path for deploying
+ and testing your web application. We haven't considered the case for the
+ production environment when writing our profiles. The "production"
+ environment (env=production), along with "test" and possibly even "local"
+ constitute a natural set of target environments for which we may want to
+ build the integration-test lifecycle phase. The incomplete specification of
+ this natural set means we have effectively limited our valid target environments
+ to the development environment. Your teammates - and probably your manager -
+ will not see the humor in this. When you construct profiles to handle cases
+ such as these, be sure to address the entire set of target permutations.
+
+ As a quick aside, it's possible for user-specific profiles to act in a similar
+ way. This means that profiles for handling different environments which are
+ keyed to the user can act up when the team adds a new developer. While I
+ suppose this <could> act as useful training for the newbie, it just wouldn't
+ be nice to throw them to the wolves in this way. Again, be sure to think of the
+ <whole> set of profiles.
+
+* How can I tell which profiles are in effect during a build?
+
+ Determining active profiles will help the user to know what particular
+ profiles has been executed during a build. We can use the {{{/plugins/maven-help-plugin/}Maven Help Plugin}}
+ to tell what profiles are in effect during a build.
+
+-----
+ mvn help:active-profiles
+-----
+
+ Let us have some small samples that will help us to understand more on the
+ <active-profiles> goal of that plugin.
+
+ From the last example of profiles in the <<<pom.xml>>>, you'll notice that there are
+ two profiles named <<<appserverConfig-dev>>> and <<<appserverConfig-dev-2>>>
+ which has been given different values for properties. If we go ahead
+ and execute:
+
+-----
+ mvn help:active-profiles -Denv=dev
+-----
+
+ The result will be a bulleted list of the id of the profile with an
+ activation property of "env=dev" together with the source where it was
+ declared. See sample below.
+
+---
+The following profiles are active:
+
+ - appserverConfig-dev (source: pom)
+---
+
+ Now if we have a profile declared in <<<settings.xml>>> (refer to the sample of profile
+ in <<<settings.xml>>>) and that have been set to be an active profile and execute:
+
+-----
+ mvn help:active-profiles
+-----
+
+ The result should be something like this
+
+---
+The following profiles are active:
+
+ - appserverConfig (source: settings.xml)
+---
+
+ Even though we don't have an activation property, a profile has been listed as active.
+ Why? Like we mentioned before, a profile that has been set as an active profile
+ in the <<<settings.xml>>> is automatically activated.
+
+ Now if we have something like a profile in the <<<settings.xml>>> that has been set
+ as an active profile and also triggered a profile in the POM. Which profile do
+ you think will have an effect on the build?
+
+-----
+ mvn help:active-profiles -P appserverConfig-dev
+-----
+
+ This will list the activated profiles:
+
+---
+The following profiles are active:
+
+ - appserverConfig-dev (source: pom)
+ - appserverConfig (source: settings.xml)
+---
+
+ Even though it listed the two active profiles, we are not sure which one
+ of them has been applied. To see the effect on the build execute:
+
+-----
+ mvn help:effective-pom -P appserverConfig-dev
+-----
+
+ This will print the effective POM for this build configuration out to the
+ console. Take note that profiles in the <<<settings.xml>>> takes higher priority
+ than profiles in the POM. So the profile that has been applied here is
+ <<<appserverConfig>>> not <<<appserverConfig-dev>>>.
+
+ If you want to redirect the output from the plugin to a file called <<<effective-pom.xml>>>,
+ use the command-line option <<<-Doutput=effective-pom.xml>>>.
+
+* Naming Conventions
+
+ By now you've noticed that profiles are a natural way of addressing the problem of
+ different build configuration requirements for different target environments. Above,
+ we discussed the concept of a "natural set" of profiles to address this situation,
+ and the importance of considering the whole set of profiles that will be required.
+
+ However, the question of how to organize and manage the evolution of that set is
+ non-trivial as well. Just as a good developer strives to write self-documenting
+ code, it's important that your profile id's give a hint to their intended use.
+ One good way to do this is to use the common system property trigger as part of
+ the name for the profile. This might result in names like <<env-dev>>, <<env-test>>,
+ and <<env-prod>> for profiles that are triggered by the system property <<env>>.
+ Such a system leaves a highly intuitive hint on how to activate a build targeted
+ at a particular environment. Thus, to activate a build for the test environment,
+ you need to activate <<env-test>> by issuing:
+
+-----
+mvn -Denv=test <phase>
+-----
+
+ The right command-line option can be had by simply substituting "=" for "-" in
+ the profile id.
+
+
diff --git a/content/apt/guides/introduction/introduction-to-repositories.apt b/content/apt/guides/introduction/introduction-to-repositories.apt
new file mode 100644
index 00000000..099abbdc
--- /dev/null
+++ b/content/apt/guides/introduction/introduction-to-repositories.apt
@@ -0,0 +1,167 @@
+ ------
+ Introduction to Repositories
+ ------
+ Jason van Zyl
+ Brian Fox
+ ------
+ 2008-05-13
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction to Repositories
+
+* Artifact Repositories
+
+ A repository in Maven holds build artifacts and dependencies of varying types.
+
+ There are exactly two types of repositories: <<local>> and <<remote>>:
+
+ [[1]] the <<local>> repository is a directory
+ on the computer where Maven runs. It caches remote downloads and contains temporary
+ build artifacts that you have not yet released.
+
+ [[2]] <<remote>> repositories refer to any other type of repository, accessed by a variety of protocols such as
+ <<<file://>>> and <<<https://>>>. These repositories might be a truly remote repository
+ set up by a third party to provide their artifacts for downloading (for example,
+ {{{https://repo.maven.apache.org/maven2/}repo.maven.apache.org}}).
+ Other "remote" repositories may be internal repositories
+ set up on a file or HTTP server within your company, used to share private artifacts between development teams
+ and for releases.
+
+ []
+
+ Local and remote repositories are structured the same way so that scripts can run on either
+ side, or they can be synced for offline use. The layout of the repositories is completely
+ transparent to the Maven user, however.
+
+* Using Repositories
+
+ In general, you should not need to do anything with the local repository on a regular basis, except clean
+ it out if you are short on disk space (or erase it completely if you are willing to download everything again).
+
+ For the remote repositories, they are used for both downloading and uploading (if you have the permission to
+ do so).
+
+** Downloading from a Remote Repository
+
+ Downloading in Maven is triggered by a project declaring a dependency that is not present in the local
+ repository (or for a <<<SNAPSHOT>>>, when the remote repository contains one that is newer).
+ By default, Maven will download from the {{{https://repo.maven.apache.org/maven2/}central}} repository.
+
+ To override this, you need to specify a <<<mirror>>> as shown in {{{../mini/guide-mirror-settings.html}Using Mirrors for Repositories}}.
+
+ You can set this in your <<<settings.xml>>> file to globally use a certain mirror. However,
+ it is common for a project to {{{../mini/guide-multiple-repositories.html}customise the repository in its <<<pom.xml>>>}}
+ and that your setting will take precedence. If dependencies are not being found, check that you
+ have not overridden the remote repository.
+
+ For more information on dependencies, see {{{./introduction-to-dependency-mechanism.html}Dependency Mechanism}}.
+
+** Using Mirrors for the Central Repository
+
+ There are {{{/repository/}several official Central repositories}} geographically distributed. You can make
+ changes to your <<<settings.xml>>> file to use one or more mirrors. Instructions for this can be
+ found in the guide {{{../mini/guide-mirror-settings.html}Using Mirrors for Repositories}}.
+
+* Building Offline
+
+ If you are temporarily disconnected from the internet and you need to build your projects offline,
+ you can use the offline switch on the CLI:
+
+-----
+ mvn -o package
+-----
+
+ Many plugins honor the offline setting and do not perform any operations that connect to
+ the internet. Some examples are resolving Javadoc links and link checking the site.
+
+* Uploading to a Remote Repository
+
+ While this is possible for any type of remote repository, you must have the permission to do so.
+ To have someone upload to the Central Maven repository, see {{{../../repository/index.html}Repository Center}}.
+
+* Internal Repositories
+
+ When using Maven, particularly in a corporate environment, connecting to the internet to download dependencies
+ is not acceptable for security, speed or bandwidth reasons. For that reason, it is desirable to set up an
+ internal repository to house a copy of artifacts, and to publish private artifacts to.
+
+ Such an internal repository can be downloaded using HTTP or the file system (with a <<<file://>>>
+ URL), and uploaded to using SCP, FTP, or a file copy.
+
+ As far as Maven is concerned, there is nothing special about this repository: it is another
+ <<remote repository>> that contains artifacts to download to a user's local cache, and is a publish
+ destination for artifact releases.
+
+ Additionally, you may want to share the repository server with your generated project sites. For more
+ information on creating and deploying sites, see {{{../mini/guide-site.html}Creating a Site}}.
+
+* Setting up the Internal Repository
+
+ To set up an internal repository just requires that you have a place to put it, and then copy
+ required artifacts there using the same layout as in a remote repository such as {{{https://repo.maven.apache.org/maven2/}repo.maven.apache.org}}.
+
+ It is <not> recommended that you scrape or <<<rsync://>>> a full copy of central as there is a large amount
+ of data there and doing so will get you banned. You can use a program such as those described on the {{{../../repository-management.html}Repository Management}} page to
+ run your internal repository's server, download from the internet as required, and then hold
+ the artifacts in your internal repository for faster downloading later.
+
+ The other options available are to manually download and vet releases, then copy them to the internal
+ repository, or to have Maven download them for a user, and manually upload the vetted artifacts to the
+ internal repository which is used for releases. This step is the only one available for artifacts where
+ the license forbids their distribution automatically, such as several J2EE JARs provided by Sun.
+ Refer to the {{{../mini/guide-coping-with-sun-jars.html}Guide to coping with SUN JARs}} document for more information.
+
+ It should be noted that Maven intends to include enhanced support for such features in the future,
+ including click through licenses on downloading, and verification of signatures.
+
+* Using the Internal Repository
+
+ Using the internal repository is quite simple. Simply make a change to add a <<<repositories>>> element:
+
++----+
+
+<project>
+ ...
+ <repositories>
+ <repository>
+ <id>my-internal-site</id>
+ <url>https://myserver/repo</url>
+ </repository>
+ </repositories>
+ ...
+</project>
+
++----+
+
+ If your internal repository requires authentication, the <<<id>>> element can be used in your {{{../../settings.html#Servers}settings}} file
+ to specify login information.
+
+* Deploying to the Internal Repository
+
+ One of the most important reasons to have one or more internal repositories is to be able to publish
+ your own private releases.
+
+ To publish to the repository, you will need to have access via one of SCP, SFTP, FTP, WebDAV, or the filesystem. Connectivity is accomplished with the various
+ {{{/wagon/wagon-providers/index.html}wagons}}. Some wagons may need to be added as {{{/ref/current/maven-model/maven.html#class_extension}extension}} to your build.
+~~ For example, to set up an SCP transfer.
+~~ show the scp example.
diff --git a/content/apt/guides/introduction/introduction-to-the-lifecycle.apt b/content/apt/guides/introduction/introduction-to-the-lifecycle.apt
new file mode 100644
index 00000000..f643d2c5
--- /dev/null
+++ b/content/apt/guides/introduction/introduction-to-the-lifecycle.apt
@@ -0,0 +1,483 @@
+ ------
+ Introduction to the Build Lifecycle
+ ------
+ Brett Porter
+ ------
+ 2006-06-16
+ 2015-04-04
+ ------
+
+ ~~ Copyright 2015 The Apache Software Foundation.
+ ~~
+ ~~ Licensed under the Apache License, Version 2.0 (the "License");
+ ~~ you may not use this file except in compliance with the License.
+ ~~ You may obtain a copy of the License at
+ ~~
+ ~~ http://www.apache.org/licenses/LICENSE-2.0
+ ~~
+ ~~ Unless required by applicable law or agreed to in writing, software
+ ~~ distributed under the License is distributed on an "AS IS" BASIS,
+ ~~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ ~~ See the License for the specific language governing permissions and
+ ~~ limitations under the License.
+
+ ~~ NOTE: For help with the syntax of this file, see:
+ ~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction to the Build Lifecycle
+
+* Table Of Contents
+
+ * {{{Build_Lifecycle_Basics}Build Lifecycle Basics}}
+
+ * {{{Setting_Up_Your_Project_to_Use_the_Build_Lifecycle}Setting Up Your Project to Use the Build Lifecycle}}
+
+ * {{{Packaging}Packaging}}
+
+ * {{{Plugins}Plugins}}
+
+ * {{{Lifecycle_Reference}Lifecycle Reference}}
+
+ * {{{Built-in_Lifecycle_Bindings}Built-in Lifecycle Bindings}}
+
+ []
+
+* {Build Lifecycle Basics}
+
+ Maven is based around the central concept of a build lifecycle. What this means is that the process for building
+ and distributing a particular artifact (project) is clearly defined.
+
+ For the person building a project, this means that it is only necessary to learn a small set of commands to build any
+ Maven project, and the {{{./introduction-to-the-pom.html}POM}} will ensure they get the results they desired.
+
+ There are three built-in build lifecycles: default, clean and site. The <<<default>>> lifecycle handles your project
+ deployment, the <<<clean>>> lifecycle handles project cleaning, while the <<<site>>> lifecycle handles the creation of your
+ project's web site.
+
+** {A Build Lifecycle is Made Up of Phases}
+
+ Each of these build lifecycles is defined by a different list of build phases, wherein a build phase represents a
+ stage in the lifecycle.
+
+ For example, the default lifecycle comprises of the following phases (for a complete list of the lifecycle phases, refer
+ to the {{{Lifecycle_Reference}Lifecycle Reference}}):
+
+ * <<<validate>>> - validate the project is correct and all necessary information is available
+
+ * <<<compile>>> - compile the source code of the project
+
+ * <<<test>>> - test the compiled source code using a suitable unit testing framework. These tests should not
+ require the code be packaged or deployed
+
+ * <<<package>>> - take the compiled code and package it in its distributable format, such as a JAR.
+
+ * <<<verify>>> - run any checks on results of integration tests to ensure quality criteria are met
+
+ * <<<install>>> - install the package into the local repository, for use as a dependency in other projects locally
+
+ * <<<deploy>>> - done in the build environment, copies the final package to the remote repository
+ for sharing with other developers and projects.
+
+ These lifecycle phases (plus the other lifecycle phases not shown here) are executed sequentially
+ to complete the <<<default>>> lifecycle.
+ Given the lifecycle phases above, this means that when the default lifecycle is used, Maven will first validate
+ the project, then will try to compile the sources, run those against the tests, package the binaries (e.g. jar), run
+ integration tests against that package, verify the integration tests, install the verified package to the local
+ repository, then deploy the installed package to a remote repository.
+
+ <{{{./introduction-to-the-lifecycle.html}[top]}}.>
+
+** {Usual Command Line Calls}
+
+ You should select the phase that matches your outcome. If you want your jar, run <<<package>>>. If you want to run the
+ unit tests, run <<<test>>>.
+
+ If you are uncertain what you want, the preferred phase to call is
+
+------
+mvn verify
+------
+
+ This command executes each default lifecycle phase in order (<<<validate>>>, <<<compile>>>, <<<package>>>, etc.),
+ before executing <<<verify>>>. You only need to call the last build phase to be executed, in this case, <<<verify>>>.
+ In most cases the effect is the same as <<<package>>>. However, in case there are integration-tests, these will be
+ executed as well. And during the <<<verify>>> phase some additional checks can be done, e.g. if your code written
+ according to the predefined checkstyle rules.
+
+ In a build environment, use the following call to cleanly build and deploy artifacts into the shared repository.
+
+------
+mvn clean deploy
+------
+
+ The same command can be used in a multi-module scenario (i.e. a project with one or more subprojects). Maven
+ traverses into every subproject and executes <<<clean>>>, then executes <<<deploy>>> (including all of
+ the prior build phase steps).
+
+ <{{{./introduction-to-the-lifecycle.html}[top]}}.>
+
+** {A Build Phase is Made Up of Plugin Goals}
+
+ However, even though a build phase is responsible for a specific step in the build lifecycle, the manner in which it
+ carries out those responsibilities may vary. And this is done by declaring the plugin goals bound to those build phases.
+
+ A plugin goal represents a specific task (finer than a build phase) which contributes to the building and managing of a
+ project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of
+ the build lifecycle by direct invocation. The order of execution depends on the order in which the goal(s) and the build phase(s) are
+ invoked. For example, consider the command below. The <<<clean>>> and <<<package>>> arguments are build phases, while the
+ <<<dependency:copy-dependencies>>> is a goal (of a plugin).
+
+------
+mvn clean dependency:copy-dependencies package
+------
+
+ If this were to be executed, the <<<clean>>> phase will be executed first (meaning it will run all preceding phases of the clean lifecycle,
+ plus the <<<clean>>> phase itself), and then the <<<dependency:copy-dependencies>>> goal, before finally executing the
+ <<<package>>> phase (and all its preceding build phases of the default lifecycle).
+
+ Moreover, if a goal is bound to one or more build phases, that goal will be called in all those phases.
+
+ Furthermore, a build phase can also have zero or more goals bound to it. If a build phase has no goals bound to it,
+ that build phase will not execute. But if it has one or more goals bound to it, it will execute all those goals.
+~~~
+~~~ Check if the following is true for Maven 3...
+ (<Note: In Maven 2.0.5 and above, multiple goals bound to a phase are executed in the same order as they are declared in the
+ POM, however multiple instances of the same plugin are not supported. Multiple instances of the same plugin are grouped to execute together and ordered in
+ Maven 2.0.11 and above>).
+~~~
+
+ <{{{./introduction-to-the-lifecycle.html}[top]}}.>
+
+** {Some Phases Are Not Usually Called From the Command Line}
+
+ The phases named with hyphenated-words (<<<pre-*>>>, <<<post-*>>>, or <<<process-*>>>) are not usually directly
+ called from the command line. These phases sequence the build, producing intermediate results that are not useful outside
+ the build. In the case of invoking <<<integration-test>>>, the environment may be left in a hanging state.
+
+ Code coverage tools such as Jacoco and execution container plugins such as Tomcat, Cargo, and Docker bind goals to the
+ <<<pre-integration-test>>> phase to prepare the integration test container environment. These plugins also bind goals
+ to the <<<post-integration-test>>> phase to collect coverage statistics or decommission the integration test container.
+
+ Failsafe and code coverage plugins bind goals to <<<integration-test>>> and <<<verify>>> phases. The net result is
+ test and coverage reports are available after the <<<verify>>> phase. If <<<integration-test>>> were to be called from the
+ command line, no reports are generated. Worse is that the integration test container environment is left in a hanging
+ state; the Tomcat webserver or Docker instance is left running, and Maven may not even terminate by itself.
+
+ <{{{./introduction-to-the-lifecycle.html}[top]}}.>
+
+* {Setting Up Your Project to Use the Build Lifecycle}
+
+ The build lifecycle is simple enough to use, but when you are constructing a Maven build for a project, how do you go
+ about assigning tasks to each of those build phases?
+
+** {Packaging}
+
+ The first, and most common way, is to set the packaging for your project via the equally named POM element <<<\<packaging\>>>>. Some of the valid
+ packaging values are <<<jar>>>, <<<war>>>, <<<ear>>> and <<<pom>>>. If no packaging value has been specified, it will default
+ to <<<jar>>>.
+
+ Each packaging contains a list of goals to bind to a particular phase. For example, the <<<jar>>> packaging will bind the following
+ goals to build phases of the default lifecycle.
+
+*------------------------------+---------------------------------------------------------------------------------------+
+|| Phase || plugin:goal
+*------------------------------+---------------------------------------------------------------------------------------+
+| <<<process-resources>>> | <<<resources:resources>>>
+*------------------------------+---------------------------------------------------------------------------------------+
+| <<<compile>>> | <<<compiler:compile>>>
+*------------------------------+---------------------------------------------------------------------------------------+
+| <<<process-test-resources>>> | <<<resources:testResources>>>
+*------------------------------+---------------------------------------------------------------------------------------+
+| <<<test-compile>>> | <<<compiler:testCompile>>>
+*------------------------------+---------------------------------------------------------------------------------------+
+| <<<test>>> | <<<surefire:test>>>
+*------------------------------+---------------------------------------------------------------------------------------+
+| <<<package>>> | <<<jar:jar>>>
+*------------------------------+---------------------------------------------------------------------------------------+
+| <<<install>>> | <<<install:install>>>
+*------------------------------+---------------------------------------------------------------------------------------+
+| <<<deploy>>> | <<<deploy:deploy>>>
+*------------------------------+---------------------------------------------------------------------------------------+
+
+ This is an almost {{{/ref/current/maven-core/default-bindings.html}standard set of bindings}};
+ however, some packagings handle them differently. For example, a project
+ that is purely metadata (packaging value is <<<pom>>>) only binds goals to the <<<install>>> and <<<deploy>>> phases (for a
+ complete list of goal-to-build-phase bindings of some of the packaging types, refer to the
+ {{{Lifecycle_Reference}Lifecycle Reference}}).
+
+ Note that for some packaging types to be available, you may also need to include a particular plugin in the
+ <<<\<build\>>>> section of your POM and specify <<<\<extensions\>true\</extensions\>>>> for that plugin.
+ One example of a plugin that requires this is the Plexus plugin, which provides a <<<plexus-application>>> and
+ <<<plexus-service>>> packaging.
+
+ <{{{./introduction-to-the-lifecycle.html}[top]}}.>
+
+** {Plugins}
+
+ The second way to add goals to phases is to configure plugins in your project. Plugins are artifacts that provide
+ goals to Maven. Furthermore, a plugin may have one or more goals wherein each goal represents a capability of that
+ plugin. For example, the Compiler plugin has two goals: <<<compile>>> and <<<testCompile>>>. The former
+ compiles the source code of your main code, while the latter compiles the source code of your test code.
+
+ As you will see in the later sections, plugins can contain information that indicates which lifecycle phase to bind a
+ goal to. Note that adding the plugin on its own is not enough information - you must also specify the goals you want
+ to run as part of your build.
+
+ The goals that are configured will be added to the goals already bound to the lifecycle from the packaging selected.
+ If more than one goal is bound to a particular phase, the order used is that those from the packaging are executed
+ first, followed by those configured in the POM. Note that you can use the <<<\<executions\>>>> element to gain more
+ control over the order of particular goals.
+
+ For example, the Modello plugin binds by default its goal <<<modello:java>>> to the <<<generate-sources>>> phase (Note: The
+ <<<modello:java>>> goal generates Java source codes). So to use the Modello plugin and have it generate sources from
+ a model and incorporate that into the build, you would add the following to your POM in the <<<\<plugins\>>>> section of
+ <<<\<build\>>>>:
+
++----+
+ <plugin>
+ <groupId>org.codehaus.modello</groupId>
+ <artifactId>modello-maven-plugin</artifactId>
+ <version>1.8.1</version>
+ <executions>
+ <execution>
+ <configuration>
+ <models>
+ <model>src/main/mdo/maven.mdo</model>
+ </models>
+ <version>4.0.0</version>
+ </configuration>
+ <goals>
+ <goal>java</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
++----+
+
+ You might be wondering why that <<<\<executions\>>>> element is there. That is so that you can run the same goal multiple times
+ with different configuration if needed. Separate executions can also be given an ID so that during inheritance or the
+ application of profiles you can control whether goal configuration is merged or turned into an additional execution.
+
+ When multiple executions are given that match a particular phase, they are executed in the order specified in the POM,
+ with inherited executions running first.
+
+ Now, in the case of <<<modello:java>>>, it only makes sense in the <<<generate-sources>>> phase. But some goals can be
+ used in more than one phase, and there may not be a sensible default. For those, you can specify the phase yourself.
+ For example, let's say you have a goal <<<display:time>>> that echos the current time to the commandline, and you want
+ it to run in the <<<process-test-resources>>> phase to indicate when the tests were started. This would be configured
+ like so:
+
++----+
+ <plugin>
+ <groupId>com.mycompany.example</groupId>
+ <artifactId>display-maven-plugin</artifactId>
+ <version>1.0</version>
+ <executions>
+ <execution>
+ <phase>process-test-resources</phase>
+ <goals>
+ <goal>time</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
++----+
+
+ <{{{./introduction-to-the-lifecycle.html}[top]}}.>
+
+* {Lifecycle Reference}
+
+ The following lists all build phases of the <<<default>>>, <<<clean>>> and <<<site>>> lifecycles, which are executed in the order given
+ up to the point of the one specified.
+
+** Clean Lifecycle
+
+*-------------------------------+---------------------------------------------------------------------------------------+
+|| Phase || Description
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<pre-clean>>> | execute processes needed prior to the actual project cleaning
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<clean>>> | remove all files generated by the previous build
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<post-clean>>> | execute processes needed to finalize the project cleaning
+*-------------------------------+--------------------------------------------------------------------------------------+
+
+** Default Lifecycle
+
+*-------------------------------+---------------------------------------------------------------------------------------+
+|| Phase || Description
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<validate>>> | validate the project is correct and all necessary information is available.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<initialize>>> | initialize build state, e.g. set properties or create directories.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<generate-sources>>> | generate any source code for inclusion in compilation.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-sources>>> | process the source code, for example to filter any values.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<generate-resources>>> | generate resources for inclusion in the package.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-resources>>> | copy and process the resources into the destination directory, ready for packaging.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<compile>>> | compile the source code of the project.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-classes>>> | post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<generate-test-sources>>> | generate any test source code for inclusion in compilation.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-test-sources>>> | process the test source code, for example to filter any values.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<generate-test-resources>>> | create resources for testing.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-test-resources>>> | copy and process the resources into the test destination directory.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<test-compile>>> | compile the test source code into the test destination directory
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-test-classes>>> | post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<test>>> | run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<prepare-package>>> | perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<package>>> | take the compiled code and package it in its distributable format, such as a JAR.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<pre-integration-test>>> | perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<integration-test>>> | process and deploy the package if necessary into an environment where integration tests can be run.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<post-integration-test>>> | perform actions required after integration tests have been executed. This may including cleaning up the environment.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<verify>>> | run any checks to verify the package is valid and meets quality criteria.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<install>>> | install the package into the local repository, for use as a dependency in other projects locally.
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<deploy>>> | done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
+*-------------------------------+--------------------------------------------------------------------------------------+
+
+** Site Lifecycle
+
+*-------------------------------+---------------------------------------------------------------------------------------+
+|| Phase || Description
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<pre-site>>> | execute processes needed prior to the actual project site generation
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<site>>> | generate the project's site documentation
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<post-site>>> | execute processes needed to finalize the site generation, and to prepare for site deployment
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<site-deploy>>> | deploy the generated site documentation to the specified web server
+*-------------------------------+--------------------------------------------------------------------------------------+
+
+ <{{{./introduction-to-the-lifecycle.html}[top]}}.>
+
+* {Built-in Lifecycle Bindings}
+
+ Some phases have goals bound to them by default. And for the default lifecycle, these bindings depend on
+ the packaging value. Here are some of the goal-to-build-phase bindings.
+
+** Clean Lifecycle Bindings
+
+*-------------------------------+--------------------------------------------------------------------------------------+
+|| Phase || plugin:goal
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<clean>>> | <<<clean:clean>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+
+** Default Lifecycle Bindings - Packaging <<<ejb>>> / <<<ejb3>>> / <<<jar>>> / <<<par>>> / <<<rar>>> / <<<war>>>
+
+*-------------------------------+--------------------------------------------------------------------------------------+
+|| Phase || plugin:goal
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-resources>>> | <<<resources:resources>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<compile>>> | <<<compiler:compile>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-test-resources>>> | <<<resources:testResources>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<test-compile>>> | <<<compiler:testCompile>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<test>>> | <<<surefire:test>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<package>>> | <<<ejb:ejb>>> <or> <<<ejb3:ejb3>>> <or> <<<jar:jar>>> <or> <<<par:par>>> <or> <<<rar:rar>>> <or> <<<war:war>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<install>>> | <<<install:install>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<deploy>>> | <<<deploy:deploy>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+
+** Default Lifecycle Bindings - Packaging <<<ear>>>
+
+*-------------------------------+--------------------------------------------------------------------------------------+
+|| Phase || plugin:goal
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<generate-resources>>> | <<<ear:generate-application-xml>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-resources>>> | <<<resources:resources>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<package>>> | <<<ear:ear>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<install>>> | <<<install:install>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<deploy>>> | <<<deploy:deploy>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+
+** Default Lifecycle Bindings - Packaging <<<maven-plugin>>>
+
+*-------------------------------+--------------------------------------------------------------------------------------+
+|| Phase || plugin:goal
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<generate-resources>>> | <<<plugin:descriptor>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-resources>>> | <<<resources:resources>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<compile>>> | <<<compiler:compile>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<process-test-resources>>> | <<<resources:testResources>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<test-compile>>> | <<<compiler:testCompile>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<test>>> | <<<surefire:test>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<package>>> | <<<jar:jar>>> <and> <<<plugin:addPluginArtifactMetadata>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<install>>> | <<<install:install>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<deploy>>> | <<<deploy:deploy>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+
+** Default Lifecycle Bindings - Packaging <<<pom>>>
+
+*-------------------------------+--------------------------------------------------------------------------------------+
+|| Phase || plugin:goal
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<package>>> |
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<install>>> | <<<install:install>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<deploy>>> | <<<deploy:deploy>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+
+** Site Lifecycle Bindings
+
+*-------------------------------+--------------------------------------------------------------------------------------+
+|| Phase || plugin:goal
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<site>>> | <<<site:site>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+| <<<site-deploy>>> | <<<site:deploy>>>
+*-------------------------------+--------------------------------------------------------------------------------------+
+
+** References
+
+ The full Maven lifecycle is defined by the <<<components.xml>>> file in the <<<maven-core>>> module, with
+ {{{/ref/current/maven-core/lifecycles.html}associated documentation}} for reference.
+
+ Default lifecycle bindings are defined in a separate
+ <<<{{{https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml}default-bindings.xml}}>>>
+ descriptor.
+
+ See {{{/ref/current/maven-core/lifecycles.html}Lifecycles Reference}} and
+ {{{/ref/current/maven-core/default-bindings.html}Plugin Bindings for default Lifecycle Reference}} for latest documentation taken directly from
+ source code.
+
+ <{{{./introduction-to-the-lifecycle.html}[top]}}.>
diff --git a/content/apt/guides/introduction/introduction-to-the-pom.apt b/content/apt/guides/introduction/introduction-to-the-pom.apt
new file mode 100644
index 00000000..f75baf22
--- /dev/null
+++ b/content/apt/guides/introduction/introduction-to-the-pom.apt
@@ -0,0 +1,577 @@
+ ------
+ Introduction to the POM
+ ------
+ Jason van Zyl
+ Franz Allan Valencia See
+ Brett Porter
+ ------
+ 2009-02-04
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction to the POM
+
+ * {{{./introduction-to-the-pom.html#What_is_a_POM}What is a POM}}?
+
+ * {{{./introduction-to-the-pom.html#Super_POM}Super POM}}
+
+ * {{{./introduction-to-the-pom.html#Minimal_POM}Minimal POM}}
+
+ * {{{./introduction-to-the-pom.html#Project_Inheritance}Project Inheritance}}
+
+ * {{{./introduction-to-the-pom.html#Example_1}Example 1}}
+
+ * {{{./introduction-to-the-pom.html#Example_2}Example 2}}
+
+ []
+
+ * {{{./introduction-to-the-pom.html#Project_Aggregation}Project Aggregation}}
+
+ * {{{./introduction-to-the-pom.html#Example_3}Example 3}}
+
+ * {{{./introduction-to-the-pom.html#Example_4}Example 4}}
+
+ []
+
+ * {{{./introduction-to-the-pom.html#Project_Inheritance_vs_Project_Aggregation}Project Inheritance vs Project Aggregation}}
+
+ * {{{./introduction-to-the-pom.html#Example_5}Example 5}}
+
+ []
+
+ * {{{./introduction-to-the-pom.html#Project_Interpolation}Project Interpolation and Variables}}
+
+ * {{{./introduction-to-the-pom.html#Available_Variables}Available Variables}}
+
+ []
+
+ []
+
+* {What is a POM}?
+
+ A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information
+ about the project and configuration details used by Maven to build the project. It contains default values for most projects.
+ Examples for this is the build directory, which is <<<target>>>; the source directory, which is <<<src/main/java>>>; the test
+ source directory, which is <<<src/test/java>>>; and so on. When executing a task or goal, Maven
+ looks for the POM in the current directory. It reads the POM, gets the needed configuration information, then executes the
+ goal.
+
+ Some of the configuration that can be specified in the POM are the project dependencies, the plugins or goals that
+ can be executed, the build profiles, and so on. Other information such as the project version, description, developers,
+ mailing lists and such can also be specified.
+
+ {{{./introduction-to-the-pom.html}[top]}}
+
+* {Super POM}
+
+ The Super POM is Maven's default POM. All POMs extend the Super POM unless explicitly set, meaning the configuration specified
+ in the Super POM is inherited by the POMs you created for your projects.
+
+ You can see the {{{/ref/3.6.3/maven-model-builder/super-pom.html}Super POM for Maven 3.6.3}} in Maven Core reference documentation.
+
+ {{{./introduction-to-the-pom.html}[top]}}
+
+* {Minimal POM}
+
+ The minimum requirement for a POM are the following:
+
+ * <<<project>>> root
+
+ * <<<modelVersion>>> - should be set to 4.0.0
+
+ * <<<groupId>>> - the id of the project's group.
+
+ * <<<artifactId>>> - the id of the artifact (project)
+
+ * <<<version>>> - the version of the artifact under the specified group
+
+ []
+
+ Here's an example:
+
++-----+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1</version>
+</project>
++-----+
+
+ A POM requires that its groupId, artifactId, and version be configured. These three values form the project's fully
+ qualified artifact name. This is in the form of \<groupId\>:\<artifactId\>:\<version\>. As for the example above, its
+ fully qualified artifact name is "com.mycompany.app:my-app:1".
+
+ Also, as mentioned in the {{{What_is_a_POM}first section}}, if the configuration details
+ are not specified, Maven will use their defaults. One of these default values is the packaging type. Every Maven project
+ has a packaging type. If it is not specified in the POM, then the default value "jar" would be used.
+
+ Furthermore, you can see that in the minimal POM the <repositories> were not specified. If you build your project using the minimal POM,
+ it would inherit the <repositories> configuration in the Super POM. Therefore when Maven sees the dependencies in
+ the minimal POM, it would know that these dependencies will be downloaded from <<<https://repo.maven.apache.org/maven2>>> which was specified
+ in the Super POM.
+
+ {{{./introduction-to-the-pom.html}[top]}}
+
+* {Project Inheritance}
+
+ Elements in the POM that are merged are the following:
+
+ * dependencies
+
+ * developers and contributors
+
+ * plugin lists (including reports)
+
+ * plugin executions with matching ids
+
+ * plugin configuration
+
+ * resources
+
+ []
+
+ The Super POM is one example of project inheritance, however you can also introduce your own parent POMs by specifying
+ the parent element in the POM, as demonstrated in the following examples.
+
+ []
+
+** {Example 1}
+
+*** The Scenario
+
+ As an example, let us reuse our previous artifact, com.mycompany.app:my-app:1. And let us introduce another artifact,
+ com.mycompany.app:my-module:1.
+
++-----+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-module</artifactId>
+ <version>1</version>
+</project>
++-----+
+
+ And let us specify their directory structure as the following:
+
+-----
+.
+ |-- my-module
+ | `-- pom.xml
+ `-- pom.xml
+-----
+
+ <<Note:>> <<<my-module/pom.xml>>> is the POM of com.mycompany.app:my-module:1 while <<<pom.xml>>> is the POM of
+ com.mycompany.app:my-app:1
+
+*** The Solution
+
+ Now, if we were to turn com.mycompany.app:my-app:1 into a parent artifact of com.mycompany.app:my-module:1,we will have to
+ modify com.mycompany.app:my-module:1's POM to the following configuration:
+
+ <<com.mycompany.app:my-module:1's POM>>
+
++-----+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+
+ <parent>
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1</version>
+ </parent>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-module</artifactId>
+ <version>1</version>
+</project>
++-----+
+
+ Notice that we now have an added section, the parent section. This section allows us to specify which artifact is the
+ parent of our POM. And we do so by specifying the fully qualified artifact name of the parent POM. With this setup, our
+ module can now inherit some of the properties of our parent POM.
+
+ Alternatively, if you want the groupId or the version of your modules to be the same as their parents, you can
+ remove the groupId or the version identity of your module in its POM.
+
++-----+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+
+ <parent>
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1</version>
+ </parent>
+
+ <artifactId>my-module</artifactId>
+</project>
++-----+
+
+ This allows the module to inherit the groupId or the version of its parent POM.
+
+ {{{./introduction-to-the-pom.html}[top]}}
+
+** {Example 2}
+
+*** The Scenario
+
+ However, that would work if the parent project was already installed in our local repository or was in that specific
+ directory structure (parent <<<pom.xml>>> is one directory higher than that of the module's <<<pom.xml>>>).
+
+ But what if the parent is not yet installed and if the directory structure is as in the following example?
+
+-----
+.
+ |-- my-module
+ | `-- pom.xml
+ `-- parent
+ `-- pom.xml
+-----
+
+*** The Solution
+
+ To address this directory structure (or any other directory structure), we would have to add the <<<\<relativePath\>>>> element to
+ our parent section.
+
++-----+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+
+ <parent>
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1</version>
+ <relativePath>../parent/pom.xml</relativePath>
+ </parent>
+
+ <artifactId>my-module</artifactId>
+</project>
++-----+
+
+ As the name suggests, it's the relative path from the module's <<<pom.xml>>> to the parent's <<<pom.xml>>>.
+
+* {Project Aggregation}
+
+ Project Aggregation is similar to {{{Project_Inheritance}Project Inheritance}}. But
+ instead of specifying the parent POM from the module, it specifies the modules from the parent POM. By doing so, the
+ parent project now knows its modules, and if a Maven command is invoked against the parent project, that Maven command
+ will then be executed to the parent's modules as well. To do Project Aggregation, you must do the following:
+
+ * Change the parent POMs packaging to the value "pom".
+
+ * Specify in the parent POM the directories of its modules (children POMs).
+
+ []
+
+ {{{./introduction-to-the-pom.html}[top]}}
+
+** {Example 3}
+
+*** The Scenario
+
+ Given the previous original artifact POMs and directory structure:
+
+ <<com.mycompany.app:my-app:1's POM>>
+
++-----+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1</version>
+</project>
++-----+
+
+ <<com.mycompany.app:my-module:1's POM>>
+
++-----+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-module</artifactId>
+ <version>1</version>
+</project>
++-----+
+
+ <<directory structure>>
+
+-----
+.
+ |-- my-module
+ | `-- pom.xml
+ `-- pom.xml
+-----
+
+*** The Solution
+
+ If we are to aggregate my-module into my-app, we would only have to modify my-app.
+
++-----+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1</version>
+ <packaging>pom</packaging>
+
+ <modules>
+ <module>my-module</module>
+ </modules>
+</project>
++-----+
+
+ In the revised com.mycompany.app:my-app:1, the packaging section and the modules sections were added. For
+ the packaging, its value was set to "pom", and for the modules section, we have the element
+ <<<\<module\>my-module\</module\>>>>. The value of <<<\<module\>>>> is the relative path from the com.mycompany.app:my-app:1
+ to com.mycompany.app:my-module:1's POM (<by practice, we use the module's artifactId as the module directory's name>).
+
+ Now, whenever a Maven command processes com.mycompany.app:my-app:1, that same Maven command would be ran against
+ com.mycompany.app:my-module:1 as well. Furthermore, some commands (goals specifically) handle project aggregation
+ differently.
+
+ {{{./introduction-to-the-pom.html}[top]}}
+
+** {Example 4}
+
+*** The Scenario
+
+ But what if we change the directory structure to the following:
+
+-----
+.
+ |-- my-module
+ | `-- pom.xml
+ `-- parent
+ `-- pom.xml
+-----
+
+ How would the parent POM specify its modules?
+
+*** The Solution
+
+ The answer? - the same way as Example 3, by specifying the path to the module.
+
++-----+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1</version>
+ <packaging>pom</packaging>
+
+ <modules>
+ <module>../my-module</module>
+ </modules>
+</project>
++-----+
+
+* {Project Inheritance vs Project Aggregation}
+
+ If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling
+ out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects
+ inherit that parent project, and those configurations would then be applied to all of them.
+
+ And if you have a group of projects that are built or processed together, you can create a parent project and have that
+ parent project declare those projects as its modules. By doing so, you'd only have to build the parent and the rest
+ will follow.
+
+ But of course, you can have both Project Inheritance and Project Aggregation. Meaning, you can have your modules
+ specify a parent project, and at the same time, have that parent project specify those Maven projects as its modules.
+ You'd just have to apply all three rules:
+
+ * Specify in every child POM who their parent POM is.
+
+ * Change the parent POMs packaging to the value "pom" .
+
+ * Specify in the parent POM the directories of its modules (children POMs)
+
+ []
+
+ {{{./introduction-to-the-pom.html}[top]}}
+
+** {Example 5}
+
+*** The Scenario
+
+ Given the previous original artifact POMs again,
+
+ <<com.mycompany.app:my-app:1's POM>>
+
++-----+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1</version>
+</project>
++-----+
+
+ <<com.mycompany.app:my-module:1's POM>>
+
++-----+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-module</artifactId>
+ <version>1</version>
+</project>
++-----+
+
+ and this <<directory structure>>
+
+-----
+.
+ |-- my-module
+ | `-- pom.xml
+ `-- parent
+ `-- pom.xml
+-----
+
+*** The Solution
+
+ To do both project inheritance and aggregation, you only have to apply all three rules.
+
+ <<com.mycompany.app:my-app:1's POM>>
+
++-----+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1</version>
+ <packaging>pom</packaging>
+
+ <modules>
+ <module>../my-module</module>
+ </modules>
+</project>
++-----+
+
+ <<com.mycompany.app:my-module:1's POM>>
+
++-----+
+<project>
+ <modelVersion>4.0.0</modelVersion>
+
+ <parent>
+ <groupId>com.mycompany.app</groupId>
+ <artifactId>my-app</artifactId>
+ <version>1</version>
+ <relativePath>../parent/pom.xml</relativePath>
+ </parent>
+
+ <artifactId>my-module</artifactId>
+</project>
++-----+
+
+ <<NOTE:>> Profile inheritance the same inheritance strategy as used for the POM itself.
+
+ {{{./introduction-to-the-pom.html}[top]}}
+
+* {Project Interpolation} and Variables
+
+ One of the practices that Maven encourages is <don't repeat yourself>. However, there are circumstances where you will need to use the same value in several different locations.
+ To assist in ensuring the value is only specified once, Maven allows you to use both your own and pre-defined variables in the POM.
+
+ For example, to access the <<<project.version>>> variable, you would reference it like so:
+
++----+
+ <version>${project.version}</version>
++----+
+
+ One factor to note is that these variables are processed <after> inheritance as outlined above. This means that if a parent project uses a variable, then its definition in the child, not the parent, will be the one eventually used.
+
+** {Available Variables}
+
+*** Project Model Variables
+
+ Any field of the model that is a single value element can be referenced as a variable. For example, <<<$\{project.groupId\}>>>, <<<$\{project.version\}>>>, <<<$\{project.build.sourceDirectory\}>>> and so on.
+ Refer to the POM reference to see a full list of properties.
+
+ These variables are all referenced by the prefix "<<<project.>>>". You may also see references with <<<pom.>>> as the prefix, or the prefix omitted entirely - these forms are now deprecated and should not be used.
+
+*** Special Variables
+
+*-----------------------------------+--------------------------------------+
+| <<<project.basedir>>> | The directory that the current project resides in. |
+*-----------------------------------+--------------------------------------+
+| <<<project.baseUri>>> | The directory that the current project resides in, represented as an URI. <Since Maven 2.1.0> |
+*-----------------------------------+--------------------------------------+
+| <<<maven.build.timestamp>>> | The timestamp that denotes the start of the build (UTC). <Since Maven 2.1.0-M1> |
+*-----------------------------------+--------------------------------------+
+
+ The format of the build timestamp can be customized by declaring the property <<<maven.build.timestamp.format>>> as
+ shown in the example below:
+
++----+
+<project>
+ ...
+ <properties>
+ <maven.build.timestamp.format>yyyy-MM-dd'T'HH:mm:ss'Z'</maven.build.timestamp.format>
+ </properties>
+ ...
+</project>
++----+
+
+ The format pattern has to comply with the rules given in the API documentation for
+ {{{https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html}SimpleDateFormat}}.
+ If the property is not present, the format defaults to the value already given in the example.
+
+*** Properties
+
+ You are also able to reference any properties defined in the project as a variable. Consider the following example:
+
++----+
+<project>
+ ...
+ <properties>
+ <mavenVersion>3.0</mavenVersion>
+ </properties>
+
+ <dependencies>
+ <dependency>
+ <groupId>org.apache.maven</groupId>
+ <artifactId>maven-artifact</artifactId>
+ <version>${mavenVersion}</version>
+ </dependency>
+ <dependency>
+ <groupId>org.apache.maven</groupId>
+ <artifactId>maven-core</artifactId>
+ <version>${mavenVersion}</version>
+ </dependency>
+ </dependencies>
+ ...
+</project>
++----+
+
+ {{{./introduction-to-the-pom.html}[top]}}
+
diff --git a/content/apt/guides/introduction/introduction-to-the-standard-directory-layout.apt b/content/apt/guides/introduction/introduction-to-the-standard-directory-layout.apt
new file mode 100644
index 00000000..531208bc
--- /dev/null
+++ b/content/apt/guides/introduction/introduction-to-the-standard-directory-layout.apt
@@ -0,0 +1,86 @@
+ ------
+ Introduction to the Standard Directory Layout
+ ------
+ Jason van Zyl
+ ------
+ 2014-03-09
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Introduction to the Standard Directory Layout
+
+ Having a common directory layout allows users familiar with one Maven project to immediately feel
+ at home in another Maven project. The advantages are analogous to adopting a site-wide look-and-feel.
+
+ The next section documents the directory layout expected by Maven and the directory layout created by
+ Maven. Try to conform to this structure as much as possible. However, if you can't, these settings can
+ be overridden via the project descriptor.
+
+*-----------------------------------+-----------------------------------------------+
+| <<<src/main/java>>> | Application/Library sources
+*-----------------------------------+-----------------------------------------------+
+| <<<src/main/resources>>> | Application/Library resources
+*-----------------------------------+-----------------------------------------------+
+| <<<src/main/filters>>> | Resource filter files
+*-----------------------------------+-----------------------------------------------+
+| <<<src/main/webapp>>> | Web application sources
+*-----------------------------------+-----------------------------------------------+
+| <<<src/test/java>>> | Test sources
+*-----------------------------------+-----------------------------------------------+
+| <<<src/test/resources>>> | Test resources
+*-----------------------------------+-----------------------------------------------+
+| <<<src/test/filters>>> | Test resource filter files
+*-----------------------------------+-----------------------------------------------+
+| <<<src/it>>> | Integration Tests (primarily for plugins)
+*-----------------------------------+-----------------------------------------------+
+| <<<src/assembly>>> | Assembly descriptors
+*-----------------------------------+-----------------------------------------------+
+| <<<src/site>>> | Site
+*-----------------------------------+-----------------------------------------------+
+| <<<LICENSE.txt>>> | Project's license
+*-----------------------------------+-----------------------------------------------+
+| <<<NOTICE.txt>>> | Notices and attributions required by libraries that the project depends on
+*-----------------------------------+-----------------------------------------------+
+| <<<README.txt>>> | Project's readme
+*-----------------------------------+-----------------------------------------------+
+
+
+ At the top level, files descriptive of the project: a <<<pom.xml>>> file.
+ In addition, there are textual documents meant for the user to be able to
+ read immediately on receiving the source: <<<README.txt>>>, <<<LICENSE.txt>>>, etc.
+
+ There are just two subdirectories of this structure: <<<src>>> and <<<target>>>. The only other
+ directories that would be expected here are metadata like <<<CVS>>>, <<<.git>>> or <<<.svn>>>, and any
+ subprojects in a multiproject build (each of which would be laid out as above).
+
+ The <<<target>>> directory is used to house all output of the build.
+
+ The <<<src>>> directory contains all of the source material for building the project, its site and so on.
+ It contains a subdirectory for each type: <<<main>>> for the main build artifact, <<<test>>> for
+ the unit test code and resources, <<<site>>> and so on.
+
+ Within artifact producing source directories (ie. <<<main>>> and <<<test>>>), there is one
+ directory for the language <<<java>>> (under which the normal package hierarchy exists), and one for
+ <<<resources>>> (the structure which is copied to the target classpath given the default resource definition).
+
+ If there are other contributing sources to the artifact build, they would be under other subdirectories. For
+ example <<<src/main/antlr>>> would contain Antlr grammar definition files.
diff --git a/content/apt/guides/mini/guide-3rd-party-jars-local.apt b/content/apt/guides/mini/guide-3rd-party-jars-local.apt
new file mode 100644
index 00000000..4c424769
--- /dev/null
+++ b/content/apt/guides/mini/guide-3rd-party-jars-local.apt
@@ -0,0 +1,59 @@
+ ------
+ Guide to installing 3rd party JARs
+ ------
+ Jason van Zyl
+ Robert Scholte
+ ------
+ 2013-07-13
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Guide to installing 3rd party JARs
+
+ Occasionally, you will have 3rd party JARs that you need to put in your local repository for use in your
+ builds, since they don't exist in any public repository like {{{https://search.maven.org}Maven Central}}.
+ The JARs must be placed in the local repository in the correct place in order for it to be correctly
+ picked up by Apache Maven.
+
+ To make this easier, and less error prone, we have provided an <<<install-file>>> goal in the
+ {{{/plugins/maven-install-plugin/}maven-install-plugin}} which should make this relatively painless.
+
+ To install a JAR in the local repository use the following command:
+
+----
+mvn install:install-file -Dfile=<path-to-file> -DgroupId=<group-id> -DartifactId=<artifact-id> -Dversion=<version> -Dpackaging=<packaging>
+----
+
+ If there's a pom-file as well, you can install it with the following command:
+
+----
+mvn install:install-file -Dfile=<path-to-file> -DpomFile=<path-to-pomfile>
+----
+
+ With version 2.5 of the maven-install-plugin, it can get even simpler: if the JAR was built by Apache Maven, it'll contain a
+ pom.xml in a subfolder of the META-INF/ directory, which will be read by default. In that case, all you need to do is:
+
+----
+mvn org.apache.maven.plugins:maven-install-plugin:2.5.2:install-file -Dfile=<path-to-file>
+----
+
+
diff --git a/content/apt/guides/mini/guide-3rd-party-jars-remote.apt b/content/apt/guides/mini/guide-3rd-party-jars-remote.apt
new file mode 100644
index 00000000..9670586d
--- /dev/null
+++ b/content/apt/guides/mini/guide-3rd-party-jars-remote.apt
@@ -0,0 +1,87 @@
+ ------
+ Guide to deploying 3rd party JARs to remote repository
+ ------
+ Allan Ramirez
+ ------
+ 2006-02-22
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Guide to deploying 3rd party JARs to remote repository
+
+ Same concept of the {{{./guide-3rd-party-jars-local.html}install:install-file}}
+ goal of the maven-install-plugin where the 3rd party JAR is installed
+ in the local repository. But this time instead to local repository the
+ JAR will be install both in the local and remote repository.
+
+ To deploy a 3rd party JAR use the deploy:deploy-file goal under
+ maven-deploy-plugin.
+
+ First, the wagon-provider(wagon-ftp, wagon-file, etc..) must be placed to
+ your <<<$\{maven.home\}/lib>>>.
+
+ Then execute the command:
+
+------
+mvn deploy:deploy-file -DgroupId=<group-id> \
+ -DartifactId=<artifact-id> \
+ -Dversion=<version> \
+ -Dpackaging=<type-of-packaging> \
+ -Dfile=<path-to-file> \
+ -DrepositoryId=<id-to-map-on-server-section-of-settings.xml> \
+ -Durl=<url-of-the-repository-to-deploy>
+------
+
+* Deploying a 3rd party JAR with a generic POM
+
+ By default, deploy:deploy-file generates a generic POM(.pom) to be deploy
+ together with the 3rd party JAR. To disable this feature we should set the
+ <<<generatePOM>>> argument to false.
+
+------
+-DgeneratePom=false
+------
+
+* Deploying a 3rd party JAR with a customized POM
+
+ If a POM is already existing for the 3rd Party JAR and you want to deploy
+ it together with the JAR we should use the <<<pomFile>>> argument of the
+ deploy-file goal. See sample below.
+
+------
+mvn deploy:deploy-file -DpomFile=<path-to-pom> \
+ -Dfile=<path-to-file> \
+ -DrepositoryId=<id-to-map-on-server-section-of-settings.xml> \
+ -Durl=<url-of-the-repository-to-deploy>
+------
+
+ Note that <<<groupId>>>, <<<artifactId>>>, <<<version>>> and <<<packaging>>>
+ arguments are not included here because deploy-file goal will get these
+ information from the given POM.
+
+* Deploying Source Jars
+
+~~ TODO: Check the following, cause i don't this is true anymore. I assume packaging should be jar
+~~ and the classifier should be set to source.
+
+ To deploy a 3rd party source jar, packaging should be set to <<<java-source>>>, and
+ generatePom should be set to <<<false>>>.
diff --git a/content/apt/guides/mini/guide-archive-configuration.apt b/content/apt/guides/mini/guide-archive-configuration.apt
new file mode 100644
index 00000000..f0011a25
--- /dev/null
+++ b/content/apt/guides/mini/guide-archive-configuration.apt
@@ -0,0 +1,71 @@
+ ------
+ Guide to Configuring Archive Plugins
+ ------
+ Brett Porter
+ ------
+ 2006-06-21
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Guide to Configuring Archive Plugins
+
+ Many Java archive generating plugins accept the <<<archive>>> configuration element to customize the generation of the archive.
+ In the standard Maven Plugins, this includes the <<<jar>>>, <<<war>>>, <<<ejb>>>, <<<ear>>> and <<<assembly>>> plugins.
+
+* Disabling Maven Meta Information
+
+ By default, Maven generated archives include the <<<META-INF/maven>>> directory, which contains the <<<pom.xml>>> file used to
+ build the archive, and a <<<pom.properties>>> file that includes some basic properties in a small, easier to read format.
+
+ To disable the generation of these files, include the following configuration for your plugin (in this example, the WAR plugin
+ is used):
+
++----+
+<project>
+ ...
+ <build>
+ <plugins>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-war-plugin</artifactId>
+ <version>2.6</version>
+ <configuration>
+ <archive>
+ <addMavenDescriptor>false</addMavenDescriptor>
+ </archive>
+ </configuration>
+ </plugin>
+ </plugins>
+ </build>
+ ...
+</project>
+
++----+
+
+~~ other things: index, compress
+
+* Configuring the Manifest
+
+ The archive configuration also accepts manifest configuration. See {{{./guide-manifest.html}Guide to Working with Manifests}} for more information.
+
+
+
diff --git a/content/markdown/guides/mini/guide-assemblies.md b/content/apt/guides/mini/guide-assemblies.apt
similarity index 66%
rename from content/markdown/guides/mini/guide-assemblies.md
rename to content/apt/guides/mini/guide-assemblies.apt
index efc5a943..f35ba587 100644
--- a/content/markdown/guides/mini/guide-assemblies.md
+++ b/content/apt/guides/mini/guide-assemblies.apt
@@ -1,34 +1,38 @@
-title: Guide to Creating Assemblies
-author: Jason van Zyl
-date: 2005-10-12
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## Guide to creating assemblies
-
-
- The assembly mechanism in Maven provides an easy way to create distributions using a assembly descriptor and dependency information found in you POM. In order to use the assembly plug-in you need to configure the assembly plug-in in your POM and it might look like the following:
-
-
-
-```
+ ------
+ Guide to Creating Assemblies
+ ------
+ Jason van Zyl
+ ------
+ 2005-10-12
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Guide to creating assemblies
+
+ The assembly mechanism in Maven provides an easy way to create distributions using a assembly descriptor
+ and dependency information found in you POM. In order to use the assembly plug-in you need to configure the
+ assembly plug-in in your POM and it might look like the following:
+
++----+
<project>
<parent>
<artifactId>maven</artifactId>
@@ -64,19 +68,18 @@ under the License.
</build>
...
</project>
-```
-
- You'll notice that the assembly descriptor is located in `$\{project.basedir\}/src/assembly` which is the [standard](../introduction/introduction-to-the-standard-directory-layout.html) location for assembly descriptors.
-
++----+
-### Creating a binary assembly
+ You'll notice that the assembly descriptor is located in <<<$\{project.basedir\}/src/assembly>>> which is the
+ {{{../introduction/introduction-to-the-standard-directory-layout.html}standard}} location for assembly
+ descriptors.
+* Creating a binary assembly
- This is the most typical usage of the assembly plugin where you are creating a distribution for standard use.
+ This is the most typical usage of the assembly plugin where you are creating a distribution for standard
+ use.
-
-
-```
++----+
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>bin</id>
@@ -108,16 +111,16 @@ under the License.
</fileSet>
</fileSets>
</assembly>
-```
-
- You can use a manually defined assembly descriptor as mentioned before but it is simpler to use the [pre-defined assembly descriptor bin](/plugins/maven-assembly-plugin/descriptor-refs.html#bin) in such cases.
-
-
- How to use such pre-defined assembly descriptors is described in the [documentation of maven-assembly-plugin](/plugins/maven-assembly-plugin/usage.html#Configuration).
++----+
+ You can use a manually defined assembly descriptor as mentioned before but it is simpler to use the
+ {{{/plugins/maven-assembly-plugin/descriptor-refs.html#bin}pre-defined assembly descriptor bin}}
+ in such cases.
+ How to use such pre-defined assembly descriptors is described in the
+ {{{/plugins/maven-assembly-plugin/usage.html#Configuration}documentation of maven-assembly-plugin}}.
-```
++----+
<assembly
xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
@@ -153,13 +156,13 @@ under the License.
</dependencySets>
</assembly>
-```
++----+
- If you like to create a source distribution package the best solution is to use the [pre-defined assembly descriptor src](/plugins/maven-assembly-plugin/descriptor-refs.html#src) for such purposes.
+ If you like to create a source distribution package the best solution is to use the
+ {{{/plugins/maven-assembly-plugin/descriptor-refs.html#src}pre-defined assembly descriptor src}}
+ for such purposes.
-
-
-```
++----+
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>src</id>
@@ -185,14 +188,11 @@ under the License.
</fileSet>
</fileSets>
</assembly>
-```
-
- You can now create the defined distribution packages via command line like this:
++----+
+ You can now create the defined distribution packages via command line like this:
-
-```
+------
mvn package
-```
-
+------
diff --git a/content/markdown/guides/mini/guide-attached-tests.md b/content/apt/guides/mini/guide-attached-tests.apt
similarity index 53%
rename from content/markdown/guides/mini/guide-attached-tests.md
rename to content/apt/guides/mini/guide-attached-tests.apt
index 3a363676..85bccc47 100644
--- a/content/markdown/guides/mini/guide-attached-tests.md
+++ b/content/apt/guides/mini/guide-attached-tests.apt
@@ -1,34 +1,39 @@
-title: Guide to using attached tests
-author: Jason van Zyl
-date: 2005-10-12
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## Guide to using attached tests
-
-
- You can reuse the tests that you have created for one project in another. For example, suppose `foo-core` contains test code in the `$\{basedir\}/src/test/java`. To package up those compiled tests in a JAR and deploy them for general reuse, configure the `maven-jar-plugin` as follows:
-
-
-
-```
+ ------
+ Guide to using attached tests
+ ------
+ Jason van Zyl
+ ------
+ 2005-10-12
+ ------
+
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements. See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership. The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License. You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied. See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+~~ NOTE: For help with the syntax of this file, see:
+~~ http://maven.apache.org/doxia/references/apt-format.html
+
+Guide to using attached tests
+
+ You can reuse the tests that you have created for one project in another. For example, suppose
+ <<<foo-core>>> contains test code in the <<<$\{basedir\}/src/test/java>>>. To package
+ up those compiled tests in a JAR and deploy them for general reuse, configure the
+ <<<maven-jar-plugin>>> as follows:
+
++----+
<project>
<build>
@@ -49,16 +54,14 @@ under the License.
</build>
</project>
-```
-
- The attached test JAR can be installed and deployed like any other Maven artifact.
-
-
- To use the attached test JAR, specify a dependency on the main artifact with a specified type of `test-jar` and the `classifier`.
++----+
+ The attached test JAR can be installed and deployed like any other Maven artifact.
+ To use the attached test JAR, specify a dependency on the main
+ artifact with a specified type of <<<test-jar>>> and the <<<classifier>>>.
-```
++----+
<project>
...
@@ -103,5 +106,5 @@ under the License.
...
</project>
-```
... 28179 lines suppressed ...
[maven-site] 03/14: Revert "[MNGSITE-509] Fix linking to anchors"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit b0eb56ddf7578910390ffe5727b18bef048a71d2
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:31:21 2023 +0100
Revert "[MNGSITE-509] Fix linking to anchors"
This reverts commit 0cc3ff422b0f00629c2c533a5a690f3f4a54c8d0.
---
content/markdown/developers/conventions/code.md | 24 ++++++-------
content/markdown/docs/3.5.3/release-notes.md | 2 +-
content/markdown/docs/3.5.4/release-notes.md | 2 +-
content/markdown/docs/3.6.0/release-notes.md | 4 +--
content/markdown/docs/3.6.1/release-notes.md | 4 +--
content/markdown/docs/3.6.2/release-notes.md | 4 +--
content/markdown/docs/3.6.3/release-notes.md | 4 +--
content/markdown/docs/3.8.1/release-notes.md | 2 +-
content/markdown/glossary.md | 2 +-
.../guides/development/guide-maven-development.md | 2 +-
content/markdown/guides/getting-started/index.md | 36 +++++++++----------
.../introduction-to-dependency-mechanism.md | 12 +++----
.../introduction-to-plugin-prefix-mapping.md | 2 +-
.../introduction/introduction-to-profiles.md | 40 +++++++++++-----------
.../introduction/introduction-to-the-lifecycle.md | 2 +-
.../guides/introduction/introduction-to-the-pom.md | 30 ++++++++--------
content/markdown/guides/mini/guide-assemblies.md | 2 +-
.../guides/mini/guide-configuring-plugins.md | 36 +++++++++----------
content/markdown/guides/mini/guide-encryption.md | 14 ++++----
.../markdown/guides/mini/guide-http-settings.md | 38 ++++++++++----------
.../guide-large-scale-centralized-deployments.md | 10 +++---
.../guides/mini/guide-maven-classloading.md | 18 +++++-----
.../markdown/guides/mini/guide-snippet-macro.md | 2 +-
.../markdown/guides/mini/guide-using-extensions.md | 6 ++--
content/markdown/issue-management.md | 2 +-
content/markdown/plugin-developers/common-bugs.md | 18 +++++-----
content/markdown/settings.md | 34 +++++++++---------
27 files changed, 176 insertions(+), 176 deletions(-)
diff --git a/content/markdown/developers/conventions/code.md b/content/markdown/developers/conventions/code.md
index b67457fd..0e2a3ec6 100644
--- a/content/markdown/developers/conventions/code.md
+++ b/content/markdown/developers/conventions/code.md
@@ -30,31 +30,31 @@ under the License.
Optionally you can still import the code style formatter for your IDE from [shared-resources](https://gitbox.apache.org/repos/asf?p=maven-shared-resources.git;a=tree;f=src/main/resources/config;hb=HEAD)
- - [Generic Code Style And Convention](#generic-code-style-and-convention)
+ - [Generic Code Style And Convention](Generic_Code_Style_And_Convention)
- - [Java](#java)
+ - [Java](Java)
- - [Java Code Style](#java-code-style)
+ - [Java Code Style](Java_Code_Style)
- - [Java Code Convention](#java-code-convention)
+ - [Java Code Convention](Java_Code_Convention)
- - [Java Code Convention - import layouts](#java-code-convention---import-layouts)
+ - [Java Code Convention - import layouts](Java_Code_Convention_-_import_layouts)
- - [JavaDoc Convention](#javadoc-convention)
+ - [JavaDoc Convention](JavaDoc_Convention)
- - [XML](#xml)
+ - [XML](XML)
- - [XML Code Style](#xml-code-style)
+ - [XML Code Style](XML_Code_Style)
- - [Generic XML Code Convention](#generic-xml-code-convention)
+ - [Generic XML Code Convention](Generic_XML_Code_Convention)
- - [POM Code Convention](#pom-code-convention)
+ - [POM Code Convention](POM_Code_Convention)
- - [XDOC Code Convention](#xdoc-code-convention)
+ - [XDOC Code Convention](XDOC_Code_Convention)
- - [FML Code Convention](#fml-code-convention)
+ - [FML Code Convention](FML_Code_Convention)
diff --git a/content/markdown/docs/3.5.3/release-notes.md b/content/markdown/docs/3.5.3/release-notes.md
index 45275985..acf8467a 100644
--- a/content/markdown/docs/3.5.3/release-notes.md
+++ b/content/markdown/docs/3.5.3/release-notes.md
@@ -131,7 +131,7 @@ So now some more interesting things about new (small) features:
- If you have used the deprecated version markers like `RELEASE` or `LATEST` this will now produce a WARNING during the build [MNG-6342][].
-## [The detailed issue list](#details)
+## [The detailed issue list](#Details)
Bugs:
diff --git a/content/markdown/docs/3.5.4/release-notes.md b/content/markdown/docs/3.5.4/release-notes.md
index 5b2fbf90..9900d13c 100644
--- a/content/markdown/docs/3.5.4/release-notes.md
+++ b/content/markdown/docs/3.5.4/release-notes.md
@@ -72,7 +72,7 @@ There are some additional minor improvements, the most notable of which is:
- The Maven Super POM changes the default execution of the `maven-source-plugin` `jar` goal into `jar-no-fork` which should resolve some issues complex projects had running releases.
-## [The detailed issue list](#details)
+## [The detailed issue list](#Details)
### Bugs
- [MNG-6370][] `ConcurrencyDependencyGraph#getNumberOfBuilds()` does not remove finished projects from unfinished ones
diff --git a/content/markdown/docs/3.6.0/release-notes.md b/content/markdown/docs/3.6.0/release-notes.md
index a9d034cd..7a2a746b 100644
--- a/content/markdown/docs/3.6.0/release-notes.md
+++ b/content/markdown/docs/3.6.0/release-notes.md
@@ -37,7 +37,7 @@ We hope you enjoy using Maven! If you have any questions, please consult:
We really value the contributions of these non committers, so this section is
focused on those individuals. Descriptions of the issues fixed can be found at
-the [end of these release notes](#details).
+the [end of these release notes](#Details).
Code Contributors of this release:
@@ -131,7 +131,7 @@ At the time of release, there are no known regressions introduced by this releas
- There was an issue related to the classpath ordering [MNG-6415] in Maven which
can cause issues which has been fixed.
-## [The detailed issue list](#details)
+## [The detailed issue list](#Details)
### Bugs:
diff --git a/content/markdown/docs/3.6.1/release-notes.md b/content/markdown/docs/3.6.1/release-notes.md
index 7d32def7..3d6217db 100644
--- a/content/markdown/docs/3.6.1/release-notes.md
+++ b/content/markdown/docs/3.6.1/release-notes.md
@@ -37,7 +37,7 @@ We hope you enjoy using Maven! If you have any questions, please consult:
We really value the contributions of these non committers, so this section is
focused on those individuals. Descriptions of the issues fixed can be found at
-the [end of these release notes](#details).
+the [end of these release notes](#Details).
Issue Reporters of this release:
@@ -191,7 +191,7 @@ Detailed explanations can be found in [Inheritance Assembly][inheritance-assembl
[inheritance-assembly]: https://maven.apache.org/ref/3.6.1/maven-model-builder/index.html#Inheritance_Assembly
-## The detailed issue list[](#details)
+## The detailed issue list[](#Details)
### Bugs:
diff --git a/content/markdown/docs/3.6.2/release-notes.md b/content/markdown/docs/3.6.2/release-notes.md
index 3a70e194..4b6e041c 100644
--- a/content/markdown/docs/3.6.2/release-notes.md
+++ b/content/markdown/docs/3.6.2/release-notes.md
@@ -37,7 +37,7 @@ If you have any questions, please consult:
We really value the contributions of these non committers, so this section is
focused on those individuals. Descriptions of the issues fixed can be found at
-the [end of these release notes](#details).
+the [end of these release notes](#Details).
Issue Reporters of this release: Benoit GUERIN, Christian Schulte, Elliotte Rusty Harold, Falko Modler, Francesco Chicchiriccò, Guillaume Nodet, guofei, Joseph Walton, Louis Mills, Mark Derricutt, Mark McKelvy, Mickael Istria, Nicolas Echegut, Nicolas Radde, Raphael Rösch, Ray Tsang, Robert Thornton, Rohan Padhye, Sergey Chernov, Stefan Oehme, Thibaud Lepretre, zhb.
@@ -58,7 +58,7 @@ Many thanks to all reporters and contributors for their time and support.
- The toolchain.xml file supports environment variables (see [MNG-6665](https://issues.apache.org/jira/browse/MNG-6665)).
-## The detailed issue list[](#details)
+## The detailed issue list[](#Details)
Sub-task
diff --git a/content/markdown/docs/3.6.3/release-notes.md b/content/markdown/docs/3.6.3/release-notes.md
index 9980fd54..b1b10d56 100644
--- a/content/markdown/docs/3.6.3/release-notes.md
+++ b/content/markdown/docs/3.6.3/release-notes.md
@@ -37,7 +37,7 @@ If you have any questions, please consult:
We really value the contributions of these non committers, so this section is
focused on those individuals. Descriptions of the issues fixed can be found at
-the [end of these release notes](#details).
+the [end of these release notes](#Details).
Issue Reporters of this release: Jonathan Chen, Charles Oliver Nutter, Lucas Ludueño, Stig Rohde Døssing, Vladimir Sitnikov
@@ -61,7 +61,7 @@ mvn -DbuildNumber=cecedd343002696d0abb50b32b541b8a6ba2883f package
If you're building on any Unix system, you'll need to add "`-Dline.separator=$'\r\n'`".
See the [Maven - Guide to Configuring for Reproducible Builds](/guides/mini/guide-reproducible-builds.html) for more details.
-## The detailed issue list[](#details)
+## The detailed issue list[](#Details)
Sub-task
diff --git a/content/markdown/docs/3.8.1/release-notes.md b/content/markdown/docs/3.8.1/release-notes.md
index b4045bef..31c5b4df 100644
--- a/content/markdown/docs/3.8.1/release-notes.md
+++ b/content/markdown/docs/3.8.1/release-notes.md
@@ -100,7 +100,7 @@ This release covers two CVEs:
- keep the dependency version but [define a mirror in your settings](/guides/mini/guide-mirror-settings.html).
-## The detailed issue list[](#details)
+## The detailed issue list[](#Details)
Bug
diff --git a/content/markdown/glossary.md b/content/markdown/glossary.md
index fcb73cab..6030e5ca 100644
--- a/content/markdown/glossary.md
+++ b/content/markdown/glossary.md
@@ -36,7 +36,7 @@ sometimes be confusing for newcomers.
- **Artifact**: An artifact is something that is either produced or
used by a project. Examples of artifacts produced by Maven for a
project include: JARs, source and binary distributions, WARs. Each
- artifact is identified by a `group id`, an
+ artifact is identified by a [group id](#GroupId), an
artifact ID, a version, an extension and a classifier
(extension+classifier may be named by a [type](/ref/current/maven-core/artifact-handlers.html)).
diff --git a/content/markdown/guides/development/guide-maven-development.md b/content/markdown/guides/development/guide-maven-development.md
index e9eb31b9..0411186b 100644
--- a/content/markdown/guides/development/guide-maven-development.md
+++ b/content/markdown/guides/development/guide-maven-development.md
@@ -85,7 +85,7 @@ under the License.
- - Make sure that you follow our code style, see [Further Links](#further-links).
+ - Make sure that you follow our code style, see [Further Links](Further_Links).
diff --git a/content/markdown/guides/getting-started/index.md b/content/markdown/guides/getting-started/index.md
index 3c472de6..443ed0e1 100644
--- a/content/markdown/guides/getting-started/index.md
+++ b/content/markdown/guides/getting-started/index.md
@@ -34,37 +34,37 @@ under the License.
- - [What is Maven?](./index.html#what-is-maven)
+ - [What is Maven?](./index.html#What_is_Maven)
- - [How can Maven benefit my development process?](./index.html#how-can-maven-benefit-my-development-process)
+ - [How can Maven benefit my development process?](./index.html#How_can_Maven_benefit_my_development_process)
- - [How do I setup Maven?](./index.html#how-do---setup-maven)
+ - [How do I setup Maven?](./index.html#How_do_I_setup_Maven)
- - [How do I make my first Maven project?](./index.html#how-do-i-make-my-first-maven-project)
+ - [How do I make my first Maven project?](./index.html#How_do_I_make_my_first_Maven_project)
- - [How do I compile my application sources?](./index.html#how-do-i-compile-my-application-sources)
+ - [How do I compile my application sources?](./index.html#How_do_I_compile_my_application_sources)
- - [How do I compile my test sources and run my unit tests?](./index.html#how-do-i-compile-my-test-sources-and-run-my-unit-tests)
+ - [How do I compile my test sources and run my unit tests?](./index.html#How_do_I_compile_my_test_sources_and_run_my_unit_tests)
- - [How do I create a JAR and install it in my local repository?](./index.html#how-do-i-create-a-jar-and-install-it-in-my-local-repository)
+ - [How do I create a JAR and install it in my local repository?](./index.html#How_do_I_create_a_JAR_and_install_it_in_my_local_repository)
- - [What is a SNAPSHOT version?](./index.html#what-is-a-snapshot-version)
+ - [What is a SNAPSHOT version?](./index.html#What_is_a_SNAPSHOT_version)
- - [How do I use plugins?](./index.html#how-do-i-use-plugins)
+ - [How do I use plugins?](./index.html#How_do_I_use_plugins)
- - [How do I add resources to my JAR?](./index.html#how-do-i-add-resources-to-my-jar)
+ - [How do I add resources to my JAR?](./index.html#How_do_I_add_resources_to_my_JAR)
- - [How do I filter resource files?](./index.html#how-do-i-filter-resource-files)
+ - [How do I filter resource files?](./index.html#How_do_I_filter_resource_files)
- - [How do I use external dependencies?](./index.html#how-do-i-use-external-dependencies)
+ - [How do I use external dependencies?](./index.html#How_do_I_use_external_dependencies)
- - [How do I deploy my jar in my remote repository?](./index.html#how-do-i-deploy-my-jar-in-my-remote-repository)
+ - [How do I deploy my jar in my remote repository?](./index.html#How_do_I_deploy_my_jar_in_my_remote_repository)
- - [How do I create documentation?](./index.html#how-do-i-create-documentation)
+ - [How do I create documentation?](./index.html#How_do_I_create_documentation)
- - [How do I build other types of projects?](./index.html#how-do-i-build-other-types-of-projects)
+ - [How do I build other types of projects?](./index.html#How_do_I_build_other_types_of_projects)
- - [How do I build more than one project at once?](./index.html#how-do-i-build-more-than-one-project-at-once)
+ - [How do I build more than one project at once?](./index.html#How_do_I_build_more_than_one_project_at_once)
### What is Maven?
@@ -179,7 +179,7 @@ mvn -B archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -Darch
- **artifactId** This element indicates the unique base name of the primary artifact being generated by this project. The primary artifact for a project is typically a JAR file. Secondary artifacts like source bundles also use the artifactId as part of their final name. A typical artifact produced by Maven would have the form `<artifactId>-<version>.<extension>` (for example, `myapp-1.0.jar`).
- - **version** This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the `SNAPSHOT` designator in a version, which indicates that a project is in a state of development. We will discuss the use of [snapshots](./index.html#what-is-a-snapshot-version) and how they work further on in this guide.
+ - **version** This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the `SNAPSHOT` designator in a version, which indicates that a project is in a state of development. We will discuss the use of [snapshots](./index.html#What_is_a_SNAPSHOT_version) and how they work further on in this guide.
- **name** This element indicates the display name used for the project. This is often used in Maven's generated documentation.
@@ -878,7 +878,7 @@ mvn process-resources "-Dcommand.line.prop=hello again"
For more information about the dependency mechanism as a whole, see [Introduction to Dependency Mechanism](../introduction/introduction-to-dependency-mechanism.html).
- With this information about a dependency, Maven will be able to reference the dependency when it builds the project. Where does Maven reference the dependency from? Maven looks in your local repository (`${user.home}/.m2/repository` is the default location) to find all dependencies. In a [previous section](#how-do-i-create-a-jar-and-install-it-in-my-local-repository), we installed the artifact from our project (my-app-1.0-SNAPSHOT.jar) into the local repository. Once it's installed ther [...]
+ With this information about a dependency, Maven will be able to reference the dependency when it builds the project. Where does Maven reference the dependency from? Maven looks in your local repository (`${user.home}/.m2/repository` is the default location) to find all dependencies. In a [previous section](How_do_I_create_a_JAR_and_install_it_in_my_local_repository), we installed the artifact from our project (my-app-1.0-SNAPSHOT.jar) into the local repository. Once it's installed there [...]
diff --git a/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md b/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
index ff43f3ab..459a8d98 100644
--- a/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
+++ b/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
@@ -30,23 +30,23 @@ under the License.
- - [Transitive Dependencies](#transitive-dependencies)
+ - [Transitive Dependencies](Transitive_Dependencies)
- Excluded/Optional Dependencies
- - [Dependency Scope](#dependency-scope)
+ - [Dependency Scope](Dependency_Scope)
- - [Dependency Management](#dependency-management)
+ - [Dependency Management](Dependency_Management)
- - [Importing Dependencies](#importing-dependencies)
+ - [Importing Dependencies](Importing_Dependencies)
- - [Bill of Materials (BOM) POMs](#bill-of-materials-bom-poms)
+ - [Bill of Materials (BOM) POMs](bill-of-materials-bom-poms)
- - [System Dependencies](#system-dependencies)
+ - [System Dependencies](System_Dependencies)
### Transitive Dependencies
diff --git a/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md b/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
index 9f144e42..da041f44 100644
--- a/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
+++ b/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
@@ -39,7 +39,7 @@ under the License.
- - `maven-${prefix}-plugin` - for official plugins maintained by the Apache Maven team itself (you **must not** use this naming pattern for your plugin, see [this note for more informations](../plugin/guide-java-plugin-development.html#plugin-naming-convention-and-apache-maven-trademark))
+ - `maven-${prefix}-plugin` - for official plugins maintained by the Apache Maven team itself (you **must not** use this naming pattern for your plugin, see [this note for more informations](../plugin/guide-java-plugin-development.html#Plugin_Naming_Convention_and_Apache_Maven_Trademark))
- `${prefix}-maven-plugin` - for plugins from other sources
diff --git a/content/markdown/guides/introduction/introduction-to-profiles.md b/content/markdown/guides/introduction/introduction-to-profiles.md
index 9b7caf2d..920c4327 100644
--- a/content/markdown/guides/introduction/introduction-to-profiles.md
+++ b/content/markdown/guides/introduction/introduction-to-profiles.md
@@ -25,55 +25,55 @@ under the License.
- - [What are the different types of profile? Where is each defined?](#what-are-the-different-types-of-profile-where-is-each-defined)
+ - [What are the different types of profile? Where is each defined?](What_are_the_different_types_of_profile.3F_Where_is_each_defined.3F)
- - [How can a profile be triggered? How does this vary according to the type of profile being used?](#how-can-a-profile-be-triggered-how-does-this-vary-according-to-the-type-of-profile-being-used)
+ - [How can a profile be triggered? How does this vary according to the type of profile being used?](How_can_a_profile_be_triggered.3F_How_does_this_vary_according_to_the_type_of_profile_being_used.3F)
- - [Details on profile activation](#details-on-profile-activation)
+ - [Details on profile activation](Details_on_profile_activation)
- - [Explicit profile activation](#explicit-profile-activation)
+ - [Explicit profile activation](Explicit_profile_activation)
- - [Implicit profile activation](#implici-profile-activation)
+ - [Implicit profile activation](Implicit_profile_activation)
- - [JDK](#jdk)
+ - [JDK](JDK)
- - [OS](#os)
+ - [OS](OS)
- - [Property](#property)
+ - [Property](Property)
- - [Files](#files)
+ - [Files](Files)
- - [Deactivating a profile](#deactivating-a-profile)
+ - [Deactivating a profile](Deactivating_a_profile)
- - [Which areas of a POM can be customized by each type of profile? Why?](#which-areas-of-a-pom-can-be-customized-by-each-type-of-profile-why)
+ - [Which areas of a POM can be customized by each type of profile? Why?](Which_areas_of_a_POM_can_be_customized_by_each_type_of_profile.3F_Why.3F)
- - [Profiles in external files](#profiles-in-external-files)
+ - [Profiles in external files](Profiles_in_external_files)
- - [Profiles in POMs](#profiles-in-poms)
+ - [Profiles in POMs](Profiles_in_POMs)
- - [POM elements outside `<profiles>`](#pom-elements-outside-profiles)
+ - [POM elements outside `<profiles>`](POM_elements_outside_.3Cprofiles.3E)
- - [Profile Order](#profile-order)
+ - [Profile Order](Profile_Order)
- - [Profile Pitfalls](#profile-pitfalls)
+ - [Profile Pitfalls](Profile_Pitfalls)
- - [External Properties](#external-properties)
+ - [External Properties](External_Properties)
- - [Incomplete Specification of a Natural Profile Set](#incomplete-specification-of-a-natural-profile-set)
+ - [Incomplete Specification of a Natural Profile Set](Incomplete_Specification_of_a_Natural_Profile_Set)
- - [How can I tell which profiles are in effect during a build?](#how-can-i-tell-which-profiles-are-in-effect-during-a-build)
+ - [How can I tell which profiles are in effect during a build?](How_can_I_tell_which_profiles_are_in_effect_during_a_build.3F)
- - [Naming Conventions](#naming-conventions)
+ - [Naming Conventions](Naming_Conventions)
Apache Maven goes to great lengths to ensure that builds are portable. Among other things, this means allowing build configuration inside the POM, avoiding **all** filesystem references (in inheritance, dependencies, and other places), and leaning much more heavily on the local repository to store the metadata needed to make this possible.
diff --git a/content/markdown/guides/introduction/introduction-to-the-lifecycle.md b/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
index 8d2dbbf7..17bb85b0 100644
--- a/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
+++ b/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
@@ -36,7 +36,7 @@ under the License.
- [Plugins](#plugins)
- - [Lifecycle Reference](#lifecycle-reference)
+ - [Lifecycle Reference](Lifecycle_Reference)
- [Built-in Lifecycle Bindings](#built-in-lifecycle-bindings)
diff --git a/content/markdown/guides/introduction/introduction-to-the-pom.md b/content/markdown/guides/introduction/introduction-to-the-pom.md
index 9f6b3909..4554ee0d 100644
--- a/content/markdown/guides/introduction/introduction-to-the-pom.md
+++ b/content/markdown/guides/introduction/introduction-to-the-pom.md
@@ -27,37 +27,37 @@ under the License.
- - [What is a POM](./introduction-to-the-pom.html#what-is-a-pom)?
+ - [What is a POM](./introduction-to-the-pom.html#What_is_a_POM)?
- - [Super POM](./introduction-to-the-pom.html#super-pom)
+ - [Super POM](./introduction-to-the-pom.html#Super_POM)
- - [Minimal POM](./introduction-to-the-pom.html#minimal-pom)
+ - [Minimal POM](./introduction-to-the-pom.html#Minimal_POM)
- - [Project Inheritance](./introduction-to-the-pom.html#project-inheritance)
+ - [Project Inheritance](./introduction-to-the-pom.html#Project_Inheritance)
- - [Example 1](./introduction-to-the-pom.html#example-1)
+ - [Example 1](./introduction-to-the-pom.html#Example_1)
- - [Example 2](./introduction-to-the-pom.html#example-2)
+ - [Example 2](./introduction-to-the-pom.html#Example_2)
- - [Project Aggregation](./introduction-to-the-pom.html#project-aggregation)
+ - [Project Aggregation](./introduction-to-the-pom.html#Project_Aggregation)
- - [Example 3](./introduction-to-the-pom.html#example-3)
+ - [Example 3](./introduction-to-the-pom.html#Example_3)
- - [Example 4](./introduction-to-the-pom.html#example-4)
+ - [Example 4](./introduction-to-the-pom.html#Example_4)
- - [Project Inheritance vs Project Aggregation](./introduction-to-the-pom.html#project-inheritance-vs-project-aggregation)
+ - [Project Inheritance vs Project Aggregation](./introduction-to-the-pom.html#Project_Inheritance_vs_Project_Aggregation)
- - [Example 5](./introduction-to-the-pom.html#example-5)
+ - [Example 5](./introduction-to-the-pom.html#Example_5)
- - [Project Interpolation and Variables](./introduction-to-the-pom.html#project-nterpolation)
+ - [Project Interpolation and Variables](./introduction-to-the-pom.html#Project_Interpolation)
- - [Available Variables](./introduction-to-the-pom.html#available-variables)
+ - [Available Variables](./introduction-to-the-pom.html#Available_Variables)
@@ -123,7 +123,7 @@ under the License.
A POM requires that its groupId, artifactId, and version be configured. These three values form the project's fully qualified artifact name. This is in the form of `<groupId>:<artifactId>:<version>`. As for the example above, its fully qualified artifact name is "com.mycompany.app:my-app:1".
- Also, as mentioned in the [first section](#hat-is-a-pom), if the configuration details are not specified, Maven will use their defaults. One of these default values is the packaging type. Every Maven project has a packaging type. If it is not specified in the POM, then the default value "jar" would be used.
+ Also, as mentioned in the [first section](What_is_a_POM), if the configuration details are not specified, Maven will use their defaults. One of these default values is the packaging type. Every Maven project has a packaging type. If it is not specified in the POM, then the default value "jar" would be used.
Furthermore, you can see that in the minimal POM the _repositories_ were not specified. If you build your project using the minimal POM, it would inherit the _repositories_ configuration in the Super POM. Therefore when Maven sees the dependencies in the minimal POM, it would know that these dependencies will be downloaded from `https://repo.maven.apache.org/maven2` which was specified in the Super POM.
@@ -299,7 +299,7 @@ under the License.
### Project Aggregation
- Project Aggregation is similar to [Project Inheritance](#project-inheritance). But instead of specifying the parent POM from the module, it specifies the modules from the parent POM. By doing so, the parent project now knows its modules, and if a Maven command is invoked against the parent project, that Maven command will then be executed to the parent's modules as well. To do Project Aggregation, you must do the following:
+ Project Aggregation is similar to [Project Inheritance](Project_Inheritance). But instead of specifying the parent POM from the module, it specifies the modules from the parent POM. By doing so, the parent project now knows its modules, and if a Maven command is invoked against the parent project, that Maven command will then be executed to the parent's modules as well. To do Project Aggregation, you must do the following:
diff --git a/content/markdown/guides/mini/guide-assemblies.md b/content/markdown/guides/mini/guide-assemblies.md
index d9e824f5..edc291f4 100644
--- a/content/markdown/guides/mini/guide-assemblies.md
+++ b/content/markdown/guides/mini/guide-assemblies.md
@@ -113,7 +113,7 @@ under the License.
You can use a manually defined assembly descriptor as mentioned before but it is simpler to use the [pre-defined assembly descriptor bin](/plugins/maven-assembly-plugin/descriptor-refs.html#bin) in such cases.
- How to use such pre-defined assembly descriptors is described in the [documentation of maven-assembly-plugin](/plugins/maven-assembly-plugin/usage.html#configuration).
+ How to use such pre-defined assembly descriptors is described in the [documentation of maven-assembly-plugin](/plugins/maven-assembly-plugin/usage.html#Configuration).
diff --git a/content/markdown/guides/mini/guide-configuring-plugins.md b/content/markdown/guides/mini/guide-configuring-plugins.md
index 10dd07cb..e4725dba 100644
--- a/content/markdown/guides/mini/guide-configuring-plugins.md
+++ b/content/markdown/guides/mini/guide-configuring-plugins.md
@@ -25,25 +25,25 @@ under the License.
- - [Introduction](#introduction)
+ - [Introduction](Introduction)
- - [Generic Configuration](#generic-configuration)
+ - [Generic Configuration](Generic_Configuration)
- - [Help Goal](#help-goal)
+ - [Help Goal](Help_Goal)
- - [Configuring Parameters](#configuring-parameters)
+ - [Configuring Parameters](Configuring_Parameters)
- - [Mapping Value Objects](#mapping-value-objects)
+ - [Mapping Value Objects](Mapping_Value_Objects)
- - [Mapping Complex Objects](#mapping-complex-objects)
+ - [Mapping Complex Objects](Mapping_Complex_Objects)
- - [Mapping Collection Types](#mapping-collection-types)
+ - [Mapping Collection Types](Mapping_Collection_Types)
- - [Mapping Collections and Arrays](#mapping-collections-and-arrays)
+ - [Mapping Collections and Arrays](Mapping_Collections_and_Arrays)
- - [Mapping Maps](#mapping-maps)
+ - [Mapping Maps](Mapping_Maps)
- - [Mapping Properties](#mapping-properties)
+ - [Mapping Properties](Mapping_Properties)
@@ -51,23 +51,23 @@ under the License.
- - [Configuring Build Plugins](#configuring-build-plugins)
+ - [Configuring Build Plugins](Configuring_Build_Plugins)
- - [Using the `<executions>` Tag](#using-the-executions-tag)
+ - [Using the `<executions>` Tag](Using_the_.3Cexecutions.3E_Tag)
- - [Using the `<dependencies>` Tag](#using-the-dependencies-tag)
+ - [Using the `<dependencies>` Tag](Using_the_.3Cdependencies.3E_Tag)
- - [Using the `<inherited>` Tag In Build Plugins](#using-the-inherited-tag-in-build-plugins)
+ - [Using the `<inherited>` Tag In Build Plugins](Using_the_.3Cinherited.3E_Tag_In_Build_Plugins)
- - [Configuring Reporting Plugins](#configuring-reporting-plugins)
+ - [Configuring Reporting Plugins](Configuring_Reporting_Plugins)
- - [Using the `<reporting>` Tag VS `<build>` Tag](#using-the-reporting-tag-vs-build-tag)
+ - [Using the `<reporting>` Tag VS `<build>` Tag](Using_the_.3Creporting.3E_Tag_VS_.3Cbuild.3E_Tag)
- - [Using the `<reportSets>` Tag](#using-the-reportsets-tag)
+ - [Using the `<reportSets>` Tag](Using_the_.3CreportSets.3E_Tag)
- - [Using the `<inherited>` Tag In Reporting Plugins](#using-the-inherited-tag-in-reporting-plugins)
+ - [Using the `<inherited>` Tag In Reporting Plugins](Using_the_.3Cinherited.3E_Tag_In_Reporting_Plugins)
diff --git a/content/markdown/guides/mini/guide-encryption.md b/content/markdown/guides/mini/guide-encryption.md
index b179a386..9046c2d6 100644
--- a/content/markdown/guides/mini/guide-encryption.md
+++ b/content/markdown/guides/mini/guide-encryption.md
@@ -25,15 +25,15 @@ under the License.
- 1 [Introduction](#introduction)
+ 1 [Introduction](Introduction)
- 1 [How to create a master password](#how-to-create-a-master-password)
+ 1 [How to create a master password](How_to_create_a_master_password)
- 1 [How to encrypt server passwords](#how-to-encrypt-server-passwords)
+ 1 [How to encrypt server passwords](How_to_encrypt_server_passwords)
- 1 [How to keep the master password on removable drive](#how-to-keep-the-master-password-on-removable-drive)
+ 1 [How to keep the master password on removable drive](How_to_keep_the_master_password_on_removable_drive)
- 1 [Tips](#tips)
+ 1 [Tips](Tips)
### Introduction
@@ -87,7 +87,7 @@ under the License.
mvn --encrypt-master-password <password>
```
- _Note:_ Since Maven 3.2.1 the password argument should no longer be used (see [Tips](#tips) below for more information). Maven will prompt for the password. Earlier versions of Maven will not prompt for a password, so it must be typed on the command-line in plaintext.
+ _Note:_ Since Maven 3.2.1 the password argument should no longer be used (see [Tips](Tips) below for more information). Maven will prompt for the password. Earlier versions of Maven will not prompt for a password, so it must be typed on the command-line in plaintext.
This command will produce an encrypted version of the password, something like
@@ -123,7 +123,7 @@ mvn --encrypt-master-password <password>
mvn --encrypt-password <password>
```
- _Note:_Just like `--encrypt-master-password` the password argument should no longer be used since Maven 3.2.1 (see [Tips below for more information.](#tips)).
+ _Note:_Just like `--encrypt-master-password` the password argument should no longer be used since Maven 3.2.1 (see [Tips below for more information.](Tips)).
This command produces an encrypted version of it, something like
diff --git a/content/markdown/guides/mini/guide-http-settings.md b/content/markdown/guides/mini/guide-http-settings.md
index 7f3d85fc..b786b1b9 100644
--- a/content/markdown/guides/mini/guide-http-settings.md
+++ b/content/markdown/guides/mini/guide-http-settings.md
@@ -25,49 +25,49 @@ under the License.
- - [Advanced Configuration of the Maven Resolver Transport](#advanced-configuration-of-the-maven-resolver-transport)
+ - [Advanced Configuration of the Maven Resolver Transport](Advanced_Configuration_of_the_Maven_Resolver_Transport)
- - [Advanced configuration to Transports](#advanced-configuration-to-transports)
+ - [Advanced configuration to Transports](Advanced_configuration_to_Transports)
- - [HTTP Headers](#http-headers)
+ - [HTTP Headers](HTTP_Headers)
- - [Connection Timeouts](#connection-timeouts)
+ - [Connection Timeouts](Connection_Timeouts)
- - [Advanced Configuration of the HttpClient HTTP Wagon](#advanced-configuration-of-the-httpclient-http-wagon)
+ - [Advanced Configuration of the HttpClient HTTP Wagon](Advanced_Configuration_of_the_HttpClient_HTTP_Wagon)
- - [Introduction](#introduction)
+ - [Introduction](Introduction)
- - [The Basics](#the-basics)
+ - [The Basics](The_Basics)
- - [Configuring GET, HEAD, PUT, or All of the Above](#configuring-get-head-put-or-all-of-the-above)
+ - [Configuring GET, HEAD, PUT, or All of the Above](Configuring_GET.2C_HEAD.2C_PUT.2C_or_All_of_the_Above)
- - [Taking Control of Your HTTP Headers](#taking-control-of-your-http-headers)
+ - [Taking Control of Your HTTP Headers](Taking_Control_of_Your_HTTP_Headers)
- - [Fine-Tuning HttpClient Parameters](#fine-tuning-httpclient-parameters)
+ - [Fine-Tuning HttpClient Parameters](Fine-Tuning_HttpClient_Parameters)
- - [Non-String Parameter Values](#non-string-parameter-values)
+ - [Non-String Parameter Values](Non-String_Parameter_Values)
- - [Example: Using Preemptive Authentication](#example--using-preemptive-authentication)
+ - [Example: Using Preemptive Authentication](Example:_Using_Preemptive_Authentication)
- - [Example: Lifting auth scope restriction for external authentication systems](#example--lifting-auth-scope-restriction-for-external-authentication-systems)
+ - [Example: Lifting auth scope restriction for external authentication systems](Example:_Lifting_auth_scope_restriction_for_external_authentication_systems)
- - [Ignoring Cookies](#ignoring-cookies)
+ - [Ignoring Cookies](Ignoring_Cookies)
- - [Support for General-Wagon Configuration Standards](#support-for-general-wagon-configuration-standards)
+ - [Support for General-Wagon Configuration Standards](Support_for_General-Wagon_Configuration_Standards)
- - [HTTP Headers](#http-headers-1)
+ - [HTTP Headers](HTTP_Headers_1)
- - [Connection Timeouts](#connection-timeouts-1)
+ - [Connection Timeouts](Connection_Timeouts_1)
- - [Read time out](#read-time-out)
+ - [Read time out](Read_time_out)
- - [Resources](#resources)
+ - [Resources](Resources)
diff --git a/content/markdown/guides/mini/guide-large-scale-centralized-deployments.md b/content/markdown/guides/mini/guide-large-scale-centralized-deployments.md
index 1c52b63a..235d162c 100644
--- a/content/markdown/guides/mini/guide-large-scale-centralized-deployments.md
+++ b/content/markdown/guides/mini/guide-large-scale-centralized-deployments.md
@@ -68,7 +68,7 @@ under the License.
- a hosted repository for snapshots
- - a hosted repository that can contain both releases and snapshots (Only needed if some projects are still using Maven Deploy Plugin < 2.8. See [Managing Uploads to the Repository Manager](#managing-uploads-to-the-repository-manager) for more info.)
+ - a hosted repository that can contain both releases and snapshots (Only needed if some projects are still using Maven Deploy Plugin < 2.8. See [Managing Uploads to the Repository Manager](Managing_Uploads_to_the_Repository_Manager) for more info.)
Separate hosted repositories are generally used for releases and snapshots due to the need for different artifact retention policies.
@@ -78,9 +78,9 @@ under the License.
- - [Download](#managing-downloads-from-the-repository-manager) artifacts from the virtual repository.
+ - [Download](Managing_Downloads_from_the_Repository_Manager) artifacts from the virtual repository.
- - [Upload](#managing-uploads-to-the-repository-manager) artifacts to one of the hosted repositories.
+ - [Upload](Managing_Uploads_to_the_Repository_Manager) artifacts to one of the hosted repositories.
@@ -228,10 +228,10 @@ under the License.
- on developer machines
- Both locations should have the mirror settings mentioned in [Managing Downloads from the Repository Manager](#managing-downloads-from-the-repository-manager).
+ Both locations should have the mirror settings mentioned in [Managing Downloads from the Repository Manager](Managing_Downloads_from_the_Repository_Manager).
- Typically, only continuous integration servers should have the deployment repository settings mentioned in [Managing Uploads to the Repository Manager](#managing-uploads-to-the-repository-manager), because only continuous integration servers should be allowed to upload to the repository manager. Alternatively, if you want developers to be able to upload artifacts to the repository manager, then include the deployment repository properties in the `settings.xml` files used by developers.
+ Typically, only continuous integration servers should have the deployment repository settings mentioned in [Managing Uploads to the Repository Manager](Managing_Uploads_to_the_Repository_Manager), because only continuous integration servers should be allowed to upload to the repository manager. Alternatively, if you want developers to be able to upload artifacts to the repository manager, then include the deployment repository properties in the `settings.xml` files used by developers.
How the `settings.xml` files are stored and updated is beyond the scope of this document. The general recommendation is to manage a few `settings.xml` files centrally, and then use automation to distribute them to continuous integration servers and developer machines.
diff --git a/content/markdown/guides/mini/guide-maven-classloading.md b/content/markdown/guides/mini/guide-maven-classloading.md
index 7d691edc..e4d7cd0a 100644
--- a/content/markdown/guides/mini/guide-maven-classloading.md
+++ b/content/markdown/guides/mini/guide-maven-classloading.md
@@ -27,23 +27,23 @@ under the License.
- - [Overview](#overview)
+ - [Overview](Overview)
- - [Platform Classloader](#platform-classloader)
+ - [Platform Classloader](Platform_Classloader)
- - [System Classloader](#system-classloader)
+ - [System Classloader](System_Classloader)
- - [Core Classloader](#core-classloader)
+ - [Core Classloader](Core_Classloader)
- - [API Classloader](#api-classloader)
+ - [API Classloader](API_Classloader)
- - [Build Extension Classloaders](#build-extension-classloaders)
+ - [Build Extension Classloaders](Build_Extension_Classloaders)
- - [Project Classloaders](#project-classloaders)
+ - [Project Classloaders](Project_Classloaders)
- - [Plugin Classloaders](#platform-classloader)
+ - [Plugin Classloaders](Plugin_Classloaders)
- - [Custom Classloaders](#custom-classloaders)
+ - [Custom Classloaders](Custom_Classloaders)
### Overview
diff --git a/content/markdown/guides/mini/guide-snippet-macro.md b/content/markdown/guides/mini/guide-snippet-macro.md
index b6616007..17d8297a 100644
--- a/content/markdown/guides/mini/guide-snippet-macro.md
+++ b/content/markdown/guides/mini/guide-snippet-macro.md
@@ -39,7 +39,7 @@ under the License.
Following are examples of snippets in various source documents, as well as the corresponding macros in the APT documentation format.
- See the Doxia [Macros Guide](/doxia/macros/index.html#snippet-macro) for more information and examples.
+ See the Doxia [Macros Guide](/doxia/macros/index.html#Snippet_Macro) for more information and examples.
### Snippets in Sources
diff --git a/content/markdown/guides/mini/guide-using-extensions.md b/content/markdown/guides/mini/guide-using-extensions.md
index 8e499426..cacfd532 100644
--- a/content/markdown/guides/mini/guide-using-extensions.md
+++ b/content/markdown/guides/mini/guide-using-extensions.md
@@ -23,7 +23,7 @@ under the License.
## Using Extensions
- Extensions are a way to add classes to either the [Core Classloader](./guide-maven-classloading.html#core-classloader) (Core Extensions) or the [Project Classloader](./guide-maven-classloading.html#Project_Classloaders) (Build Extensions). This is necessary for adjusting Maven in a way that affects more than just one plug-in.
+ Extensions are a way to add classes to either the [Core Classloader](./guide-maven-classloading.html#Core_Classloader) (Core Extensions) or the [Project Classloader](./guide-maven-classloading.html#Project_Classloaders) (Build Extensions). This is necessary for adjusting Maven in a way that affects more than just one plug-in.
The mechanism allows extensions to either replace default [Sisu components](https://www.eclipse.org/sisu/) with custom ones or add new components which are used at run time. In addition one could also expose additional packages from the Core Classloader.
@@ -54,7 +54,7 @@ under the License.
- - Registered via [`project-\>build-\>plugins-\>plugin`](../../pom.html#plugins) with element `extensions` being set to `true`. This is useful for regular plug-ins carrying some extensions.
+ - Registered via [`project-\>build-\>plugins-\>plugin`](../../pom.html#Plugins) with element `extensions` being set to `true`. This is useful for regular plug-ins carrying some extensions.
Example:
@@ -82,7 +82,7 @@ under the License.
```
- - Registered as build extension in [`project-\>build-\>extensions-\>extension`](../../pom.html#extensions)
+ - Registered as build extension in [`project-\>build-\>extensions-\>extension`](../../pom.html#Extensions)
Example:
diff --git a/content/markdown/issue-management.md b/content/markdown/issue-management.md
index 4b63265a..b804a819 100644
--- a/content/markdown/issue-management.md
+++ b/content/markdown/issue-management.md
@@ -22,7 +22,7 @@ Maven projects use [Jira](https://www.atlassian.com/software/jira) as issue trac
## Issue Management
-Maven is composed of nearly [100 parts](/scm.html#maven-sources-overview), each one having its own Jira project or component:
+Maven is composed of nearly [100 parts](/scm.html#Maven_Sources_Overview), each one having its own Jira project or component:
**see the [Maven Jira issues overview](https://cwiki.apache.org/confluence/display/MAVEN/Maven+JIRA+issues+overview) to get a summary of open issues**.
Issues, bugs, and feature requests should be submitted to the following
diff --git a/content/markdown/plugin-developers/common-bugs.md b/content/markdown/plugin-developers/common-bugs.md
index 7b5e64d4..63fb6a7b 100644
--- a/content/markdown/plugin-developers/common-bugs.md
+++ b/content/markdown/plugin-developers/common-bugs.md
@@ -28,23 +28,23 @@ under the License.
- - [Reading and Writing Text Files](#reading-and-writing-text-files)
+ - [Reading and Writing Text Files](Reading_and_Writing_Text_Files)
- - [Converting between URLs and Filesystem Paths](#converting-between-urls-and-filesystem-paths)
+ - [Converting between URLs and Filesystem Paths](Converting_between_URLs_and_Filesystem_Paths)
- - [Handling Strings Case-insensitively](#handling-strings-case-insensitively)
+ - [Handling Strings Case-insensitively](Handling_Strings_Case-insensitively)
- - [Creating Resource Bundle Families](#creating-resource-bundle-families)
+ - [Creating Resource Bundle Families](Creating_Resource_Bundle_Families)
- - [Using System Properties](#using-system-properties)
+ - [Using System Properties](Using_System_Properties)
- - [Using Shutdown Hooks](#using-shutdown-hooks)
+ - [Using Shutdown Hooks](Using_Shutdown_Hooks)
- - [Resolving Relative Paths](#resolving-relative-paths)
+ - [Resolving Relative Paths](Resolving_Relative_Paths)
- - [Determining the Output Directory for a Site Report](#determining-the-output-directory-for-a-site-report)
+ - [Determining the Output Directory for a Site Report](Determining_the_Output_Directory_for_a_Site_Report)
- - [Retrieving the Mojo Logger](#retrieving-the-mojo-logger)
+ - [Retrieving the Mojo Logger](Retrieving_the_Mojo_Logger)
### Reading and Writing Text Files
diff --git a/content/markdown/settings.md b/content/markdown/settings.md
index 9443ac47..1ff140e9 100644
--- a/content/markdown/settings.md
+++ b/content/markdown/settings.md
@@ -17,23 +17,23 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
-1. [Introduction](#introduction)
- 1. [Quick Overview](#quick-overview)
+1. [Introduction](#Introduction)
+ 1. [Quick Overview](#Quick_Overview)
-2. [Settings Details](#dettings-details)
- 1. [Simple Values](#simple-values)
- 2. [Plugin Groups](#plugin-groups)
- 3. [Servers](#servers)
- 1. [Password Encryption](#password-encryption)
+2. [Settings Details](#Settings_Details)
+ 1. [Simple Values](#Simple_Values)
+ 2. [Plugin Groups](#Plugin_Groups)
+ 3. [Servers](#Servers)
+ 1. [Password Encryption](#Password_Encryption)
- 4. [Mirrors](#mirrors)
- 5. [Proxies](#proxies)
- 6. [Profiles](#profiles)
- 1. [Activation](#activation)
- 2. [Repositories](#repositories)
- 3. [Plugin Repositories](#plugin-repositories)
+ 4. [Mirrors](#Mirrors)
+ 5. [Proxies](#Proxies)
+ 6. [Profiles](#Profiles)
+ 1. [Activation](#Activation)
+ 2. [Repositories](#Repositories)
+ 3. [Plugin Repositories](#Plugin_Repositories)
- 7. [Active Profiles](#active-profiles)
+ 7. [Active Profiles](#Active_Profiles)
## Introduction
@@ -95,7 +95,7 @@ cannot be used for interpolation.
Half of the top-level `settings` elements are simple values,
representing a range of values which describe elements of the build
system that are active full-time.
-```xml
+
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
<localRepository>${user.home}/.m2/repository</localRepository>
@@ -103,7 +103,7 @@ system that are active full-time.
<offline>false</offline>
...
</settings>
-```
+
- **localRepository**: This value is the path of this build system's
local repository. The default value is
`${user.home}/.m2/repository`. This element is especially useful for
@@ -214,7 +214,7 @@ page](./guides/mini/guide-encryption.html)
- **id**, **name**: The unique identifier and user-friendly name of
this mirror. The `id` is used to differentiate between `mirror`
elements and to pick the corresponding credentials from the
- [`<servers>`](#servers) section when connecting to the mirror.
+ [`<servers>`](#Servers) section when connecting to the mirror.
- **url**: The base URL of this mirror. The build system will use this
URL to connect to a repository rather than the original repository
URL.
[maven-site] 10/14: Revert "use directory, not folder"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit 03e99ad1fff2601a1a4cab06c1396867e3485e15
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:34:13 2023 +0100
Revert "use directory, not folder"
This reverts commit ec74b081fc8c183782154adc8332f48e32a6fee1.
---
.../website/deploy-component-reference-documentation.md | 2 +-
content/markdown/docs/3.3.1/release-notes.md | 8 ++++----
content/markdown/docs/3.3.9/release-notes.md | 4 ++--
content/markdown/faq-unoffical.md | 8 ++++----
content/markdown/guides/mini/guide-3rd-party-jars-local.md | 2 +-
content/markdown/guides/mini/guide-encryption.md | 2 +-
content/markdown/guides/mini/guide-releasing.md | 2 +-
content/markdown/install.md.vm | 2 +-
content/markdown/maven-jsr330.md | 2 +-
content/markdown/plugin-developers/common-bugs.md | 2 +-
content/markdown/plugins/index.md | 4 ++--
content/markdown/plugins/localization.md | 2 +-
content/markdown/security-plexus-archiver.md | 2 +-
content/markdown/security.md | 2 +-
14 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/content/markdown/developers/website/deploy-component-reference-documentation.md b/content/markdown/developers/website/deploy-component-reference-documentation.md
index 976a785c..91c20a34 100644
--- a/content/markdown/developers/website/deploy-component-reference-documentation.md
+++ b/content/markdown/developers/website/deploy-component-reference-documentation.md
@@ -63,7 +63,7 @@ under the License.
1 prerequisite: eventually build the component if it has not been done previously, or some reports may miss build or integration information:
- Notice: In cases where you have prepared a release you can simple change into `target/checkout` directory and continue with 2.
+ Notice: In cases where you have prepared a release you can simple change into `target/checkout` folder and continue with 2.
diff --git a/content/markdown/docs/3.3.1/release-notes.md b/content/markdown/docs/3.3.1/release-notes.md
index 69950e46..e777a8d7 100644
--- a/content/markdown/docs/3.3.1/release-notes.md
+++ b/content/markdown/docs/3.3.1/release-notes.md
@@ -58,7 +58,7 @@ The new [Maven 3.3.1 Release is just out](http://mail-archives.apache.org/mod_mb
* The handling of the [`toolchains.xml`][MNG-3891] file has been adjusted with the
handling of `settings.xml` which means it will be searched within the
- `${maven.home}/conf/` directory and furthermore within the `${user.home}/.m2/` directory.
+ `${maven.home}/conf/` folder and furthermore within the `${user.home}/.m2/` folder.
* For a better understanding and as an example of the `toolchains.xml` file has been added
to the [Maven distribution][MNG-5745].
@@ -75,7 +75,7 @@ The new [Maven 3.3.1 Release is just out](http://mail-archives.apache.org/mod_mb
it simpler to use.
* The old way (up to Maven 3.2.5) was to create a jar (must be shaded if you have other dependencies)
- which contains the extension and put it manually into the `${MAVEN_HOME}/lib/ext` directory.
+ which contains the extension and put it manually into the `${MAVEN_HOME}/lib/ext` folder.
This means you had to change the Maven installation. The consequence was that everyone who likes
to use this needed to change it's installation and makes the on-boarding for a developer much
more inconvenient. The other option was to give the path to the jar on command line via
@@ -124,8 +124,8 @@ The new [Maven 3.3.1 Release is just out](http://mail-archives.apache.org/mod_mb
--fail-at-end`. So you only have to call maven just by using `mvn clean
package` instead of `mvn -T3 -U --fail-at-end clean package` and not to miss
the `-T3 -U --fail-at-end` options. The `${maven.projectBasedir}/.mvn/maven.config`
- is located in the `${maven.projectBasedir}/.mvn/` directory which is in the root
- of a multi module build. This directory is part of the project and will be checked
+ is located in the `${maven.projectBasedir}/.mvn/` folder which is in the root
+ of a multi module build. This folder is part of the project and will be checked
in into your version control. This results in being picked by everybody who
checks out the project and no need to remember to call this project
via `mvn -T3 -U --fail-at-end clean package` instead of `mvn clean package`.
diff --git a/content/markdown/docs/3.3.9/release-notes.md b/content/markdown/docs/3.3.9/release-notes.md
index d38486bd..1d73af31 100644
--- a/content/markdown/docs/3.3.9/release-notes.md
+++ b/content/markdown/docs/3.3.9/release-notes.md
@@ -123,7 +123,7 @@ Bugs
`MAVEN_OPTS` and debugging options which has been fixed by [MNG-5813][MNG-5813].
* Since Maven 3.3.1 it is possible to have configurations stored on a per project base in the
- `${maven.projectBasedir}/.mvn` directory of the project. There you can use the `maven.config`
+ `${maven.projectBasedir}/.mvn` folder of the project. There you can use the `maven.config`
file to store command line options instead of repeating them every time you call Maven.
In cases where this file has been empty Maven ended with a failure. This has been fixed
with [MNG-5816][MNG-5816].
@@ -147,7 +147,7 @@ Bugs
has been fixed with [MNG-5721].
* There had been several issues with the `mvn` script which are for example
- wrong locating the `.mvn` directory, nonportable shell constructs, wrongly setting
+ wrong locating the `.mvn` folder, nonportable shell constructs, wrongly setting
'maven.multiModuleProjectDirectory' variable or directories which contain spaces. Those
issues have been fixed [MNG-5786][MNG-5786], [MNG-5858][MNG-5858],
[MNG-5882][MNG-5882] and [MNG-5884][MNG-5884].
diff --git a/content/markdown/faq-unoffical.md b/content/markdown/faq-unoffical.md
index bfaafe59..4adb12de 100644
--- a/content/markdown/faq-unoffical.md
+++ b/content/markdown/faq-unoffical.md
@@ -40,7 +40,7 @@ This page serves as a collection of questions *with* answers. If you have a freq
### Eclipse
-[How do I specify which output directories the Eclipse plugin puts into the .classpath file?](#How do I specify which output directories the Eclipse plugin puts into the .classpath file?]
+[How do I specify which output folders the Eclipse plugin puts into the .classpath file?](#How do I specify which output folders the Eclipse plugin puts into the .classpath file?]
[Where can I get the Maven plugin for Eclipse?](#Where can I get the Maven plugin for Eclipse?]
[I issued\- mvn \-Declipse.downloadSources=true eclipse eclipse goal. It created .classpath and .project for both modules, and in my local repository it downloaded sources Ho do I access them in eclipse?](#I issued- mvn -Declipse.downloadSources=true eclipse eclipse goal. It created .classpath and .project for both modules, and in my local repository it downloaded sources Ho do I access them in eclipse?]
[Is it possible that if I do mvn eclipse eclipse goal that my project would get disconnected from the subversion repository?](#Is it possible that if I do mvn eclipse eclipse goal that my project would get disconnected from the subversion repository?]
@@ -517,7 +517,7 @@ To specify a remote repo in Maven, add the `<repositories>` element to the POM:
Or, refer to the following page [http://maven.apache.org/guides/mini/guide-multiple-repositories.html)
_Repositories_
-### How do I specify which output directories the Eclipse plugin puts into the .classpath file?
+### How do I specify which output folders the Eclipse plugin puts into the .classpath file?
```
<build>
@@ -1518,7 +1518,7 @@ Wagon wagon;
### How do I set the base directory for creating the packages created by assembly?
-The assembly plugin, by default, saves the packages to your project.build.directory from your pom or
+The assembly plugin, by default, saves the packages to your project.build.directory folder from your pom or
```
<project>
...
@@ -1968,4 +1968,4 @@ This sometimes happens when $M2_HOME is not the same as your $PATH. That is, wh
If you want to `mvn --encrypt-password` a password with an ampersand you will get an error, e.g. `mvn --encrypt-password test&Password`
On the one hand the ampersand has to be encoded as entity with &. On the other hand the ampersand has to be escaped for the command line.
Result would be `mvn --encrypt-password test &Password`
-Also a dollar sign $ has to be escaped for the command line.
+Also a dollar sign $ has to be escaped for the command line.
\ No newline at end of file
diff --git a/content/markdown/guides/mini/guide-3rd-party-jars-local.md b/content/markdown/guides/mini/guide-3rd-party-jars-local.md
index 28343a29..fca1ef3b 100644
--- a/content/markdown/guides/mini/guide-3rd-party-jars-local.md
+++ b/content/markdown/guides/mini/guide-3rd-party-jars-local.md
@@ -46,7 +46,7 @@ mvn install:install-file -Dfile=<path-to-file> -DgroupId=<group-id> -DartifactId
mvn install:install-file -Dfile=<path-to-file> -DpomFile=<path-to-pomfile>
```
- With version 2.5 of the maven-install-plugin, it can get even simpler: if the JAR was built by Apache Maven, it'll contain a pom.xml in a subdirectory of the META-INF/ directory, which will be read by default. In that case, all you need to do is:
+ With version 2.5 of the maven-install-plugin, it can get even simpler: if the JAR was built by Apache Maven, it'll contain a pom.xml in a subfolder of the META-INF/ directory, which will be read by default. In that case, all you need to do is:
diff --git a/content/markdown/guides/mini/guide-encryption.md b/content/markdown/guides/mini/guide-encryption.md
index 9046c2d6..4dc3e2d2 100644
--- a/content/markdown/guides/mini/guide-encryption.md
+++ b/content/markdown/guides/mini/guide-encryption.md
@@ -58,7 +58,7 @@ under the License.
- - authorized users have an additional `settings-security.xml` file in their `${user.home}/.m2` directory
+ - authorized users have an additional `settings-security.xml` file in their `${user.home}/.m2` folder
- this file either contains encrypted **master password**, used to encrypt other passwords
diff --git a/content/markdown/guides/mini/guide-releasing.md b/content/markdown/guides/mini/guide-releasing.md
index 196c9d80..61f7593e 100644
--- a/content/markdown/guides/mini/guide-releasing.md
+++ b/content/markdown/guides/mini/guide-releasing.md
@@ -169,7 +169,7 @@ mvn release:prepare \
- **A Desired SCM provider tag name**.
- This is a SCM provider specific value, in the case of the Subversion SCM provider this value is equal to the directory name that will appear under the URL provided by the the tagBase parameter.
+ This is a SCM provider specific value, in the case of the Subversion SCM provider this value is equal to the folder name that will appear under the URL provided by the the tagBase parameter.
diff --git a/content/markdown/install.md.vm b/content/markdown/install.md.vm
index 7e003d4a..6c1d059c 100644
--- a/content/markdown/install.md.vm
+++ b/content/markdown/install.md.vm
@@ -18,7 +18,7 @@ specific language governing permissions and limitations
under the License.
-->
The installation of Apache Maven is a simple process of extracting the archive
-and adding the `bin` directory with the `mvn` command to the `PATH`.
+and adding the `bin` folder with the `mvn` command to the `PATH`.
Detailed steps are:
diff --git a/content/markdown/maven-jsr330.md b/content/markdown/maven-jsr330.md
index 41acdc14..0ce05fbc 100644
--- a/content/markdown/maven-jsr330.md
+++ b/content/markdown/maven-jsr330.md
@@ -123,7 +123,7 @@ Ok, so let's take a look at the POM:
```
So, as mentioned, we have the `javax.inject` dependency and the `sisu-maven-plugin` configured to create
-the JSR-330 component index. When you build and place the extension JAR in the `${MAVEN_HOME}/lib/ext` directory,
+the JSR-330 component index. When you build and place the extension JAR in the `${MAVEN_HOME}/lib/ext` folder,
it will automatically get picked up by Maven. In the case of this example, we have an implementation of
an `EventSpy` that times the executions of individual mojos within a phase in the lifecycle.
diff --git a/content/markdown/plugin-developers/common-bugs.md b/content/markdown/plugin-developers/common-bugs.md
index 63fb6a7b..947be36d 100644
--- a/content/markdown/plugin-developers/common-bugs.md
+++ b/content/markdown/plugin-developers/common-bugs.md
@@ -287,7 +287,7 @@ public MyMojo extends AbstractMojo
a Embedded Maven Invocations
- Other tools, most notably IDEs, that run Maven under the hood may have set the current working directory to their installation directory or whatever they like.
+ Other tools, most notably IDEs, that run Maven under the hood may have set the current working directory to their installation folder or whatever they like.
diff --git a/content/markdown/plugins/index.md b/content/markdown/plugins/index.md
index b92246ce..e3564f51 100644
--- a/content/markdown/plugins/index.md
+++ b/content/markdown/plugins/index.md
@@ -35,7 +35,7 @@ under the License.
### Supported By The Maven Project
- To see the most up-to-date list browse the Maven repository, specifically the [ `org/apache/maven/plugins`](https://repo.maven.apache.org/maven2/org/apache/maven/plugins/) subdirectory. _(Plugins are organized according to a directory structure that resembles the standard Java package naming convention)_
+ To see the most up-to-date list browse the Maven repository, specifically the [ `org/apache/maven/plugins`](https://repo.maven.apache.org/maven2/org/apache/maven/plugins/) subfolder. _(Plugins are organized according to a directory structure that resembles the standard Java package naming convention)_
<!-- TODO: the repository manager should be able to produce a page like this. Ensure all descriptions are in the POM of these plugins. -->
@@ -141,7 +141,7 @@ under the License.
|**Plugin** (see [complete list with version](https://www.mojohaus.org/plugins.html))|**Description**|
|---|---|
|[ `animal-sniffer`](https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/)|Build signatures of APIs (JDK for example) and checks your classes against them.|
-|[ `build-helper`](https://www.mojohaus.org/build-helper-maven-plugin/)|Attach extra artifacts and source directories to build.|
+|[ `build-helper`](https://www.mojohaus.org/build-helper-maven-plugin/)|Attach extra artifacts and source folders to build.|
|[ `buildplan`](https://www.mojohaus.org/buildplan-maven-plugin/)|Inspect the lifecycle of your build.|
|[ `castor`](https://www.mojohaus.org/castor-maven-plugin/)|Generate sources from an XSD using Castor.|
|[ `clirr`](https://www.mojohaus.org/clirr-maven-plugin/)|Compare binaries or sources for compatibility using Clirr|
diff --git a/content/markdown/plugins/localization.md b/content/markdown/plugins/localization.md
index a4874e93..51b6d210 100644
--- a/content/markdown/plugins/localization.md
+++ b/content/markdown/plugins/localization.md
@@ -60,7 +60,7 @@ under the License.
- Check out the source code for the plugin you want to add a translation to.
- - Find the resource bundles that needs to be translated. They are often found in the `src/main/resources` directory.
+ - Find the resource bundles that needs to be translated. They are often found in the `src/main/resources` folder.
- Copy the basefile for the bundle, i.e. the one **without** a language extension. The copy should have the same name as the original file, except for the addition of a language extension. If, for example, you want to translate the Checkstyle Plugin into Spanish, you would copy `src/main/resources/checkstyle-report.properties` to `src/main/resources/checkstyle-report_es.properties`.
diff --git a/content/markdown/security-plexus-archiver.md b/content/markdown/security-plexus-archiver.md
index 49decd71..6c6829c4 100644
--- a/content/markdown/security-plexus-archiver.md
+++ b/content/markdown/security-plexus-archiver.md
@@ -23,7 +23,7 @@ an arbitrary file write generic vulnerability, that can be achieved using a
specially crafted zip (or bzip2, gzip, tar, xz, war) archive, that holds
path traversal filenames. So when the filename gets concatenated to the
target extraction directory, if the extraction tool used does not make
-sufficient checks, the final path ends up outside of the target directory.
+sufficient checks, the final path ends up outside of the target folder.
The Apache Maven team has been informed because the plexus-archiver library
did not make sufficient checks and it is a library used by most of the
diff --git a/content/markdown/security.md b/content/markdown/security.md
index 6ef1552d..cea1c2e6 100644
--- a/content/markdown/security.md
+++ b/content/markdown/security.md
@@ -77,7 +77,7 @@ an arbitrary file write generic vulnerability, that can be achieved using a
specially crafted zip (or bzip2, gzip, tar, xz, war) archive, that holds
path traversal filenames. So when the filename gets concatenated to the
target extraction directory, if the extraction tool used does not make
-sufficient checks, the final path ends up outside of the target directory.
+sufficient checks, the final path ends up outside of the target folder.
The affected plugins use plexus-archiver to unpack dependencies to disk
and have been identified as potential triggers for exposing the vulnerability
if dependencies are compromised.
[maven-site] 08/14: Revert "fix JIRA link, reformt"
Posted by sl...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit be357c6d99ee87748f6e902d90d7de98a4959743
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 21:33:39 2023 +0100
Revert "fix JIRA link, reformt"
This reverts commit 6a372b543628ca9a2a79937d7d0e70ae080ba6cb.
---
content/markdown/shared/index.md | 48 ++++++++++++++++++++--------------------
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/content/markdown/shared/index.md b/content/markdown/shared/index.md
index 199a5728..464eb023 100644
--- a/content/markdown/shared/index.md
+++ b/content/markdown/shared/index.md
@@ -26,30 +26,30 @@ under the License.
The shared components are currently under transition to Maven 3.x only components.
-| **Shared Component** | **Version** | **Release Date** | **Description** | **Source Repository** | **Issue Tracking** |
-| -------------------- | ----------- | ---------------- | --------------- | --------------------- | ----------------- |
-| [`file-management`](/shared/file-management/) | 3.1.0 | 2022-06-29 | API to collect files from a given directory using several include/exclude rules. | [Git](https://gitbox.apache.org/repos/asf/maven-file-management.git) / [GitHub](https://github.com/apache/maven-file-management/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=file-management) |
-| [`maven-archiver`](/shared/maven-archiver/) | 3.6.0 | 2022-06-23 | Is mainly used by plugins to handle packaging. | [Git](https://gitbox.apache.org/repos/asf/maven-archiver.git) / [GitHub](https://github.com/apache/maven-archiver/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-archiver) |
-| [`maven-artifact-transfer`](/shared/maven-artifact-transfer/) | 0.13.1 | 2020-12-26 | An API to install, deploy and resolve artifacts with Maven | [Git](https://gitbox.apache.org/repos/asf/maven-artifact-transfer.git) / [GitHub](https://github.com/apache/maven-artifact-transfer/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-artifact-transfer) |
-| [`maven-common-artifact-filters`](/shared/maven-common-artifact-filters/) | 3.3.2 | 2022-09-12 | Filters lists of Artifact instances. | [Git](https://gitbox.apache.org/repos/asf/maven-common-artifact-filters.git) / [GitHub](https://github.com/apache/maven-common-artifact-filters/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-common-artifact-filters) |
-| [`maven-dependency-analyzer`](/shared/maven-dependency-analyzer/) | 1.13.0 | 2022-08-20 | Maven Dependency Analyzer component. | [Git](https://gitbox.apache.org/repos/asf/maven-dependency-analyzer.git) / [GitHub](https://github.com/apache/maven-dependency-analyzer/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-dependency-analyzer) |
-| [`maven-dependency-tree`](/shared/maven-dependency-tree/) | 3.2.1 | 2022-11-16 | Maven Dependency Tree constructs a tree model of a Maven project's dependencies. | [Git](https://gitbox.apache.org/repos/asf/maven-dependency-tree.git) / [GitHub](https://github.com/apache/maven-dependency-tree/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-dependency-tree) |
-| [`maven-doxia-tools`](/doxia/doxia-sitetools/doxia-integration-tools/) | | | moved to [`doxia-integration-tools`](/doxia/doxia-sitetools/doxia-integration-tools/) | | |
-| [`maven-filtering`](/shared/maven-filtering/) | 3.3.0 | 2022-06-14 | Components for filtering resources. | [Git](https://gitbox.apache.org/repos/asf/maven-filtering.git) / [GitHub](https://github.com/apache/maven-filtering/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-filtering) |
-| [`maven-invoker`](/shared/maven-invoker/) | 3.2.0 | 2022-04-05 | Fires up a Maven build in a new JVM. | [Git](https://gitbox.apache.org/repos/asf/maven-invoker.git) / [GitHub](https://github.com/apache/maven-invoker/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-invoker) |
-| [`maven-jarsigner`](/shared/maven-jarsigner/) | 3.0.0 | 2018-10-31 | This component provides some utilities to sign/verify jars/files in your Mojos. | [Git](https://gitbox.apache.org/repos/asf/maven-jarsigner.git) / [GitHub](https://github.com/apache/maven-jarsigner/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-jarsigner) |
-| [`maven-mapping`](/shared/maven-mapping/) | 3.0.0 | 2015-11-19 | A shared component for all plugins that need to do mapping. | [Git](https://gitbox.apache.org/repos/asf/maven-mapping.git) / [GitHub](https://github.com/apache/maven-mapping/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-mapping) |
-| [`maven-reporting-api`](/shared/maven-reporting-api/) | 4.0.0-M4 | 2023-01-21 | API to manage report generation. | [Git](https://gitbox.apache.org/repos/asf/maven-reporting-api.git) / [GitHub](https://github.com/apache/maven-reporting-api/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-reporting-api) |
-| [`maven-reporting-exec`](/shared/maven-reporting-exec/) | 2.0.0-M4 | 2023-01-31 | API to manage report plugins preparation with Maven 3. | [Git](https://gitbox.apache.org/repos/asf/maven-reporting-exec.git) / [GitHub](https://github.com/apache/maven-reporting-exec/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-reporting-exec) |
-| [`maven-reporting-impl`](/shared/maven-reporting-impl/) | 4.0.0-M4 | 2023-02-11 | Abstract classes to manage report generation. | [Git](https://gitbox.apache.org/repos/asf/maven-reporting-impl.git) / [GitHub](https://github.com/apache/maven-reporting-impl/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-reporting-impl) |
-| [`maven-script-interpreter`](/shared/maven-script-interpreter/) | 1.4 | 2022-12-20 | Utilities to interpret/execute some scripts for various implementations: groovy or beanshell. | [Git](https://gitbox.apache.org/repos/asf/maven-script-interpreter.git) / [GitHub](https://github.com/apache/maven-script-interpreter/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-script-interpreter) |
-| [`maven-shared-incremental`](/shared/maven-shared-incremental/) | 1.1 | 2013-04-08 | Various utility classes and plexus components for supporting incremental build functionality in Maven plugins. | [Git](https://gitbox.apache.org/repos/asf/maven-shared-incremental.git) / [GitHub](https://github.com/apache/maven-shared-incremental/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-shared-incremental) |
-| [`maven-shared-jar`](/shared/maven-shared-jar/) | 1.2 | 2015-12-31 | Utilities which help identify the contents of a JAR, including Java class analysis and Maven metadata analysis. | [Git](https://gitbox.apache.org/repos/asf/maven-shared-jar.git) / [GitHub](https://github.com/apache/maven-shared-jar/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-shared-jar) |
-| [`maven-shared-resources`](/shared/maven-shared-resources/) | 5 | 2022-11-21 | This is a collection of templates that are specific to the Maven project. | [Git](https://gitbox.apache.org/repos/asf/maven-shared-resources.git) / [GitHub](https://github.com/apache/maven-shared-resources/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-shared-resources) |
-| [`maven-shared-utils`](/shared/maven-shared-utils/) | 3.3.4 | 2021-04-30 | Utilities functions for use within Maven. | [Git](https://gitbox.apache.org/repos/asf/maven-shared-utils.git) / [GitHub](https://github.com/apache/maven-shared-utils/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-shared-utils) |
-| [`maven-shared-io`](/shared/maven-shared-io/) | 3.0.0 | 2015-12-23 | API for I/O support like logging, download or file scanning. | [Git](https://gitbox.apache.org/repos/asf/maven-shared-io.git) / [GitHub](https://github.com/apache/maven-shared-io/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-shared-io) |
-| [`maven-verifier`](/shared/maven-verifier/) | 2.0.0-M1 | 2022-09-22 | Used to run Maven builds as part of tests. | [Git](https://gitbox.apache.org/repos/asf/maven-verifier.git) / [GitHub](https://github.com/apache/maven-verifier/) | [JIRA](https://issues.apache.org/jira/issues/?jql=project=MSHARED%20AND%20status!=Closed%20AND%20component=maven-verifier) |
-| [`maven-scm`](/scm/) | 2.0.0-M1 | 2022-01-08 | Generic API to SCM systems. | [Git](https://gitbox.apache.org/repos/asf/maven-scm.git) / [GitHub](https://github.com/apache/maven-scm/) | [JIRA](https://issues.apache.org/jira/browse/SCM) |
+|**Shared Component**|**Version**|**Release Date**|**Description**|**Source Repository**|**Issue Tracking**|
+|---|---|---|---|---|---|
+|[ `file-management`](/shared/file-management/)|3.1.0|2022-06-29|API to collect files from a given directory using several include/exclude rules.|[Git](https://gitbox.apache.org/repos/asf/maven-file-management.git) / [GitHub](https://github.com/apache/maven-file-management/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = file-management)|
+|[ `maven-archiver`](/shared/maven-archiver/)|3.6.0|2022-06-23|Is mainly used by plugins to handle packaging.|[Git](https://gitbox.apache.org/repos/asf/maven-archiver.git) / [GitHub](https://github.com/apache/maven-archiver/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-archiver)|
+|[ `maven-artifact-transfer`](/shared/maven-artifact-transfer/)|0.13.1|2020-12-26|An API to install, deploy and resolve artifacts with Maven|[Git](https://gitbox.apache.org/repos/asf/maven-artifact-transfer.git) / [GitHub](https://github.com/apache/maven-artifact-transfer/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-artifact-transfer)|
+|[ `maven-common-artifact-filters`](/shared/maven-common-artifact-filters/)|3.3.2|2022-09-12|Filters lists of Artifact instances.|[Git](https://gitbox.apache.org/repos/asf/maven-common-artifact-filters.git) / [GitHub](https://github.com/apache/maven-common-artifact-filters/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-common-artifact-filters)|
+|[ `maven-dependency-analyzer`](/shared/maven-dependency-analyzer/)|1.13.0|2022-08-20|Maven Dependency Analyzer component.|[Git](https://gitbox.apache.org/repos/asf/maven-dependency-analyzer.git) / [GitHub](https://github.com/apache/maven-dependency-analyzer/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-dependency-analyzer)|
+|[ `maven-dependency-tree`](/shared/maven-dependency-tree/)|3.2.1|2022-11-16|Maven Dependency Tree constructs a tree model of a Maven project's dependencies.|[Git](https://gitbox.apache.org/repos/asf/maven-dependency-tree.git) / [GitHub](https://github.com/apache/maven-dependency-tree/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-dependency-tree)|
+|[ `maven-doxia-tools`](/doxia/doxia-sitetools/doxia-integration-tools/)|||moved to [ `doxia-integration-tools`](/doxia/doxia-sitetools/doxia-integration-tools/)|||
+|[ `maven-filtering`](/shared/maven-filtering/)|3.3.0|2022-06-14|Components for filtering resources.|[Git](https://gitbox.apache.org/repos/asf/maven-filtering.git) / [GitHub](https://github.com/apache/maven-filtering/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-filtering)|
+|[ `maven-invoker`](/shared/maven-invoker/)|3.2.0|2022-04-05|Fires up a Maven build in a new JVM.|[Git](https://gitbox.apache.org/repos/asf/maven-invoker.git) / [GitHub](https://github.com/apache/maven-invoker/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-invoker)|
+|[ `maven-jarsigner`](/shared/maven-jarsigner/)|3.0.0|2018-10-31|This component provides some utilities to sign/verify jars/files in your Mojos.|[Git](https://gitbox.apache.org/repos/asf/maven-jarsigner.git) / [GitHub](https://github.com/apache/maven-jarsigner/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-jarsigner)|
+|[ `maven-mapping`](/shared/maven-mapping/)|3.0.0|2015-11-19|A shared component for all plugins that need to do mapping.|[Git](https://gitbox.apache.org/repos/asf/maven-mapping.git) / [GitHub](https://github.com/apache/maven-mapping/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-mapping)|
+|[ `maven-reporting-api`](/shared/maven-reporting-api/)|4.0.0-M4|2023-01-21|API to manage report generation.|[Git](https://gitbox.apache.org/repos/asf/maven-reporting-api.git) / [GitHub](https://github.com/apache/maven-reporting-api/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-reporting-api)|
+|[ `maven-reporting-exec`](/shared/maven-reporting-exec/)|2.0.0-M4|2023-01-31|API to manage report plugins preparation with Maven 3.|[Git](https://gitbox.apache.org/repos/asf/maven-reporting-exec.git) / [GitHub](https://github.com/apache/maven-reporting-exec/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-reporting-exec)|
+|[ `maven-reporting-impl`](/shared/maven-reporting-impl/)|4.0.0-M4|2023-02-11|Abstract classes to manage report generation.|[Git](https://gitbox.apache.org/repos/asf/maven-reporting-impl.git) / [GitHub](https://github.com/apache/maven-reporting-impl/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-reporting-impl)|
+|[ `maven-script-interpreter`](/shared/maven-script-interpreter/)|1.4|2022-12-20|Utilities to interpret/execute some scripts for various implementations: groovy or beanshell.|[Git](https://gitbox.apache.org/repos/asf/maven-script-interpreter.git) / [GitHub](https://github.com/apache/maven-script-interpreter/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-script-interpreter)|
+|[ `maven-shared-incremental`](/shared/maven-shared-incremental/)|1.1|2013-04-08|Various utility classes and plexus components for supporting incremental build functionality in Maven plugins.|[Git](https://gitbox.apache.org/repos/asf/maven-shared-incremental.git) / [GitHub](https://github.com/apache/maven-shared-incremental/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-shared-incremental)|
+|[ `maven-shared-jar`](/shared/maven-shared-jar/)|1.2|2015-12-31|Utilities which help identify the contents of a JAR, including Java class analysis and Maven metadata analysis.|[Git](https://gitbox.apache.org/repos/asf/maven-shared-jar.git) / [GitHub](https://github.com/apache/maven-shared-jar/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-shared-jar)|
+|[ `maven-shared-resources`](/shared/maven-shared-resources/)|5|2022-11-21|This is a collection of templates that are specific to the Maven project.|[Git](https://gitbox.apache.org/repos/asf/maven-shared-resources.git) / [GitHub](https://github.com/apache/maven-shared-resources/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-shared-resources)|
+|[ `maven-shared-utils`](/shared/maven-shared-utils/)|3.3.4|2021-04-30|Utilities functions for use within Maven.|[Git](https://gitbox.apache.org/repos/asf/maven-shared-utils.git) / [GitHub](https://github.com/apache/maven-shared-utils/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-shared-utils)|
+|[ `maven-shared-io`](/shared/maven-shared-io/)|3.0.0|2015-12-23|API for I/O support like logging, download or file scanning.|[Git](https://gitbox.apache.org/repos/asf/maven-shared-io.git) / [GitHub](https://github.com/apache/maven-shared-io/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-shared-io)|
+|[ `maven-verifier`](/shared/maven-verifier/)|2.0.0-M1|2022-09-22|Used to run Maven builds as part of tests.|[Git](https://gitbox.apache.org/repos/asf/maven-verifier.git) / [GitHub](https://github.com/apache/maven-verifier/)|[JIRA](https://issues.apache.org/jira/issues/?jql=project = MSHARED AND status != Closed AND component = maven-verifier)|
+|[ `maven-scm`](/scm/)|2.0.0-M1|2022-01-08|Generic API to SCM systems.|[Git](https://gitbox.apache.org/repos/asf/maven-scm.git) / [GitHub](https://github.com/apache/maven-scm/)|[JIRA](https://issues.apache.org/jira/browse/SCM)|
Archived version of shared libraries reference documentations are [located here](../shared-archives/).