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/09 00:39:13 UTC
[maven-site] branch master updated: [MNGSITE-507] Converted .apt documents to Markdown
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
The following commit(s) were added to refs/heads/master by this push:
new 394bf48a [MNGSITE-507] Converted .apt documents to Markdown
394bf48a is described below
commit 394bf48addb9008c0fd65db521d70af6245d47b3
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Thu Feb 9 01:24:58 2023 +0100
[MNGSITE-507] Converted .apt documents to Markdown
---
content/apt/archives/maven-2.x/index.apt | 48 -
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 --
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 -
.../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 --
.../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 --
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 +
.../maven-2.x/maven-2.1-architectural-goals.md} | 0
.../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 ++
.../developers/release/pmc-gpg-keys.md} | 152 ++-
.../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/website/website-overview.odg | Bin
.../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-assemblies.md} | 118 +-
.../guides/mini/guide-attached-tests.md} | 81 +-
.../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 ++
.../guides/mini/guide-using-ant.md} | 73 +-
.../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, 18328 insertions(+), 18059 deletions(-)
diff --git a/content/apt/archives/maven-2.x/index.apt b/content/apt/archives/maven-2.x/index.apt
deleted file mode 100644
index c629528a..00000000
--- a/content/apt/archives/maven-2.x/index.apt
+++ /dev/null
@@ -1,48 +0,0 @@
- ---
- 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/apt/developers/committer-environment.apt b/content/apt/developers/committer-environment.apt
deleted file mode 100644
index 9247e4e1..00000000
--- a/content/apt/developers/committer-environment.apt
+++ /dev/null
@@ -1,54 +0,0 @@
- ------
- 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
deleted file mode 100644
index dbe1c629..00000000
--- a/content/apt/developers/committer-settings.apt
+++ /dev/null
@@ -1,81 +0,0 @@
- ------
- 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
deleted file mode 100644
index 1fce293f..00000000
--- a/content/apt/developers/compatibility-plan.apt
+++ /dev/null
@@ -1,77 +0,0 @@
- ------
- 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
deleted file mode 100644
index aca633f8..00000000
--- a/content/apt/developers/conventions/code.apt
+++ /dev/null
@@ -1,246 +0,0 @@
- ------
- 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
deleted file mode 100644
index b08a99e3..00000000
--- a/content/apt/developers/conventions/git.apt
+++ /dev/null
@@ -1,228 +0,0 @@
- ------
- 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
deleted file mode 100644
index 60ab6a42..00000000
--- a/content/apt/developers/dependency-policies.apt
+++ /dev/null
@@ -1,78 +0,0 @@
- ------
- 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
deleted file mode 100644
index 6886ea21..00000000
--- a/content/apt/developers/index.apt
+++ /dev/null
@@ -1,115 +0,0 @@
- ------
- 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
deleted file mode 100644
index 385ac4ed..00000000
--- a/content/apt/developers/release/index.apt
+++ /dev/null
@@ -1,48 +0,0 @@
- -----
- 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
deleted file mode 100644
index 3c827cd5..00000000
--- a/content/apt/developers/release/maven-project-release-procedure.apt
+++ /dev/null
@@ -1,328 +0,0 @@
- -----
- 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
deleted file mode 100644
index 3e357916..00000000
--- a/content/apt/developers/release/parent-pom-release.apt
+++ /dev/null
@@ -1,101 +0,0 @@
- -----
- 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/apt/developers/retirement-plan-plugins.apt b/content/apt/developers/retirement-plan-plugins.apt
deleted file mode 100644
index 1c15a4be..00000000
--- a/content/apt/developers/retirement-plan-plugins.apt
+++ /dev/null
@@ -1,166 +0,0 @@
- ------
- 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
deleted file mode 100644
index 2ada4474..00000000
--- a/content/apt/developers/website/deploy-component-reference-documentation.apt
+++ /dev/null
@@ -1,165 +0,0 @@
- ------
- 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
deleted file mode 100644
index 179e5365..00000000
--- a/content/apt/developers/website/deploy-maven-website.apt
+++ /dev/null
@@ -1,117 +0,0 @@
- ------
- 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
deleted file mode 100644
index a18de28b..00000000
--- a/content/apt/developers/website/index.apt
+++ /dev/null
@@ -1,74 +0,0 @@
- ------
- 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
deleted file mode 100644
index 63e11968..00000000
--- a/content/apt/developers/website/website-overview.apt
+++ /dev/null
@@ -1,43 +0,0 @@
- ------
- 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/apt/developers/welcome-to-new-committers.apt b/content/apt/developers/welcome-to-new-committers.apt
deleted file mode 100644
index ad1400d4..00000000
--- a/content/apt/developers/welcome-to-new-committers.apt
+++ /dev/null
@@ -1,70 +0,0 @@
- ------
- 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
deleted file mode 100644
index ef4d66ef..00000000
--- a/content/apt/examples/index.apt
+++ /dev/null
@@ -1,35 +0,0 @@
- ---
- 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
deleted file mode 100644
index 09498baa..00000000
--- a/content/apt/examples/injecting-properties-via-settings.apt
+++ /dev/null
@@ -1,84 +0,0 @@
- ---
- 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
deleted file mode 100644
index ce8bc8f3..00000000
--- a/content/apt/guides/development/guide-building-maven.apt
+++ /dev/null
@@ -1,92 +0,0 @@
- ------
- 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
deleted file mode 100644
index 6c6aa22c..00000000
--- a/content/apt/guides/development/guide-committer-school.apt
+++ /dev/null
@@ -1,157 +0,0 @@
- ------
- 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
deleted file mode 100644
index 09817584..00000000
--- a/content/apt/guides/development/guide-documentation-style.apt
+++ /dev/null
@@ -1,136 +0,0 @@
- ------
- 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
deleted file mode 100644
index 82c2237c..00000000
--- a/content/apt/guides/development/guide-helping.apt
+++ /dev/null
@@ -1,106 +0,0 @@
- ------
- 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
deleted file mode 100644
index 1b919b67..00000000
--- a/content/apt/guides/development/guide-maven-development.apt
+++ /dev/null
@@ -1,197 +0,0 @@
- ------
- 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
deleted file mode 100644
index 3a7f4cae..00000000
--- a/content/apt/guides/development/guide-plugin-documentation.apt
+++ /dev/null
@@ -1,410 +0,0 @@
- ------
- 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
deleted file mode 100644
index 22e87db7..00000000
--- a/content/apt/guides/development/guide-testing-development-plugins.apt
+++ /dev/null
@@ -1,141 +0,0 @@
- ------
- 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
deleted file mode 100644
index 7b5cc24f..00000000
--- a/content/apt/guides/development/guide-testing-releases.apt
+++ /dev/null
@@ -1,153 +0,0 @@
- ------
- 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
deleted file mode 100644
index ba3fb02c..00000000
--- a/content/apt/guides/getting-started/index.apt
+++ /dev/null
@@ -1,1241 +0,0 @@
- ----
- 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
deleted file mode 100644
index 3b9a7185..00000000
--- a/content/apt/guides/getting-started/maven-in-five-minutes.apt
+++ /dev/null
@@ -1,294 +0,0 @@
- ----
- 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
deleted file mode 100644
index 8fd7640b..00000000
--- a/content/apt/guides/getting-started/windows-prerequisites.apt
+++ /dev/null
@@ -1,66 +0,0 @@
- ----
- 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
deleted file mode 100644
index 70c3c10c..00000000
--- a/content/apt/guides/introduction/introduction-to-archetypes.apt
+++ /dev/null
@@ -1,102 +0,0 @@
- ------
- 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
deleted file mode 100644
index c976d057..00000000
--- a/content/apt/guides/introduction/introduction-to-dependency-mechanism.apt
+++ /dev/null
@@ -1,876 +0,0 @@
- ------
- 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
deleted file mode 100644
index 4ecceba6..00000000
--- a/content/apt/guides/introduction/introduction-to-optional-and-excludes-dependencies.apt
+++ /dev/null
@@ -1,320 +0,0 @@
- ------
- 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
deleted file mode 100644
index 3980eb45..00000000
--- a/content/apt/guides/introduction/introduction-to-plugin-prefix-mapping.apt
+++ /dev/null
@@ -1,167 +0,0 @@
- ---
- 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
deleted file mode 100644
index cde95074..00000000
--- a/content/apt/guides/introduction/introduction-to-plugins.apt
+++ /dev/null
@@ -1,87 +0,0 @@
- ------
- 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
deleted file mode 100644
index 0208564b..00000000
--- a/content/apt/guides/introduction/introduction-to-profiles.apt
+++ /dev/null
@@ -1,816 +0,0 @@
- ---
- 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
deleted file mode 100644
index 099abbdc..00000000
--- a/content/apt/guides/introduction/introduction-to-repositories.apt
+++ /dev/null
@@ -1,167 +0,0 @@
- ------
- 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
deleted file mode 100644
index f643d2c5..00000000
--- a/content/apt/guides/introduction/introduction-to-the-lifecycle.apt
+++ /dev/null
@@ -1,483 +0,0 @@
- ------
- 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
deleted file mode 100644
index f75baf22..00000000
--- a/content/apt/guides/introduction/introduction-to-the-pom.apt
+++ /dev/null
@@ -1,577 +0,0 @@
- ------
- 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
deleted file mode 100644
index 531208bc..00000000
--- a/content/apt/guides/introduction/introduction-to-the-standard-directory-layout.apt
+++ /dev/null
@@ -1,86 +0,0 @@
- ------
- 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
deleted file mode 100644
index 4c424769..00000000
--- a/content/apt/guides/mini/guide-3rd-party-jars-local.apt
+++ /dev/null
@@ -1,59 +0,0 @@
- ------
- 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
deleted file mode 100644
index 9670586d..00000000
--- a/content/apt/guides/mini/guide-3rd-party-jars-remote.apt
+++ /dev/null
@@ -1,87 +0,0 @@
- ------
- 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
deleted file mode 100644
index f0011a25..00000000
--- a/content/apt/guides/mini/guide-archive-configuration.apt
+++ /dev/null
@@ -1,71 +0,0 @@
- ------
- 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/apt/guides/mini/guide-bash-m2-completion.apt b/content/apt/guides/mini/guide-bash-m2-completion.apt
deleted file mode 100644
index 96ac9377..00000000
--- a/content/apt/guides/mini/guide-bash-m2-completion.apt
+++ /dev/null
@@ -1,37 +0,0 @@
- ------
- Guide to Maven auto completion using BASH
- ------
- Trygve Laugstol
- Jason van Zyl
- Karl Heinz Marbaise
- ------
- 2016-01-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
-
-Guide to Maven auto completion using BASH
-
- If you like having bash completion which i can recommend if you are working
- with Maven on command line i would suggest to install
- the following {{{https://github.com/juven/maven-bash-completion}Maven Bash Auto Completion}}
- to fullfil you needs.
-
diff --git a/content/apt/guides/mini/guide-building-for-different-environments.apt b/content/apt/guides/mini/guide-building-for-different-environments.apt
deleted file mode 100644
index b1813f55..00000000
--- a/content/apt/guides/mini/guide-building-for-different-environments.apt
+++ /dev/null
@@ -1,161 +0,0 @@
- ---
- Building For Different Environments
- ---
- Trygve Laugstøl
- ---
- 2006-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
-
-Building For Different Environments
-
- Building the same artifact for different environments has always been an annoyance. You have multiple environments,
- for instance test and production servers or, maybe a set of servers that run the same application with different
- configurations. In this guide I'll explain how you can use profiles to build and package artifacts configured for
- specific environments. See {{{../introduction/introduction-to-profiles.html}Introduction to Build Profiles}} for a
- more in-depth explanation of the profile concept.
-
- Note:
-
- * This guide assume that you have basic Maven knowledge.
-
- * It will show a way to configure Maven to solve simple configuration set-ups only. By simple configuration set-up I
- mean cases where you only have a single file or a small set of files that vary for each environment. There are
- other and better ways to handle two and many-dimensional configuration issues.
-
-
- This example assume the use of the
- {{{../introduction/introduction-to-the-standard-directory-layout.html}Standard Directory Layout}}.
-
-----
-pom.xml
-src/
- main/
- java/
- resources/
- test/
- java/
-----
-
-
- Under <<<src/main/resources>>> there are three files:
-
- * <<<environment.properties>>> - This is the default configuration and will be packaged in the artifact by default.
-
- * <<<environment.test.properties>>> - This is the variant for the test environment.
-
- * <<<environment.prod.properties>>> - This is basically the same as the test variant and will be used in the
- production environment.
-
- In the project descriptor, you need to configure the different profiles. Only the test profile is showed here.
-
-+----+
- <profiles>
- <profile>
- <id>test</id>
- <build>
- <plugins>
- <plugin>
- <artifactId>maven-antrun-plugin</artifactId>
- <executions>
- <execution>
- <phase>test</phase>
- <goals>
- <goal>run</goal>
- </goals>
- <configuration>
- <tasks>
- <delete file="${project.build.outputDirectory}/environment.properties"/>
- <copy file="src/main/resources/environment.test.properties"
- tofile="${project.build.outputDirectory}/environment.properties"/>
- </tasks>
- </configuration>
- </execution>
- </executions>
- </plugin>
- <plugin>
- <artifactId>maven-surefire-plugin</artifactId>
- <configuration>
- <skip>true</skip>
- </configuration>
- </plugin>
- <plugin>
- <artifactId>maven-jar-plugin</artifactId>
- <executions>
- <execution>
- <phase>package</phase>
- <goals>
- <goal>jar</goal>
- </goals>
- <configuration>
- <classifier>test</classifier>
- </configuration>
- </execution>
- </executions>
- </plugin>
- </plugins>
- </build>
- </profile>
-
- .. Other profiles go here ..
-
- </profiles>
-+----+
-
- Three things are configured in this snippet:
-
- [[1]] It configures the antrun plugin to execute the run goal in the test phase where it will copy the
- <<<environment.test.properties>>> file to <<<environment.properties>>>.
-
- [[2]] It will configure the test plugin to skip all tests when building the test and production artifacts.
- This is useful as you probably don't want to run tests against the production system
-
- [[3]] It configures the JAR plugin to create an "attached" JAR with the "test" classifier.
-
- To activate this profile execute <<<mvn -Ptest install>>> and Maven will execute the steps in the profile
- in addition to the normal steps. From this build you will get two artifacts, "foo-1.0.jar" and "foo-1.0-test.jar".
- These two jars will identical.
-
-Caveats
-
- * Currently Maven doesn't allow a project build to only produce attached artifacts. (i.e. it has to produce a
- "main" artifact as well) This results in two equal JARs being packaged and installed. The JAR plugin probably
- should also get improved support for this use case to that two different output directories will be used as the
- basis for building the JAR.
-
- * The usage of the delete task might seem a bit odd but is required to make sure that the copy task actually will
- copy the file. The copy task will look at the timestamps of the source and destination files, only when copying the
- files it won't know that the actually source file might be different than the last time it was executed.
-
- * After the build the test configuration will be in target/classes and won't be overridden because the resources
- plugin uses the same timestamp checking, so you should always do a clean after executing Maven with a profile.
-
- * For the reasons given above it's imperative that you only build an artifact for a single environment in a single
- execution at a time and that you execute "mvn clean" whenever you change the profile switches. If not, you might get
- artifacts with a mixed set of configuration files.
-
-Resources
-
- [[1]] {{{../introduction/introduction-to-profiles.html}Introduction to Build Profiles}}
-
- [[2]] {{{../introduction/introduction-to-the-standard-directory-layout.html}Standard Directory Layout}}
-
diff --git a/content/apt/guides/mini/guide-configuring-maven.apt b/content/apt/guides/mini/guide-configuring-maven.apt
deleted file mode 100644
index cc1652e7..00000000
--- a/content/apt/guides/mini/guide-configuring-maven.apt
+++ /dev/null
@@ -1,171 +0,0 @@
- ------
- Guide to Configuring Maven
- ------
- Brett Porter
- ------
- 2005-04-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
-
-Configuring Maven
-
- Maven configuration occurs at 3 levels:
-
- * <Project> - most static configuration occurs in <<<pom.xml>>>
-
- * <Installation> - this is configuration added once for a Maven installation
-
- * <User> - this is configuration specific to a particular user
-
- 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.
-
- For this, you should have your projects inherit from a company-wide parent <<<pom.xml>>>.
-
- ~~TODO: versioning doc that discusses this
-
- You can specify your user configuration in <<<$\{user.home\}/.m2/settings.xml>>>. A
- {{{../../maven-settings/settings.html}full reference}} 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/>>>.
-
-+-------------+
-<settings>
- ...
- <localRepository>/path/to/local/repo/</localRepository>
- ...
-</settings>
-+-------------+
-
- <<Note:>> The local repository must be an absolute path.
-
-* Configuring a Proxy
-
- Proxy configuration can also be specified in the settings file.
-
- For more information, see the {{{./guide-proxies.html} Guide to using a Proxy}}.
-
-* 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:
-
-----
-mvn -Dmaven.artifact.threads=1 verify
-----
-
- You may wish to set this option permanently, in which case you can use the <<<MAVEN_OPTS>>> environment variable. For example:
-
-----
-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.
-
- 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.
-
- 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:
-
-+-------------+
-<settings>
- ...
- <servers>
- <server>
- <id>repo1</id>
- <username>repouser</username>
- <!-- other optional elements:
- <password>my_login_password</password>
- <privateKey>/path/to/identity</privateKey> (default is ~/.ssh/id_dsa)
- <passphrase>my_key_passphrase</passphrase>
- -->
- </server>
- ...
- </servers>
- ...
-</settings>
-+-------------+
-
- To encrypt passwords in these sections, refer to {{{./guide-encryption.html} Encryption Settings}}.
-
-* Using Mirrors for Repositories
-
- Repositories can be declared inside a project, which means that if you have your own custom repositories, those
- sharing your project easily get the right settings out of the box. However, you may want to use an alternative
- mirror for a particular repository without changing the project files. Refer to {{{./guide-mirror-settings.html} Guide to Mirror Settings}}
- for more details.
-
-
-* Profiles
-
- Repository configuration can also be put into a profile. You can have multiple
- profiles, with one set to active so that you can easily switch environments.
- Read more about profiles in {{{../introduction/introduction-to-profiles.html}Introduction to Build Profiles}}.
-
-
-
-
-* Optional configuration
-
- Maven will work for most tasks with the above configuration, however if you have any environmental specific configuration outside of individual
- projects then you will need to configure settings. The following sections refer to what is available.
-
-
-** Settings
-
- Maven has a settings file located in the Maven installation and/or user home directory that configure environmental specifics such as:
-
- * HTTP proxy server
-
- * repository manager location
-
- * server authentication and passwords
-
- * other configuration properties
-
- []
-
- For information on this file, see the {{{/settings.html}Settings reference}}
-
-** 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-encryption.html}Guide to Password Encryption}}.
-
-** 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-using-toolchains.html}Guide to Using Toolchains}}.
diff --git a/content/apt/guides/mini/guide-configuring-plugins.apt b/content/apt/guides/mini/guide-configuring-plugins.apt
deleted file mode 100644
index 91f1b9e5..00000000
--- a/content/apt/guides/mini/guide-configuring-plugins.apt
+++ /dev/null
@@ -1,752 +0,0 @@
- ------
- Guide to Configuring Plug-ins
- ------
- Jason van Zyl
- Vincent Siveton
- ------
- 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
-
-Guide to Configuring Plug-ins
-
-%{toc|fromDepth=2}
-
-* Introduction
-
- In Maven, there are two kinds of plugins, build and reporting:
-
- * <<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.
-
- []
-
- All plugins should have minimal required
- {{{/ref/current/maven-model/maven.html#class_plugin}information}}:
- <<<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).
-
-* {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:
-
-+----+
-@Mojo( name = "query" )
-public class MyQueryMojo
- extends AbstractMojo
-{
- @Parameter(property = "query.url", required = true)
... 28181 lines suppressed ...