You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by sl...@apache.org on 2023/02/18 18:16:43 UTC
[maven-site] 01/02: (doc) lint markdown files
This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
commit dbcc0c8feef3dc2e1c725e24bdf0fb230c5dd079
Author: Sylwester Lachiewicz <sl...@apache.org>
AuthorDate: Sat Feb 18 18:32:07 2023 +0100
(doc) lint markdown files
---
content/markdown/aether.md | 2 +-
content/markdown/archives/maven-2.x/index.md | 2 +-
.../maven-2.x/maven-2.1-architectural-goals.md | 73 +++---
content/markdown/background/history-of-maven.md | 4 +-
content/markdown/background/philosophy-of-maven.md | 2 +-
content/markdown/code-quality-management.md | 10 +-
content/markdown/configure.md | 36 +--
.../markdown/developers/committer-environment.md | 20 +-
content/markdown/developers/committer-settings.md | 14 +-
content/markdown/developers/compatibility-plan.md | 42 +---
content/markdown/developers/conventions/code.md | 133 +++-------
content/markdown/developers/conventions/git.md | 77 +-----
content/markdown/developers/conventions/jira.md | 2 +-
content/markdown/developers/dependency-policies.md | 30 +--
content/markdown/developers/index.md | 75 ++----
content/markdown/developers/release/index.md | 14 +-
.../developers/release/maven-core-release.md | 7 +-
.../release/maven-project-release-procedure.md | 117 ++-------
.../developers/release/parent-pom-release.md | 26 +-
.../markdown/developers/release/pmc-gpg-keys.md | 20 --
.../markdown/developers/retirement-plan-plugins.md | 28 +--
.../component-reference-documentation-helper.md | 2 +-
.../deploy-component-reference-documentation.md | 54 +---
.../developers/website/deploy-maven-website.md | 55 +---
content/markdown/developers/website/index.md | 31 +--
.../developers/website/website-overview.md | 9 +-
.../developers/welcome-to-new-committers.md | 29 +--
content/markdown/docs/3.2.1/release-notes.md | 4 -
content/markdown/docs/3.2.2/release-notes.md | 3 +-
content/markdown/docs/3.2.3/release-notes.md | 5 -
content/markdown/docs/3.2.5/release-notes.md | 1 -
content/markdown/docs/3.3.1/release-notes.md | 70 +++---
content/markdown/docs/3.3.3/release-notes.md | 1 -
content/markdown/docs/3.3.9/release-notes.md | 125 +++++-----
.../markdown/docs/3.5.0-alpha-1/release-notes.md | 200 +++++++--------
.../markdown/docs/3.5.0-beta-1/release-notes.md | 74 +++---
content/markdown/docs/3.5.0/release-notes.md | 39 +--
content/markdown/docs/3.5.2/release-notes.md | 38 +--
content/markdown/docs/3.5.3/release-notes.md | 1 -
content/markdown/docs/3.5.4/release-notes.md | 6 +-
content/markdown/docs/3.6.0/release-notes.md | 39 +--
content/markdown/docs/3.6.1/release-notes.md | 176 +++++++------
content/markdown/docs/3.6.2/release-notes.md | 5 +-
content/markdown/docs/3.6.3/release-notes.md | 9 +-
content/markdown/docs/3.8.1/release-notes.md | 30 ++-
content/markdown/docs/3.8.3/release-notes.md | 6 +-
content/markdown/docs/3.8.4/release-notes.md | 5 +-
content/markdown/docs/3.8.5/release-notes.md | 2 +-
content/markdown/docs/3.8.6/release-notes.md | 4 +-
content/markdown/docs/3.8.7/release-notes.md | 6 +-
content/markdown/docs/3.9.0/release-notes.md | 48 ++--
.../markdown/docs/4.0.0-alpha-2/release-notes.md | 8 +-
.../markdown/docs/4.0.0-alpha-3/release-notes.md | 6 +-
.../markdown/docs/4.0.0-alpha-4/release-notes.md | 10 +-
content/markdown/examples/index.md | 6 +-
.../examples/injecting-properties-via-settings.md | 14 --
content/markdown/faq-unoffical.md | 228 +++++++++++------
content/markdown/glossary.md | 24 +-
.../guides/development/guide-building-maven.md | 37 +--
.../guides/development/guide-committer-school.md | 47 +---
.../development/guide-documentation-style.md | 47 +---
.../markdown/guides/development/guide-helping.md | 62 ++---
.../guides/development/guide-maven-development.md | 117 ++-------
.../development/guide-plugin-documentation.md | 161 +++---------
.../guide-testing-development-plugins.md | 43 +---
.../guides/development/guide-testing-releases.md | 67 ++---
content/markdown/guides/getting-started/index.md | 277 ++++-----------------
.../getting-started/maven-in-five-minutes.md | 92 +------
.../getting-started/windows-prerequisites.md | 18 --
.../introduction/introduction-to-archetypes.md | 19 --
.../introduction-to-dependency-mechanism.md | 144 ++---------
...uction-to-optional-and-excludes-dependencies.md | 65 +----
.../introduction-to-plugin-prefix-mapping.md | 43 +---
.../guides/introduction/introduction-to-plugins.md | 19 --
.../introduction/introduction-to-profiles.md | 272 ++++----------------
.../introduction/introduction-to-repositories.md | 50 ----
.../introduction/introduction-to-the-lifecycle.md | 124 +--------
.../guides/introduction/introduction-to-the-pom.md | 213 +++-------------
...ntroduction-to-the-standard-directory-layout.md | 10 -
.../guides/mini/guide-3rd-party-jars-local.md | 12 +-
.../guides/mini/guide-3rd-party-jars-remote.md | 19 --
.../guides/mini/guide-archive-configuration.md | 10 -
content/markdown/guides/mini/guide-assemblies.md | 16 --
.../markdown/guides/mini/guide-attached-tests.md | 7 -
.../guides/mini/guide-bash-m2-completion.md | 3 -
.../guide-building-for-different-environments.md | 47 +---
.../guides/mini/guide-configuring-maven.md | 72 +-----
.../guides/mini/guide-configuring-plugins.md | 172 ++-----------
.../guides/mini/guide-creating-archetypes.md | 54 +---
.../guides/mini/guide-default-execution-ids.md | 47 +---
.../mini/guide-deployment-security-settings.md | 10 +-
content/markdown/guides/mini/guide-encryption.md | 101 +-------
.../guides/mini/guide-generating-sources.md | 6 -
.../markdown/guides/mini/guide-http-settings.md | 150 ++---------
.../guide-large-scale-centralized-deployments.md | 63 +----
content/markdown/guides/mini/guide-manifest.md | 2 -
.../guides/mini/guide-maven-classloading.md | 63 +----
.../markdown/guides/mini/guide-mirror-settings.md | 58 +----
.../guides/mini/guide-multiple-modules-4.md | 2 -
.../markdown/guides/mini/guide-multiple-modules.md | 59 ++---
.../guides/mini/guide-multiple-repositories.md | 24 --
.../guides/mini/guide-naming-conventions.md | 22 +-
.../markdown/guides/mini/guide-new-committers.md | 6 -
content/markdown/guides/mini/guide-proxies.md | 10 -
content/markdown/guides/mini/guide-releasing.md | 90 +------
content/markdown/guides/mini/guide-relocation.md | 36 ---
.../markdown/guides/mini/guide-repository-ssl.md | 41 +--
.../guides/mini/guide-reproducible-builds.md | 65 +----
content/markdown/guides/mini/guide-site.md | 106 ++------
.../markdown/guides/mini/guide-snippet-macro.md | 32 +--
content/markdown/guides/mini/guide-using-ant.md | 6 -
.../markdown/guides/mini/guide-using-extensions.md | 32 +--
.../markdown/guides/mini/guide-using-modello.md | 19 +-
.../mini/guide-using-one-source-directory.md | 56 +----
.../markdown/guides/mini/guide-using-toolchains.md | 25 +-
.../markdown/guides/mini/guide-wagon-providers.md | 20 --
.../guides/plugin/guide-java-plugin-development.md | 33 ++-
.../plugin/guide-java-report-plugin-development.md | 126 ++--------
content/markdown/ide.md | 6 +-
content/markdown/maven-1.x-eol.md | 15 +-
content/markdown/maven-2.x-eol.md | 3 +-
content/markdown/maven-ci-friendly.md | 12 +-
content/markdown/maven-conventions.md | 3 +-
content/markdown/maven-features.md | 28 +--
content/markdown/maven-jsr330.md | 6 +-
content/markdown/maven-logging.md | 6 +-
content/markdown/plugin-developers/common-bugs.md | 109 +-------
.../markdown/plugin-developers/cookbook/index.md | 9 +-
.../cookbook/plexus-plugin-upgrade.md | 33 +--
content/markdown/plugin-developers/index.md | 41 ++-
.../plugin-developers/plugin-documenting.md | 14 +-
.../markdown/plugin-developers/plugin-testing.md | 37 ---
content/markdown/plugins/index.md | 198 ++++++++-------
content/markdown/plugins/localization.md | 72 ++----
content/markdown/privacy-policy.md | 11 +-
content/markdown/project-roles.md | 94 +++----
content/markdown/reference/maven-classloading.md | 7 +-
content/markdown/repositories/artifacts.md | 44 ++--
content/markdown/repositories/index.md | 5 +-
content/markdown/repositories/layout.md | 6 +-
content/markdown/repositories/local.md | 12 +-
content/markdown/repositories/metadata.md | 10 +-
content/markdown/repositories/remote.md | 18 +-
content/markdown/repository-management.md | 15 +-
content/markdown/repository/central-index.md | 17 +-
content/markdown/repository/central-metadata.md | 12 -
.../repository/guide-central-repository-upload.md | 67 +----
content/markdown/run-maven/index.md | 26 +-
content/markdown/run.md | 1 -
content/markdown/security-plexus-archiver.md | 30 ++-
content/markdown/security.md | 30 +--
content/markdown/settings.md | 97 ++++----
content/markdown/shared/index.md | 52 ++--
content/markdown/skins/index.md | 31 +--
content/markdown/support-and-training.md | 15 +-
content/markdown/testimonials.md | 1 -
content/markdown/users/getting-help.md | 40 +--
content/markdown/users/index.md | 20 +-
content/markdown/what-is-maven.md | 25 +-
159 files changed, 1769 insertions(+), 5265 deletions(-)
diff --git a/content/markdown/aether.md b/content/markdown/aether.md
index 8b780131..d3da54c0 100644
--- a/content/markdown/aether.md
+++ b/content/markdown/aether.md
@@ -32,7 +32,7 @@ and through [MNG-6007](https://issues.apache.org/jira/browse/MNG-6007).
|**central groupId**|[org.eclipse.aether](https://repo.maven.apache.org/maven2/org/eclipse/aether/)|[org.apache.maven.resolver](https://repo.maven.apache.org/maven2/org/apache/maven/resolver/)|
|**artifactIds**|aether<br/>aether-api<br/>aether-impl<br/>aether-spi<br/>aether-util<br/>aether-transport-\*|maven-resolver<br/>maven-resolver-api<br/>maven-resolver-impl<br/>maven-resolver-spi<br/>maven-resolver-util<br/>maven-resolver-transport-*|
|**OSGi Bundles**|org.eclipse.aether.api<br/>org.eclipse.aether.impl<br/>org.eclipse.aether....|no OSGi bundles in Apache Maven|
-|**P2 repo**|http://download.eclipse.org/aether/aether-core/releases/<br/>http://download.eclipse.org/aether/maven-aether-provider/releases/|no P2 repo|
+|**P2 repo**|<http://download.eclipse.org/aether/aether-core/releases/<br/>http://download.eclipse.org/aether/maven-aether-provider/releases/|no> P2 repo|
|**API java packages**|org.eclipse.aether...|**Keep packages in Maven 3.x to maintain compatibility for some plugins or extensions using Aether API.**|
|**Impl java packages**|org.eclipse.aether.impl.\*<br/>org.eclipse.aether.internal.\*|Same as API, even if nobody should rely on impl...|
|**SPI java packages**|org.eclipse.aether.spi.\*|Same as API (is it really used outside?)|
diff --git a/content/markdown/archives/maven-2.x/index.md b/content/markdown/archives/maven-2.x/index.md
index ac2b0c27..a636e5d9 100644
--- a/content/markdown/archives/maven-2.x/index.md
+++ b/content/markdown/archives/maven-2.x/index.md
@@ -31,6 +31,6 @@ under the License.
|**Plugin**|**Type***|**Version**|**Last Release Date**|**Description**|**Date of Funeral**|
|---|---|---|---|---|---|
|**Core plugins**||||**Plugins corresponding to default core phases (ie. clean, compile). They may have multiple goals as well.**||
-|[ `reactor`](/plugins/maven-reactor-plugin/)|B|1.0|2008-09-27|Build a subset of interdependent projects in a reactor|2014-03-24|
+|[`reactor`](/plugins/maven-reactor-plugin/)|B|1.0|2008-09-27|Build a subset of interdependent projects in a reactor|2014-03-24|
\* **B**uild or **R**eporting plugin
diff --git a/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md b/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md
index 7c73f05e..dd18a46f 100644
--- a/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md
+++ b/content/markdown/archives/maven-2.x/maven-2.1-architectural-goals.md
@@ -8,7 +8,7 @@ h1. Maven 2.1 -- Jason van Zyl
~~ "License"); you may not use this file except in compliance
~~ with the License. You may obtain a copy of the License at
~~
-~~ http://www.apache.org/licenses/LICENSE-2.0
+~~ <http://www.apache.org/licenses/LICENSE-2.0>
~~
~~ Unless required by applicable law or agreed to in writing,
~~ software distributed under the License is distributed on an
@@ -35,7 +35,7 @@ h2. Architectural Goals
h3. Backward Compatibility
-We must ensure that plugins and reports written against the Maven 2.0.x APIs remain to work in 2.1. We don't want people to have to rewrite
+We must ensure that plugins and reports written against the Maven 2.0.x APIs remain to work in 2.1. We don't want people to have to rewrite
their plugins. There are several plugins that are using the current artifact resolution code that will not be supported (please see the Mercury section below). The
ones that are in our control we can port over to use Mercury, and external users will have to deal with the major version change. Most people will not be affected and
Mercury will be a far better solution.
@@ -75,7 +75,6 @@ So the basic problem we're up against is that there can be core api changes betw
h3. Strategies for ensuring backward compatibility
-
* Plugin integration testing
{code}
@@ -100,7 +99,7 @@ jason: so when you and benjamin went through the tests you have "integration-tes
[08:07am] aheritier: it's too long
[08:07am] jason: a smoke test in one mode
[08:07am] jason: and then turn them all on in hudson
-[08:07am] aheritier: it's why we invented CI servers
+[08:07am] aheritier: it's why we invented CI servers
[08:07am] aheritier: yes
[08:07am] eu left the chat room. (Ping timeout)
[08:08am] jason: i will document the setup but you and ben should figure out the pattern you want for a given plugin test
@@ -141,7 +140,7 @@ jason: so when you and benjamin went through the tests you have "integration-tes
[08:15am] bentmann: Not sure what kind of consistency you actually require
[08:16am] bentmann: The IT profile should be named equal for all of them
[08:16am] bentmann: by inheriting from the parent
-[08:16am] i386_ left the chat room. (i386_)
+[08:16am] i386_left the chat room. (i386_)
[08:16am] bentmann: whether the are run by Invoker or Shitty shouldn't matter, I guess
[08:17am] jason: no, the actual project just needs a profile name the same. not taken from the parent but stated in the project itself
[08:17am] jason: though the parent could specify that profile which just echos "No ITs"
@@ -161,7 +160,7 @@ We just need some way to easy support multiple versions and support mediation be
* Tags: loose categorization people to use to help categorize as they see fit
* Categories: more standard categories that form over time by using category structures that exist or common tags that are used so often they become categories
* Dendency excludes: being to transitively exclude a dependency
-* Properties on dependencies
+* Properties on dependencies
* Specification Dependencies
* Schematron/RelaxNG descriptor for each plugin -- Bryon Jacob proposed a flexible model but XSD is hard to fight here so I'm not sure how far this will go
@@ -176,17 +175,17 @@ h3. Custom Components
As discussed in [Substituting of Custom Components|http://docs.codehaus.org/display/MAVEN/Substitution+of+Custom+Maven+Components] we now have two ways
to insert new components into the system.
-* Using a directory and specifying it in the Classworlds configuration. Tycho simply has a special set of components that load first before the standard maven components and they override
+* Using a directory and specifying it in the Classworlds configuration. Tycho simply has a special set of components that load first before the standard maven components and they override
the standard Maven components. Here's the example based on what Tycho is currently doing which allows custom components to be used.
{code}
-main is org.apache.maven.cli.MavenCli from plexus.core
-
-set maven.home default ${user.home}/m2
-
-[plexus.core]
-load ${maven.home}/tycho/*.jar
-load ${maven.home}/lib/*.jar
+main is org.apache.maven.cli.MavenCli from plexus.core
+
+set maven.home default ${user.home}/m2
+
+[plexus.core]
+load ${maven.home}/tycho/*.jar
+load ${maven.home}/lib/*.jar
{code}
* The embedder has the ContainerCustomizer which allow you to inject new component descriptors. This is used in the IDE integration (m2ecipse, Netbeans) for adding
@@ -204,7 +203,7 @@ Mercury is a replacement for the current Maven Artifact subsystem, and a complet
The primary reasons for replacing the code are that it is unmaintainable and nearly impossible to navigate, it uses completely non-standard structures and libraries for
version calculations, the API is too hard for people to use, and it is not given to users to consume as a single componment to use. Users are forced to know how several
complicated components interact in order to implement a mechanism of retrieving artifacts from a repository. The entire mechanism needs to be replaced with something
-that can be maintained and is reliable.
+that can be maintained and is reliable.
Mercury started as some fixes to Maven Artifact to first help with embeddability and error reporting for IDE integration. This was a direct result of all IDE integrators
having to reimplement the current artifact resolver to provide decent feedback to users when errors occured. The artifact subsystem would just die and leave the IDE in
@@ -214,21 +213,21 @@ behavior, Oleg and I decided to make a break from the old codebase and attempt t
* Find the best people in the world to help create an awesome HTTP and DAV implementation. We did this by talking to Greg, Jan, and Jesse who are the Jetty folks
and there just isn't anyone who knows HTTP better. Greg and Jan are awesome, and Jesse is Maven committer so we have some deep understanding of the issues involved. So
- what Oleg and I wanted to see was:
-** Easy SSL support where mucky with certificates in the default install is not required.
-** Connection pooling
-** Connection parallelization
+ what Oleg and I wanted to see was:
+**Easy SSL support where mucky with certificates in the default install is not required.
+** Connection pooling
+**Connection parallelization
** Built in DAV client support for deployment
-** Atomic retrieval: we make sure absolutely everything is been safely transported to disk before we place it in the local Maven repository
-** Atomic deployment: in this case we could only support this using a special filter Greg created which blocks requests for any artifacts being deploy in the current
- set until the entire set land safely to disk. So it becomes impossible to ask for an artifact that refers to something else in the set before it is actually available.
+**Atomic retrieval: we make sure absolutely everything is been safely transported to disk before we place it in the local Maven repository
+** Atomic deployment: in this case we could only support this using a special filter Greg created which blocks requests for any artifacts being deploy in the current
+ set until the entire set land safely to disk. So it becomes impossible to ask for an artifact that refers to something else in the set before it is actually available.
** Starting thinking about a client that can understand GeoIP. Given the recent spikes in traffic we are going to start needing to distribute the load.
* Find the best solution possible solution for dealing with version calculations, in particular ranges. For this we called on Daniel Le Berre and ask for some help in
integrating his SAT4J library. We learned about the SAT4J library from the P2 project over at Eclipse.org at the last EclipseCon. SAT4J was deemed the best way forward
- by the P2 team in providing the most reliable, and most workable solution for doing version calculation. SAT4J provides ways to plug-in strategies to deal with our
+ by the P2 team in providing the most reliable, and most workable solution for doing version calculation. SAT4J provides ways to plug-in strategies to deal with our
scopes, conflict resolution strategies and it is deadly fast. We felt we are in good company as we can call on Daniel and the P2 team and collaborate when difficult
- problems arise.
+ problems arise.
* Find the best people to help with with security. This might an SSL-based solution to secure the channel where the source is known to be safe, a PGP-based solution where
the contents must be secured assuming a hostile channel, or a combination of the two. To that end I have contacted the folks at the Legion of the Bouncy Castle and asked
@@ -236,22 +235,24 @@ behavior, Oleg and I decided to make a break from the old codebase and attempt t
So in the end I believe it would be detrimental to use the Maven Artifact code in the 2.1.x tree and the change needs to be made to use Mercury before the first alpha ships. Oleg
and I started this work, and Oleg has subsequently worked tirelessly on Mercury along with a great deal of help from Greg, Jan and Jesse. I think Oleg understands the requirements
-as he's seen Maven in action in one of the largest development environments in the world and watched how Maven can fail spectacularly.
+as he's seen Maven in action in one of the largest development environments in the world and watched how Maven can fail spectacularly.
h3. Plugin API
+
* Symmetric output expressions
* Java5 Mojo annotations (Yoav Landman has this working already)
* Clean separation of plugins from reports. It's not good that those are the same thing in the Maven internals.
** Not using concrete XML classes in the Plugin API (Xpp3Dom)
h3. Core Refactorings
+
* Project Builder ([architecture|http://docs.codehaus.org/display/MAVENUSER/Project+Builder])
-** Maven shared model work: a new way of reading in the models for Maven that is not format dependent in any way i.e. XML, text, YAML, scripts, whatever.
+**Maven shared model work: a new way of reading in the models for Maven that is not format dependent in any way i.e. XML, text, YAML, scripts, whatever.
** Pluggable model readers: this could leverage different implementations provided by the shared model work, but we still need a way to detect the type and version
of the model that we want to consume
-** A new terse format that uses attributes
+**A new terse format that uses attributes
** Automatic parent versioning
-** New interpolation component (plexus-interpolation)
+**New interpolation component (plexus-interpolation)
** Dynamic build sections ([MNG-3530|http://jira.codehaus.org/browse/MNG-3530])
** Mixin support -- allowing a paramterizable template which can be imported with one line.
@@ -263,12 +264,12 @@ h3. Core Refactorings
* Have one configuration model for session: session takes the request in the constructor and delegates
* Domain logging
* Plugin Manager
-** Removal of the Plugin Registry (done) -- we moved in a direction where people lock down their versions and we've helped by putting default versions
+**Removal of the Plugin Registry (done) -- we moved in a direction where people lock down their versions and we've helped by putting default versions
in the parent POM.
** Load Plugin dependencies into a separate ClassRealm (done)
** Plugin Execution Environment: Ability to run any version of a plugin where an environment is created which contains all the
requirements for a particular version of the Plugin API
-* Lifecycle Executor
+* Lifecycle Executor
** Queryable Lifecycle
*** The most important change in the embedding environment. You can actually query Maven for the complete execution before it happens. We must know the entire
model of execution before we execute.
@@ -276,15 +277,17 @@ h3. Core Refactorings
h3. Java 5
-Java5 annotations for plugins: we have two implementations that have now been merged in plexus-cdc. QDOX 1.7 has now been released so we may want to check the
+Java5 annotations for plugins: we have two implementations that have now been merged in plexus-cdc. QDOX 1.7 has now been released so we may want to check the
source level gleaning again. Jason Dillon has created a working class processing model. We need to deal with Plexus components and Maven plugins.
-
+
h3. Integration and promotion of scriptable plugins
-
+
h3. Toolchains
+
* Milos has implemented this and Shane had some feedback so this needs to be linked together
h3. Reporting
+
* Report Execution Environment: Ability to run any version of a report where an environment is created which contains all the requirements for a particular version of the Report API.
* Decouple the reporting core. We need to get Doxia out of the core. Anything it needs to run should be isolated.
@@ -315,7 +318,7 @@ or
This test will return false negative for some WAR projects (not added to classpath and don't have any sources to compile). Also, compileSourceRoots and testCompileSourceRoots only become fully populated after running maven build lifecycle, which is expensive.
* Extensions
-** Different categories of extensions: providers vs packaging vs PMD/Checkstyle resources stuff in a JAR
+**Different categories of extensions: providers vs packaging vs PMD/Checkstyle resources stuff in a JAR
** Transparent Extension Loading
-*** Any Wagon or SCM providers should get picked up automatically from SCM and distributionManagement URLs
+***Any Wagon or SCM providers should get picked up automatically from SCM and distributionManagement URLs
*** Any extensions containing packaging/lifecycle related bits needs to be picked up automatically
diff --git a/content/markdown/background/history-of-maven.md b/content/markdown/background/history-of-maven.md
index b160b046..015e9a49 100644
--- a/content/markdown/background/history-of-maven.md
+++ b/content/markdown/background/history-of-maven.md
@@ -1,4 +1,4 @@
-# History of Maven
+# History of Maven
<!--
Licensed to the Apache Software Foundation (ASF) under one
@@ -107,4 +107,4 @@ was written by myself with lots of help from Bob McWhirter
[6]: http://mail-archives.apache.org/mod_mbox/jakarta-alexandria-dev/200202.mbox/%3c20020202153719.50163.qmail@icarus.apache.org%3e
[7]: http://turbine.apache.org/
[8]: http://www.oreillynet.com/pub/a/network/2005/08/30/ruby-rails-david-heinemeier-hansson.html
-[9]: http://www.ibiblio.org
\ No newline at end of file
+[9]: http://www.ibiblio.org
diff --git a/content/markdown/background/philosophy-of-maven.md b/content/markdown/background/philosophy-of-maven.md
index 919a33f0..1c2d7437 100644
--- a/content/markdown/background/philosophy-of-maven.md
+++ b/content/markdown/background/philosophy-of-maven.md
@@ -1,4 +1,4 @@
-# Philosophy of Maven
+# Philosophy of Maven
<!--
Licensed to the Apache Software Foundation (ASF) under one
diff --git a/content/markdown/code-quality-management.md b/content/markdown/code-quality-management.md
index 76fd15ac..2b45082e 100644
--- a/content/markdown/code-quality-management.md
+++ b/content/markdown/code-quality-management.md
@@ -27,11 +27,11 @@ this information to offer enhanced quality management functionalities.
Following is an alphabetical list of those we've heard mentioned around
the Maven community:
-- [Hudson](https://hudson-ci.org)
-- [Jenkins](https://jenkins-ci.org)
-- [SonarQube](http://www.sonarqube.org/)
-- [Squale](http://www.squale.org/)
-- [XRadar](http://xradar.sourceforge.net)
+- [Hudson](https://hudson-ci.org)
+- [Jenkins](https://jenkins-ci.org)
+- [SonarQube](http://www.sonarqube.org/)
+- [Squale](http://www.squale.org/)
+- [XRadar](http://xradar.sourceforge.net)
[PMD]: https://maven.apache.org/plugins/maven-pmd-plugin/
[Checkstyle]: https://maven.apache.org/plugins/maven-checkstyle-plugin/
diff --git a/content/markdown/configure.md b/content/markdown/configure.md
index aaf782b9..7eb897fe 100644
--- a/content/markdown/configure.md
+++ b/content/markdown/configure.md
@@ -17,39 +17,39 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
-The configuration for Apache Maven usage itself and projects built with resides
-in a number of places:
+The configuration for Apache Maven usage itself and projects built with resides
+in a number of places:
-## `MAVEN_OPTS` environment variable:
+## `MAVEN_OPTS` environment variable
This variable contains parameters used to start up the JVM running Maven and
can be used to supply additional options to it. E.g. JVM memory
settings could be defined with the value `-Xms256m -Xmx512m`.
-## `MAVEN_ARGS` environment variable:
+## `MAVEN_ARGS` environment variable
Starting with Maven 3.9.0, this variable contains arguments passed to Maven before
CLI arguments. E.g., options and goals could be defined with the value
`-B -V checkstyle:checkstyle`.
-## `settings.xml` file:
+## `settings.xml` file
Located in USER_HOME/.m2 the settings files is designed to contain any
configuration for Maven usage across projects.
-## `.mvn` directory:
+## `.mvn` directory
Located within the project's top level directory, the files `maven.config`, `jvm.config`, and `extensions.xml`
contain project specific configuration for running Maven.
This directory is part of the project and may be checked in into your version control.
-### `.mvn/extensions.xml` file:
+### `.mvn/extensions.xml` file
-The old way (up to Maven 3.2.5) was to create a jar (must be shaded if you have other dependencies) which contains the extension and put
+The old way (up to Maven 3.2.5) was to create a jar (must be shaded if you have other dependencies) which contains the extension and put
it manually into the `${MAVEN_HOME}/lib/ext` directory. This means you had to change the Maven installation. The consequence was that everyone
-who likes to use this needed to change it’s installation and makes the on-boarding for a developer much more inconvenient. The other
-option was to give the path to the jar on command line via `mvn -Dmaven.ext.class.path=extension.jar`. This has the drawback giving those
+who likes to use this needed to change it’s installation and makes the on-boarding for a developer much more inconvenient. The other
+option was to give the path to the jar on command line via `mvn -Dmaven.ext.class.path=extension.jar`. This has the drawback giving those
options to your Maven build every time you are calling Maven. Not very convenient as well.
From now on this can be done much more simpler and in a more Maven like way. So you can define an `${maven.projectBasedir}/.mvn/extensions.xml` file which looks like the following:
@@ -67,15 +67,15 @@ From now on this can be done much more simpler and in a more Maven like way. So
Now you can simply use an extension by defining the usual maven coordinates groupId, artifactId, version as any other artifact. Furthermore all transitive dependencies of those extensions will automatically being downloaded from your repository. So no need to create a shaded artifact anymore.
-### `.mvn/maven.config` file:
+### `.mvn/maven.config` file
-It’s really hard to define a general set of options for calling the maven command line. Starting with Maven 3.3.1+, this can be solved by
-putting this
-options to a script but this can now simple being done by defining `${maven.projectBasedir}/.mvn/maven.config` file which contains the
-configuration options for the `mvn` command line.
+It’s really hard to define a general set of options for calling the maven command line. Starting with Maven 3.3.1+, this can be solved by
+putting this
+options to a script but this can now simple being done by defining `${maven.projectBasedir}/.mvn/maven.config` file which contains the
+configuration options for the `mvn` command line.
-For example things like `-T3 -U --fail-at-end`. So you only have to call Maven just by using `mvn
-clean package` instead of `mvn -T3 -U --fail-at-end clean package` and not to miss the `-T3 -U --fail-at-end` options on every call.
+For example things like `-T3 -U --fail-at-end`. So you only have to call Maven just by using `mvn
+clean package` instead of `mvn -T3 -U --fail-at-end clean package` and not to miss the `-T3 -U --fail-at-end` options on every call.
The `${maven.projectBasedir}/.mvn/maven.config` is located in the `${maven.projectBasedir}/.mvn/` directory; also works if in the root of a multi module build.
**NOTICE** starting with Maven **3.9.0** each single argument must be put in new line, so for the mentioned example your file will have content like:
@@ -86,7 +86,7 @@ The `${maven.projectBasedir}/.mvn/maven.config` is located in the `${maven.proje
--fail-at-end
```
-### `.mvn/jvm.config` file:
+### `.mvn/jvm.config` file
Starting with Maven 3.3.1+ you can define JVM configuration via `${maven.projectBasedir}/.mvn/jvm.config` file which means you can define the options for your build on a per project base. This file will become part of your project and will be checked in along with your project. So no need anymore for `MAVEN_OPTS`, `.mavenrc` files. So for example if you put the following JVM options into the `${maven.projectBasedir}/.mvn/jvm.config` file
diff --git a/content/markdown/developers/committer-environment.md b/content/markdown/developers/committer-environment.md
index b933c92b..52719085 100644
--- a/content/markdown/developers/committer-environment.md
+++ b/content/markdown/developers/committer-environment.md
@@ -23,38 +23,22 @@ under the License.
## Committer Environment
-
### Introduction
-
This document describes how to set up the Maven committer environment.
-
-
### Source File Encoding
-
When editing source files, make sure you use the right file encoding. For the Maven project, UTF-8 has been chosen as the default file encoding. UTF-8 is an encoding scheme for the Unicode character set that can encode all characters that Java can handle. The source files should not contain the byte order mark (BOM). There are exceptions to this general rule. For instance, properties files are encoded using ISO-8859-1 as per the JRE API, so please keep this in mind, too.
-
-
### Maven Code Style
-
Refer to [Maven Code Style And Code Conventions](./conventions/code.html)
-
-
### Useful software
-
The Maven Team uses assorted software. Here is a partial list:
+- [Cygwin](https://www.cygwin.com/): collection of free software tools that allow various versions of Microsoft Windows to act somewhat like a Unix system
-
- - [Cygwin](https://www.cygwin.com/): collection of free software tools that allow various versions of Microsoft Windows to act somewhat like a Unix system
-
- - [GnuPG](https://www.gnupg.org/): GNU Privacy Guard.
-
-
-
+- [GnuPG](https://www.gnupg.org/): GNU Privacy Guard.
diff --git a/content/markdown/developers/committer-settings.md b/content/markdown/developers/committer-settings.md
index d979a678..54d00842 100644
--- a/content/markdown/developers/committer-settings.md
+++ b/content/markdown/developers/committer-settings.md
@@ -23,19 +23,13 @@ under the License.
## Introduction
-
This document is intended to set up the Maven committer settings, i.e. the `${user.home}/.m2/settings.xml`.
-
### Enable Apache Servers
-
Maven uses several servers configuration to deploy snapshots and releases on the Apache servers. You need to tell to Maven what your Apache username is.
-
- **It is highly recommended to use Maven's [ password encryption capabilities](../guides/mini/guide-encryption.html) for your passwords**.
-
-
+ **It is highly recommended to use Maven's [password encryption capabilities](../guides/mini/guide-encryption.html) for your passwords**.
```
<settings>
@@ -58,14 +52,10 @@ under the License.
</settings>
```
-
### Enable sending announcement e-mails
-
To be able to send out announcements of Maven releases you need to add a couple of properties to the `apache-release` profile.
-
-
```
<settings>
...
@@ -81,5 +71,3 @@ under the License.
</profiles>
</settings>
```
-
-
diff --git a/content/markdown/developers/compatibility-plan.md b/content/markdown/developers/compatibility-plan.md
index 37d42df5..e8220330 100644
--- a/content/markdown/developers/compatibility-plan.md
+++ b/content/markdown/developers/compatibility-plan.md
@@ -23,62 +23,42 @@ under the License.
## Maven Plugins Compatibility Plan
-
### Scope
-
This page describes the system requirements plan, which consists of:
-
-
1 minimum **Java** runtime prerequisite for Maven plugins, which can be extended to shared components,
1 minimum **Maven** runtime prerequisite for plugins.
-
Such requirements are displayed as "System Requirements" in every plugin info report (see [this example](/plugins/maven-clean-plugin/plugin-info.html)).
-
Consolidated view for all LATEST plugins release is visible in a [daily generated report](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html).
-
-
### Maven Plan
+- Until 2012, Maven 2.2.1 + Java 5 prerequisites, with plugins versions in 2.x
+- Since 2012, Maven 3.0 + Java 7 prerequisites, with plugins in 3.x.y
- - Until 2012, Maven 2.2.1 + Java 5 prerequisites, with plugins versions in 2.x
-
- - Since 2012, Maven 3.0 + Java 7 prerequisites, with plugins in 3.x.y
-
- - Since June 2020, Maven Plugin API used by plugins >= 3.1.0 + Java 8 prerequisites [Technical details](https://s.apache.org/MVN-PLUGIN-MIGRATION-3.1)
-
-
+- Since June 2020, Maven Plugin API used by plugins >= 3.1.0 + Java 8 prerequisites [Technical details](https://s.apache.org/MVN-PLUGIN-MIGRATION-3.1)
### Context
+- Maven core history with Java prerequisite is available in the [release notes](/docs/history.html)
+- JDK/JRE availability dates:
- - Maven core history with Java prerequisite is available in the [release notes](/docs/history.html)
-
- - JDK/JRE availability dates:
-
- - Java 5 (2004) is closed source, End of Public Update in 2009
-
- - Java 6 (2006) is Open Source, maintained at OpenJDK until 2018
+- Java 5 (2004) is closed source, End of Public Update in 2009
- - Java 7 (2011) is Open Source, maintained [at OpenJDK](https://wiki.openjdk.java.net/display/jdk7u) at least until June 2020
+- Java 6 (2006) is Open Source, maintained at OpenJDK until 2018
- - Java 8 (2014) is Open Source, maintained [at OpenJDK](https://wiki.openjdk.java.net/display/jdk8u) at least until September 2023
+- Java 7 (2011) is Open Source, maintained [at OpenJDK](https://wiki.openjdk.java.net/display/jdk7u) at least until June 2020
- - Java 11 (LTS, 2018) is Open Source, maintained [at OpenJDK](https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u) at least until September 2025
+- Java 8 (2014) is Open Source, maintained [at OpenJDK](https://wiki.openjdk.java.net/display/jdk8u) at least until September 2023
- - see [Java Version Almanac](https://javaalmanac.io/jdk/) for updated JDK releases
+- Java 11 (LTS, 2018) is Open Source, maintained [at OpenJDK](https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u) at least until September 2025
+- see [Java Version Almanac](https://javaalmanac.io/jdk/) for updated JDK releases
see also [Java Is Still Free](https://docs.google.com/document/d/1nFGazvrCvHMZJgFstlbzoHjpAVwv5DEdnaBr_5pKuHo) for more details
-
-
-
-
-
diff --git a/content/markdown/developers/conventions/code.md b/content/markdown/developers/conventions/code.md
index b67457fd..3f96f8a9 100644
--- a/content/markdown/developers/conventions/code.md
+++ b/content/markdown/developers/conventions/code.md
@@ -26,139 +26,99 @@ under the License.
As the formatting is automatically enforced or even applied with [spotless-maven-plugin](https://github.com/diffplug/spotless/tree/main/plugin-maven) for all projects using [Maven Project Parent POM 38 or newer](/pom/maven/index.html) developers usually don't need to care and the following sections are just for informational purposes.
-
Optionally you can still import the code style formatter for your IDE from [shared-resources](https://gitbox.apache.org/repos/asf?p=maven-shared-resources.git;a=tree;f=src/main/resources/config;hb=HEAD)
+- [Generic Code Style And Convention](#generic-code-style-and-convention)
- - [Generic Code Style And Convention](#generic-code-style-and-convention)
-
- - [Java](#java)
-
- - [Java Code Style](#java-code-style)
-
- - [Java Code Convention](#java-code-convention)
-
- - [Java Code Convention - import layouts](#java-code-convention---import-layouts)
+- [Java](#java)
- - [JavaDoc Convention](#javadoc-convention)
+- [Java Code Style](#java-code-style)
+- [Java Code Convention](#java-code-convention)
+- [Java Code Convention - import layouts](#java-code-convention---import-layouts)
- - [XML](#xml)
+- [JavaDoc Convention](#javadoc-convention)
- - [XML Code Style](#xml-code-style)
+- [XML](#xml)
- - [Generic XML Code Convention](#generic-xml-code-convention)
+- [XML Code Style](#xml-code-style)
- - [POM Code Convention](#pom-code-convention)
-
- - [XDOC Code Convention](#xdoc-code-convention)
-
- - [FML Code Convention](#fml-code-convention)
+- [Generic XML Code Convention](#generic-xml-code-convention)
+- [POM Code Convention](#pom-code-convention)
+- [XDOC Code Convention](#xdoc-code-convention)
+- [FML Code Convention](#fml-code-convention)
### Generic Code Style And Convention
-
All working files (java, xml, others) should respect the following conventions:
+- **License Header**: Always add the current [ASF license header](https://www.apache.org/legal/src-headers.html#headers) in all files checked into the source code repository.
-
- - **License Header**: Always add the current [ASF license header](https://www.apache.org/legal/src-headers.html#headers) in all files checked into the source code repository.
-
- - **Trailing Whitespace**: No trailing whitespaces allowed.
-
+- **Trailing Whitespace**: No trailing whitespaces allowed.
and the following style:
+- **Indentation**: **Never** use tabs!
-
- - **Indentation**: **Never** use tabs!
-
- - **Line wrapping**: Always use a 120-column line width.
-
+- **Line wrapping**: Always use a 120-column line width.
**Note**: The specific styles and conventions, listed in the next sections, can override these generic rules.
-
-
### Java
-
#### Java Code Style
-
Maven adopts the [palantir Java format](https://github.com/palantir/palantir-java-format).
-
-
#### Java Code Convention
-
For consistency reasons, our Java code convention is mainly:
+- **Naming**: Constants (i.e. static final members) should always be in upper case. Use short, descriptive names for classes and methods.
+- **Organization**: Avoid using public inner classes. Prefer interfaces instead of default implementation.
- - **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.
+- **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.
+- **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.\***
- - import **javax.\***
-
- - import **java.\***
-
- - blank line
-
- - import **all other imports**
+- 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 `[maven-eclipse-importorder.txt](https://gitbox.apache.org/repos/asf?p=maven-shared-resources.git;a=blob_plain;f=src/main/resources/config/maven-eclipse-importorder.txt;hb=HEAD)`, select _Window \> Preferences_ and navigate to _Java \> Code Style \> Organize Imports_. Click on _Import..._ and select the downloaded file to change the import order.
-
-
#### JavaDoc Convention
-
TO BE DISCUSSED
-
-
-
### XML
-
#### XML Code Style
-
The Maven style for XML files is mainly:
+- **Indentation**: Always use 2 space indents, unless you're wrapping a new XML tags line in which case you should indent 4 spaces.
-
- - **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:
+- **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>
@@ -170,46 +130,30 @@ under the License.
</aTag>
```
-
In some cases, adding comments could improve the readability of blocks, for instance:
-
-
```
<!-- Simple XML documentation -->
```
-
or
-
-
```
<!-- ====================================================================== -->
<!-- Block documentation -->
<!-- ====================================================================== -->
```
-
-
-
#### Generic XML Code Convention
-
No generic code convention exists yet for XML files.
-
-
#### POM Code Convention
-
The team has [voted](https://lists.apache.org/thread/h8px5t6f3q59cnkzpj1t02wsoynr3ygk) during the end of June 2008 to follow a specific POM convention to ordering POM elements. The consequence of this vote is that the [Maven project descriptor](https://maven.apache.org/ref/current/maven-model/maven.html) is **no more** considered as the reference for the ordering.
-
The following is the recommended ordering for all Maven POM files:
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion/>
@@ -260,39 +204,24 @@ under the License.
**Comments**:
-
-
1 The `<project>` element is always on one line.
1 The blocks are voluntary separated by a new line to improve the readiness.
1 The dependencies in `<dependencies>` and `<dependencyManagement>` tags have no specific ordering. Developers are free to choose the ordering, but grouping dependencies by topics (like groupId i.e. `org.apache.maven`) is a good practice.
-
-
#### XDOC Code Convention
-
For consistency and readability reasons, XDOC files should respect:
+- **Metadata**: Always specify metadata in the `<properties>` tag.
-
- - **Metadata**: Always specify metadata in the `<properties>` tag.
-
- - **Sections**: Always use a new line with indentation for `<section>` tags.
-
-
+- **Sections**: Always use a new line with indentation for `<section>` tags.
#### FML Code Convention
-
For readability reasons, FML files should respect:
-
-
- - **FAQ**: Always use a new line with indentation for `<faq>` tags.
-
+- **FAQ**: Always use a new line with indentation for `<faq>` tags.
<!-- * {APT} Do we need any specific APT style/convention? -->
-
-
diff --git a/content/markdown/developers/conventions/git.md b/content/markdown/developers/conventions/git.md
index de40447b..ef568786 100644
--- a/content/markdown/developers/conventions/git.md
+++ b/content/markdown/developers/conventions/git.md
@@ -23,23 +23,16 @@ under the License.
## Maven Git Convention
-
- This document describes how developers should use Git.
-
+ This document describes how developers should use Git.
### Git Configuration
-
#### For contributors who are not committers
-
Apache git repositories are at _git://git.apache.org_. However, the ASF uses clones on github.com to make it easier for people to contribute changes via pull requests.
-
To contribute to a Maven component that is maintained in git, please follow these steps:
-
-
1 create a JIRA for bug or improvement that you wish to work on. The Maven project uses JIRA to organize and track our work, and in particular to keep track of which changes are included in which releases.
1 Make a fork of the official ASF clone from github.com. For example, `https://github.com/apache/maven-scm`.
@@ -50,24 +43,16 @@ under the License.
1 Make a pull request to pull your changes to the official clone. Add a link to your pull request to the JIRA. Committers will take it from here.
-
-
#### For committers
-
Committers may, of course, commit directly to the ASF repositories. For complex changes, you may find it valuable to make a pull request at github to make it easier to collaborate with others.
-
##### Commit Message Template
-
Commits should be focused on one issue at a time, because that makes it easier for others to review the commit.
-
A commit message should use this template:
-
-
```
[ISSUE-1] <<Summary field from JIRA>>
Submitted by: <<Name of non-committer>>
@@ -77,19 +62,14 @@ 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.
- - **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.
-
+- **Comments** some optional words about the solution.
eg:
-
-
```
[MNG-1456] Added the foo to the bar
Submitted by: Baz Bazman
@@ -97,46 +77,30 @@ Submitted by: Baz Bazman
o Applied without change
```
-
-
-
### Apply User Patch
-
To keep the history of contributions clear, The committer should usually apply the patch without any **major** modifications, and then create his or her own commits for further modifications. However, committers should never commit code to a live branch which is not suitable to release. If a contribution requires significant work to make it useful, commit it to a branch, fix it up, and merge the branch.
-
If the user created a pull request, the committer is responsible for closing that pull request. You do this by adding a note to a commit message:
-
-
```
Closes #NNN.
```
where NNN is the number of the pull request.
-
-
### Edit Commit Message
-
to edit last commit comment:
-
-
```
-$ git commit --amend -m "new comment"
+git commit --amend -m "new comment"
```
-
### Workflow
-
Workflow for svn folks is something like :
-
-
```
$ git pull
$ hack hack hack
@@ -149,8 +113,6 @@ $ git commit --amend -m "new comment"
A more quiet workflow :
-
-
```
$ git pull
$ hack hack hack
@@ -163,34 +125,24 @@ $ git rebase origin/master
$ git push
```
-
### Other useful Git commands while developing
-
If you've done a chunk of work and you would like to ditch your changes and start from scratch use this command to revert to the original checkout:
-
-
```
-$ git checkout .
+git checkout .
```
TODO .gitignore
-
#### power-git checkout
-
This checkout is typical for highly experienced git users, and may serve as inspiration for others; as usual the best way to learn is by doing. Sample shown for maven-surefire
-
- Go to https://github.com/apache/maven-surefire and fork surefire to your own github account.
-
+ Go to <https://github.com/apache/maven-surefire> and fork surefire to your own github account.
Starting with nothing (no existing clone)
-
-
```
git clone https://github.com/<youraccount>/maven-surefire.git
git remote add apache https://git-wip-us.apache.org/repos/asf/maven-surefire.git
@@ -201,25 +153,18 @@ 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
@@ -227,11 +172,8 @@ 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
@@ -239,14 +181,9 @@ git push apache # upload to apache
Or if you're comfortable with rebasing;
-
-
```
git checkout pr/10
git rebase apache/master
git push apache
```
-
-
-
diff --git a/content/markdown/developers/conventions/jira.md b/content/markdown/developers/conventions/jira.md
index 30f7ea1d..8b1b9b9b 100644
--- a/content/markdown/developers/conventions/jira.md
+++ b/content/markdown/developers/conventions/jira.md
@@ -73,4 +73,4 @@ The Maven team doesn't use this. Committers can if it helps them.
- [JIRA Documentation](https://confluence.atlassian.com/jira064/jira-documentation-720411693.html)
- [What is an Issue?](https://confluence.atlassian.com/jira064/what-is-an-issue-720416138.html)
-- [What is a project?](https://confluence.atlassian.com/jira064/what-is-a-project-720416135.html)
\ No newline at end of file
+- [What is a project?](https://confluence.atlassian.com/jira064/what-is-a-project-720416135.html)
diff --git a/content/markdown/developers/dependency-policies.md b/content/markdown/developers/dependency-policies.md
index 064a45ff..7625546d 100644
--- a/content/markdown/developers/dependency-policies.md
+++ b/content/markdown/developers/dependency-policies.md
@@ -23,60 +23,36 @@ under the License.
## Maven Dependency Policies
-
### Scope
-
This page describes the policies around the use of dependencies by the Apache Maven Developers in the process of developing Apache Maven itself.
-
This page does not apply to projects hosted outside of the Apache Maven project. In order to remove all doubt, this page only applies to code which has a Github URL that starts with `https://github.com/apache/maven` or a Gitbox URL starting with `https://gitbox.apache.org/repos/asf?p=maven`
-
If you have stumbled across this page and you are working on code that does not have a Github URL starting with `https://github.com/apache/maven` then this page does not apply to you.
-
-
### Background
-
The Apache Maven PMC is tasked with ensuring (among other things) that all legal issues are addressed and that each and every release is the product of the community as a whole.
-
The Apache Maven project consists of quite a number of components. For the purposes of this policy, we will make a distinction between the core Maven distribution and all the other components.
-
- The core Maven distribution is the binary and source distributions made available from the https://maven.apache.org/download page.
-
-
+ The core Maven distribution is the binary and source distributions made available from the <https://maven.apache.org/download> page.
### Applicability
-
This policy applies to all changes to dependencies as and from Subversion revision 1067464.
-
-
### Core Maven Distribution Dependencies
-
All dependencies which are included in the Core Maven Distribution must either:
+- be licensed under a [Category A license](https://www.apache.org/legal/resolved.html#category-a); or
-
- - be licensed under a [Category A license](https://www.apache.org/legal/resolved.html#category-a); or
-
- - be licensed under a [Category B license](https://www.apache.org/legal/resolved.html#category-b) and approved by a majority vote of the Apache Maven PMC.
-
+- be licensed under a [Category B license](https://www.apache.org/legal/resolved.html#category-b) and approved by a majority vote of the Apache Maven PMC.
Votes for Category B licenses will be held on the dev@maven.apache.org mailing list. A majority of the PMC must vote in favour of a Category B licensed dependency before a release can be made containing that dependency.
-
-
### Non-Core Dependencies
-
Non-Core components may only use Category A or Category B licenses.
-
-
-
diff --git a/content/markdown/developers/index.md b/content/markdown/developers/index.md
index 32526fe3..cb7ac499 100644
--- a/content/markdown/developers/index.md
+++ b/content/markdown/developers/index.md
@@ -23,103 +23,72 @@ under the License.
## Maven Developer Centre
-
This documentation centre is for people who are Maven developers, or would like to contribute.
-
If you cannot find your answers here, feel free to ask the [Maven Developer List](mailto:dev@maven.apache.org).
-
### Contributors Resources
+- [Guide to helping with Maven](../guides/development/guide-helping.html)
+- [Developing Maven](../guides/development/guide-maven-development.html)
- - [Guide to helping with Maven](../guides/development/guide-helping.html)
-
- - [Developing Maven](../guides/development/guide-maven-development.html)
+- [Building Maven](../guides/development/guide-building-maven.html)
- - [Building Maven](../guides/development/guide-building-maven.html)
+- [Source Code](../scm.html)
- - [Source Code](../scm.html)
-
- - [Continuous Integration](https://ci-maven.apache.org/job/Maven/job/maven-box/)
-
- - [Common Bugs and Pitfalls](../plugin-developers/common-bugs.html)
-
- - [Apache Maven Project Roles](../project-roles.html)
+- [Continuous Integration](https://ci-maven.apache.org/job/Maven/job/maven-box/)
+- [Common Bugs and Pitfalls](../plugin-developers/common-bugs.html)
+- [Apache Maven Project Roles](../project-roles.html)
### Committers Resources
-
#### General Resources
+- [Guide for new Maven committers](./welcome-to-new-committers.html)
+- [Committer Environment](./committer-environment.html)
- - [Guide for new Maven committers](./welcome-to-new-committers.html)
+- [Committer Settings](./committer-settings.html)
- - [Committer Environment](./committer-environment.html)
-
- - [Committer Settings](./committer-settings.html)
-
- - [Retirement Plan for Plugins](./retirement-plan-plugins.html)
-
- - [Maven Dependency Policies](./dependency-policies.html)
-
- - [Maven Plugins and Components Compatibility Plan](./compatibility-plan.html)
-
- - [Maven Proposals/Backlog](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567)
+- [Retirement Plan for Plugins](./retirement-plan-plugins.html)
+- [Maven Dependency Policies](./dependency-policies.html)
+- [Maven Plugins and Components Compatibility Plan](./compatibility-plan.html)
+- [Maven Proposals/Backlog](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567)
### Developers Conventions
-
There are a number of conventions used in the Maven projects, which contributors and developers alike should follow for consistency's sake.
+- [Maven Code Style And Conventions](./conventions/code.html)
+- [Maven JIRA Convention](./conventions/jira.html)
- - [Maven Code Style And Conventions](./conventions/code.html)
-
- - [Maven JIRA Convention](./conventions/jira.html)
-
- - [Maven Git Convention](./conventions/git.html)
-
+- [Maven Git Convention](./conventions/git.html)
**Note**: If you cannot find your answers here, feel free to ask the [Maven Developer List](mailto:dev@maven.apache.org).
-
-
### Making Releases
+- [Making GPG Keys](./release/pmc-gpg-keys.html)
-
- - [Making GPG Keys](./release/pmc-gpg-keys.html)
-
- - [Release Process](./release/index.html)
-
-
+- [Release Process](./release/index.html)
### Maven Website
-
-
- - [Deploy Maven Website](./website/index.html)
-
-
+- [Deploy Maven Website](./website/index.html)
### Other Resources
+- [ASF Development Infrastructure Information](https://www.apache.org/dev/)
-
- - [ASF Development Infrastructure Information](https://www.apache.org/dev/)
-
- - [About the Apache Software Foundation](https://www.apache.org/foundation/)
-
+- [About the Apache Software Foundation](https://www.apache.org/foundation/)
<!-- TODO: tasks as buttons? -->
<!-- TODO: de-dupe with existing documents in community -->
<!-- TODO: clean up, have cookbook with more in depth documents like cutting releases, etc. -->
-
diff --git a/content/markdown/developers/release/index.md b/content/markdown/developers/release/index.md
index 083735d3..c001ef96 100644
--- a/content/markdown/developers/release/index.md
+++ b/content/markdown/developers/release/index.md
@@ -23,25 +23,17 @@ under the License.
## Releasing A Maven Project
-
What follows is a description of releasing a Maven project to a staging repository and its documentation, whereupon it is scrutinized by the community, approved, and transferred to a production repository.
-
The steps involved are similar for any Apache project, with more specifics for parent POMs and Maven itself. The steps involved, and the relevant documents for each, are listed below.
-
<!-- nothing specific: normal component * {{{./maven-plugin-release.html} Releasing a Maven plugin project}} -->
<!-- nothing specific: normal component * {{{./maven-shared-release.html} Releasing a Maven shared component or subproject}} -->
- - [ Releasing Maven Core](./maven-core-release.html)
-
- - [ Releasing a parent POM](./parent-pom-release.html)
+- [Releasing Maven Core](./maven-core-release.html)
+- [Releasing a parent POM](./parent-pom-release.html)
The above links all provide specific information for those types of releases, but they all refer back to the common documentation:
-
-
- - [ Maven Project Common Release procedure](./maven-project-release-procedure.html)
-
-
+- [Maven Project Common Release procedure](./maven-project-release-procedure.html)
diff --git a/content/markdown/developers/release/maven-core-release.md b/content/markdown/developers/release/maven-core-release.md
index 70b772bd..4e3fedaa 100644
--- a/content/markdown/developers/release/maven-core-release.md
+++ b/content/markdown/developers/release/maven-core-release.md
@@ -51,13 +51,13 @@ with 3.2.5.
For non-alpha/beta releases, release candidates are produced before the actual release.
-Checkout https://dist.apache.org/repos/dist/dev/maven/maven-3 then create the necessary directory tree.
+Checkout <https://dist.apache.org/repos/dist/dev/maven/maven-3> then create the necessary directory tree.
Copy the binaries and src-tar.gz with their sha512/asc to the created directories.
To produce a release candidate, follow the first seven steps only from the following procedure:
-- [Maven Project Common Release Procedure](./maven-project-release-procedure.html)
+- [Maven Project Common Release Procedure](./maven-project-release-procedure.html)
The version used should be the eventual version with -RC1, -RC2, etc. appended.
@@ -71,7 +71,7 @@ Once happy with a release candidate, the full release is performed, with the fin
To produce a final release, the same process as for standard projects is followed:
-- [Maven Project Common Release Procedure](./maven-project-release-procedure.html)
+- [Maven Project Common Release Procedure](./maven-project-release-procedure.html)
Below describes the additional steps that need to be taken at the points where the website are updated in those instructions.
@@ -151,4 +151,3 @@ Next, any superseded releases should be removed from the above locations (after
#### Proceed with Announcement
You can now proceed with the steps outlined after deploying the website on [Maven Project Common Release Procedure](./maven-project-release-procedure.html)
-
diff --git a/content/markdown/developers/release/maven-project-release-procedure.md b/content/markdown/developers/release/maven-project-release-procedure.md
index 8709bbc2..91df9d3c 100644
--- a/content/markdown/developers/release/maven-project-release-procedure.md
+++ b/content/markdown/developers/release/maven-project-release-procedure.md
@@ -22,78 +22,52 @@ under the License.
-->
## Performing a Maven Project Release
-
This document covers the common release procedures used by the Maven team to perform releases.
-
### Prerequisites
-
Be sure that:
+- you have a recent Git client installed and on your shell's path.
+- you have JDK 8 installed and on your shell's path to build Maven 3.7.0+. Details about minimum JDK version to build an appropriate version can be found here: [https://maven.apache.org/docs/history.html](/docs/history.html)
- - you have a recent Git client installed and on your shell's path.
-
- - you have JDK 8 installed and on your shell's path to build Maven 3.7.0+. Details about minimum JDK version to build an appropriate version can be found here: [https://maven.apache.org/docs/history.html](/docs/history.html)
-
- - if you receive an OutOfMemoryError during the build, make sure to have set the environment variable `MAVEN_OPTS=-Xmx512m`
-
- - you must use Maven 3.3.9+.
-
- - follow Apache environment configuration steps outlined at: [Publishing Maven Artifacts](https://www.apache.org/dev/publishing-maven-artifacts.html#dev-env).
+- if you receive an OutOfMemoryError during the build, make sure to have set the environment variable `MAVEN_OPTS=-Xmx512m`
+- you must use Maven 3.3.9+.
+- follow Apache environment configuration steps outlined at: [Publishing Maven Artifacts](https://www.apache.org/dev/publishing-maven-artifacts.html#dev-env).
### Before you begin
-
If you started here, you may first want to review one of the following documents that cover the specifics of various types of releases we have in the Maven Project:
+- [Releasing Maven Core](./maven-core-release.html)
-
- - [ Releasing Maven Core](./maven-core-release.html)
-
- - [ Releasing a parent POM](./parent-pom-release.html)
-
-
+- [Releasing a parent POM](./parent-pom-release.html)
### Consider updating the parent versions
-
If the item you are planning to release is not using the most recent version of its parent (see [parent POMs](../../pom/) index), consider taking this opportunity to update to it.
-
-
### Make sure that site compilation works
-
Particularly if you update the parent or if you updated your javadoc, the site compilation process may fail, or reveal a conspicuous error. It is stressful and time-consuming to discover this \*after\* you stage a release and then try to follow the procedure to deploy the site for review. So you may find it more pleasant to check out the state of the site before you start:
-
-
```
mvn -Preporting site site:stage
```
-
### Stage the Release
-
-
- 1 Follow the release preparation, staging and closing the repository steps outlined in [Publishing Maven Releases](https://infra.apache.org/publishing-maven-artifacts.html).
+ 1 Follow the release preparation, staging and closing the repository steps outlined in [Publishing Maven Releases](https://infra.apache.org/publishing-maven-artifacts.html).
1 Stage the latest documentation as explained in [deploying Maven components reference documentation](../website/deploy-component-reference-documentation.html).
-
-
### Call the vote
-
Propose a vote on the dev list with the closed issues, the issues left, the staging repository and the staging site. For instance:
-
-
```
To: "Maven Developers List" <de...@maven.apache.org>
Subject: [VOTE] Release Apache Maven XXX Plugin version Y.Z
@@ -129,21 +103,14 @@ Vote open for at least 72 hours.
To get the JIRA release notes link, browse to the plugin's or component's JIRA page, select the _Road Map_ link, and use the link to _Release Notes_ that is next to the version being released.
-
To get the list of issues left in JIRA, browse to the plugin's or component's JIRA page, and from the _Preset Filters_ on the right, use the link for _Outstanding_ issues.
-
The vote is open for at least 72 hours means, that you need to wait at least 72 hours before proceeding. This gives others time to test your release and check that everything is good. If you have received after that not enough +1 votes to reach the quorum, this doesn't mean, the vote failed. It just takes a bit longer.
-
-
### Check the vote results
-
Copied from [Votes on Package Releases](https://www.apache.org/foundation/voting.html#ReleaseVotes).
-
-
```
Votes on whether a package is ready to be released use majority approval
-- i.e. at least three PMC members must vote affirmatively for release,
@@ -156,14 +123,10 @@ but the 'minimum quorum of three +1 votes' rule is universal.
The list of PMC members is available at [https://people.apache.org/committers-by-project.html#maven-pmc](https://people.apache.org/committers-by-project.html#maven-pmc).
-
#### Successful vote
-
Once a vote is **successful**, post the result to the `dev` list and cc the `PMC`. For instance:
-
-
```
To: "Maven Developers List" <de...@maven.apache.org>
CC: "Maven Project Management Committee List" <pr...@maven.apache.org>
@@ -182,15 +145,10 @@ I will promote the source release zip file to Apache distribution area and the a
Follow the procedure to the end.
-
-
#### Unsuccessful vote
-
Once a vote is **unsuccessful**, post the result to the `dev` list, For instance:
-
-
```
To: "Maven Developers List" <de...@maven.apache.org>
Subject: [CANCEL] [VOTE] Release Apache Maven XXX Plugin version Y.Z
@@ -202,47 +160,34 @@ The vote has been canceled.
For canceled vote the process will need to be restarted.
-
Be sure to:
+- drop your staging repository as described in [Drop a repository](https://www.apache.org/dev/publishing-maven-artifacts.html)
+- create new version for next round `Y.Z+1`
- - drop your staging repository as described in [Drop a repository](https://www.apache.org/dev/publishing-maven-artifacts.html)
-
- - create new version for next round `Y.Z+1`
-
- - assign issues from version `Y.Z` also to version `Y.Z+1`
+- assign issues from version `Y.Z` also to version `Y.Z+1`
- - mark the `Y.Z` version as **archived**
+- mark the `Y.Z` version as **archived**
- - report found issues and assign them to version `Y.Z+1`
-
- - fix found issues
+- 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 [Apache Release Distribution Policy](https://www.apache.org/dev/release-distribution). All releases for Maven must be copied to [the official Maven release area](https://www.apache.org/dist/maven/).
-
The release area is maintained with svnpubsub. To deliver a release, you add it to [the subversion repository for the dist area](https://dist.apache.org/repos/dist/release/maven): add the release, its signature and sha512 checksum files, copying them from `target/checkout/target/` directory created during `mvn release:perform` step. Currently this requires to be in maven-pmc group (see [INFRA-5945](https://issues.apache.org/jira/browse/INFRA-5945)). If you are not a PMC member, drop a l [...]
-
-
```
for f in *.zip ; do echo -n $(sha512sum $f | cut -c -128) > $f.sha512 ; done
```
For example:
-
-
```
wagon/wagon-2.2-source-release.zip
wagon/wagon-2.2-source-release.zip.asc
@@ -251,76 +196,48 @@ wagon/wagon-2.2-source-release.zip.sha512
You should also run 'svn rm' as needed to clear out older releases. As per [Apache Release Policy](https://www.apache.org/legal/release-policy.html#where-do-releases-go), only the latest release on a branch should stay in the main dist areas. So long as the previous release is at least a day old, the automatic archiver will have copied it to the archive.
-
To check that everything is ok in the dist area, dist-tool-plugin has been written and run once a day to produce ["Check Source Release" and "Check Errors" reports](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/).
-
-
### Add the release for next board report
-
After committing the 3 source-release files, visit [Apache Committee Report Helper](https://reporter.apache.org/addrelease.html?maven) to add your release data with the Full Version Name and Date of Release. (You will receive an e-mail for it as well).
-
If you are not a PMC member, drop a line to _private@maven.apache.org_ and ask them to do this step for you if they did not do the update while adding to release area.
-
-
### Promote the release
-
Once the release is deemed fit for public consumption it can be transfered to a production repository where it will be available to all users.
-
-
1 See [Promoting a Repo](https://www.apache.org/dev/publishing-maven-artifacts.html#promote) for details on promotion.
1 Deploy the current website
As above, deploy the web site if appropriate and update the project site for the new release: use [Component Reference Documentation Helper](../website/component-reference-documentation-helper.html) to generate commands or see [Publishing versioned component reference documentation](../website/deploy-component-reference-documentation.html#Publishing_versioned_component_reference_documentation) for explanations. Note that not all projects follow these conventions exactly.
-
-
In case there's an overview table with version (e.g. [plugins](/plugins/index.html) and [shared](/shared/index.html)) you can directly edit it on the github page.
-
-
1 Update the version tracking in JIRA
In the relevant project, go to Administration, then Versions. Mark the `Y.Z` version as 'released'. Create version `Y.Z+1`, if that hasn't already been done. You may also archive any deprecated releases (milestones or alphas) at this time.
-
-
Note: Currently this requires to be in the maven-pmc group. So, if you don't see the Administration option in JIRA, kindly ask _private@maven.apache.org_ to do this step for you.
-
-
1 Wait for everything to sync
a Sync to [Maven Central](https://repo.maven.apache.org/maven2/org/apache/maven/)
The sync into central staging from repository.apache.org occurs every 4 hours. There is a separate hourly schedule that runs which pushes from staging to the other central machines, and then updates the indexes.
-
-
a Sync to Maven Website
If the project you are releasing doesn't yet use svnpubsub for site deployment, the deployment of the Maven website will [take an hour or so to sync](https://www.apache.org/dev/release-publishing.html#sync-delay).
-
-
-
-
1 Create an announcement.
Following instructions are done for plugins: if you are releasing anything else than a plugin, you should adapt email content to match what you are releasing.
-
-
**Note:** You must send this email from your apache email account, e.g. YOUR_APACHE_USERNAME@apache.org otherwise the email to `announce@maven.apache.org` will bounce.
-
-
```
From: YOUR_APACHE_USERNAME@apache.org
To: announce@maven.apache.org, users@maven.apache.org
@@ -355,14 +272,8 @@ Enjoy,
```
-
1 If releasing the Apache Parent POM, notify `release-discuss@apache.org`: Several projects follow this list, and should be made aware of changes to the common parent. This might also be a step to take if other shared resources are released, or if plugin releases are of particular interest to that group.
If releasing Maven Core, notify `announce@apache.org`
-
-
1 Celebrate :o)
-
-
-
diff --git a/content/markdown/developers/release/parent-pom-release.md b/content/markdown/developers/release/parent-pom-release.md
index 667abcdd..b9eef9ed 100644
--- a/content/markdown/developers/release/parent-pom-release.md
+++ b/content/markdown/developers/release/parent-pom-release.md
@@ -23,24 +23,16 @@ under the License.
## Releasing A Parent POM
-
Releasing a Parent POM is much the same as any other Maven project. The following guide walks through most of the steps:
-
-
- - [ Maven Project Common Release procedure](./maven-project-release-procedure.html)
-
+- [Maven Project Common Release procedure](./maven-project-release-procedure.html)
Note that Parent POMs have particular conventions for managing and deploying the documentation.
-
### Rationale
-
To be able to publish a documentation for the parent POM without affecting released `pom.xml` and `site.xml`, parent POM projects have a specific structure, with the addition of `site-pom.xml` and `src/site-docs` to provide `mvn -f site-pom.xml site` with useful documentation content:
-
-
```
|-- pom.xml
|-- site-pom.xml
@@ -55,44 +47,30 @@ under the License.
And the `index.apt` page not only contains instructions about the content of the parent POM, but it maintains a history of POM releases links and diffs.
-
Each specific step is done to maintain `site-pom.xml` and `index.apt` in sync with the release being released.
-
-
### Stage the release
-
Before staging the release with usual procedure, you need to update `site-pom.xml` and `index.apt` to take the future release into account:
-
-
1 update `site-pom.xml` parent POM version to match the version being released,
1 update `src/site-docs/index.apt.vm`: add a line in the history of `pom.xml` for the version being released, referring to the future git release tag and date.
-
Once these modifications are done, you can follow [standard component documentation staging steps](../website/deploy-component-reference-documentation.html), taking care to use the `site-pom.xml` POM, with `mvn -f site-pom.xml ...` command, each time the parent POM's site is generated or published.
-
Then the only difference is with commands to stage the site:
-
-
```
cd target/checkout
mvn -f site-pom.xml site
mvn -f site-pom.xml scm-publish:publish-scm
```
-
### Call the vote
-
In the vote, instead of providing links to JIRA, the parent POMs should include a link to the Git changes since the last release:
-
-
```
...
Hi,
@@ -107,5 +85,3 @@ https://github.com/apache/maven-parent/compare/maven-parent-<VERSION-OF-PREVIOUS
Staging repo:
...
```
-
-
diff --git a/content/markdown/developers/release/pmc-gpg-keys.md b/content/markdown/developers/release/pmc-gpg-keys.md
index a235cdf2..4a5890fb 100644
--- a/content/markdown/developers/release/pmc-gpg-keys.md
+++ b/content/markdown/developers/release/pmc-gpg-keys.md
@@ -23,14 +23,10 @@ under the License.
## Introduction
-
You need to add your GPG keys in [https://svn.apache.org/repos/asf/maven/project/KEYS](https://svn.apache.org/repos/asf/maven/project/KEYS) before a release. Here are some useful [GnuPG](http://www.gnupg.org/) commands to generate your Keys.
-
### gpg --gen-key
-
-
```
>gpg --gen-key
gpg (GnuPG) 1.4.5; Copyright (C) 2006 Free Software Foundation, Inc.
@@ -108,11 +104,8 @@ sub 2048g/D2814A59 2006-10-10
```
-
### gpg --list-sigs && gpg --armor --export
-
-
```
>gpg --list-sigs "Vincent Siveton" && gpg --armor --export "Vincent Siveton"
pub 1024D/07DDB702 2006-10-10
@@ -123,25 +116,16 @@ sig 07DDB702 2006-10-10 Vincent Siveton <vs...@apache.org>
```
-
-
## Version: GnuPG v1.4.5 (MingW32)
-
-
## mQGiBEUrnAsRBACQDiYGc1IQmkENLO9iznBg8otGPEbzqQozT5tsip5mB30f6Mc/ uuLxJkLdna7Ul3goIXDtCeLJq38gHvruNtVNR6S+juJFkd5sLEH8UJ18PbKuo/9I KGlzjtCYUUDC48czRr0efhqd54NH8ydNdpaZ76NGPPYfpXtk7kKgH/nPiwCgxozK IG2frMuWIvdFafbqdAl7y/sD/1Csf0r9jtHEeXOuyhm8jCGrSwzLbHUGKPUQP37P ajECHoWp6HnvHEEEpgVl+UjfZvrcVhzUoP+3r5HAugqERfkzK8AWc7qjIRjf64kU sjvto31G2KYz17Y8K9y4LkRkUspu8uw903pKnW/QELg4vvPVaEYpVVIdS6+cUreu V0hOA/4tW7T/GpzSbQmjvnIRQ7GVHbQeXsANwrS6NmGYIxafN9P9dfHV+eUieTu6 rvMP9coOhTYyEKZksrXw2MmXx5SzgxsXT0 [...]
-
You need to append this result to [https://svn.apache.org/repos/asf/maven/project/KEYS](https://svn.apache.org/repos/asf/maven/project/KEYS).
-
You also need to upload your key to the public server: [http://pgp.mit.edu/](http://pgp.mit.edu/) by copying the same you appended in the text field and submit. You can ensure by searching your email in key search engine.
-
### gpg --fingerprint
-
-
```
>gpg --fingerprint vsiveton
pub 1024D/07DDB702 2006-10-10
@@ -152,8 +136,4 @@ sub 2048g/D2814A59 2006-10-10
Go to [https://id.apache.org](https://id.apache.org), log in and fill `OpenPGP Public Key Primary Fingerprint:` with the value of `Key fingerprint`.
-
You can read more about [Checksums And Signatures](https://www.apache.org/dev/release-signing.html#faq).
-
-
-
diff --git a/content/markdown/developers/retirement-plan-plugins.md b/content/markdown/developers/retirement-plan-plugins.md
index 77bbec25..f190e96d 100644
--- a/content/markdown/developers/retirement-plan-plugins.md
+++ b/content/markdown/developers/retirement-plan-plugins.md
@@ -22,28 +22,20 @@ under the License.
-->
## Retirement Plan for Plugins
-
### Decide to retire
-
Propose a vote on the dev-list to retire a plugin. The vote should be open for the standard 72 hours to allow people to voice their opinions. Send a cc to the users-list. Standard Apache voting rules apply. Only PMC votes are binding.
-
The vote must contain one or more options on how to retire the plugin. There are multiple scenarios available. Here are a couple that have been suggested:
-
-
A Move to our retired area in svn
A Move to another Apache project
A Move to www.mojohaus.org, apache-extras.org or another forge
-
Here's a template for scenario A that can be used for the vote email:
-
-
```
To: "Maven Developers List" <de...@maven.apache.org>
Cc: "Maven Users List" <us...@maven.apache.org>
@@ -71,8 +63,6 @@ The vote is open for 72 hours.
If the vote is successful, post the result to the dev list and cc the PMC and users list. For instance:
-
-
```
To: "Maven Developers List" <de...@maven.apache.org>
Cc: "Maven Users List" <us...@maven.apache.org>
@@ -91,12 +81,8 @@ I will continue with the steps required to retire this plugin.
If the vote passes, make one final release of the plugin (with its own standard 72h vote on source release) before it is retired. This allows us to make a clean break. The person who wants to retire a plugin is the one who does the final release. Below you will find the extra steps that you need to follow when retiring a plugin, in addition to [our standard release process](./release/maven-project-release-procedure.html).
-
-
### Make the final release
-
-
1 Create an issue in JIRA with the issue type "Task" and the summary "Retire this plugin", and schedule it for the final release. If the plugin includes a JIRA report in the generated site, you will need to close this issue before you make the release.
1 Add the description "This is the final version of this plugin. It has been retired." to the final version in JIRA.
@@ -107,17 +93,13 @@ I will continue with the steps required to retire this plugin.
Note: This plugin is retired. It is no longer maintained.
```
-
If the plugin is moved elsewhere, that should also be added to the plugin's site. Suggested text:
-
-
```
Note: This plugin has retired from the Apache Maven project,
but has moved to the <Organization> <Project> project.
```
-
1 Add " (RETIRED)" at the end of `<project> <name>` in the plugin's `pom.xml`. This will show up on every page of the generated site.
1 Go ahead with [the standard release process](./release/maven-project-release-procedure.html), making sure that you follow the exceptions mentioned above regarding the site deployment.
@@ -126,19 +108,15 @@ but has moved to the <Organization> <Project> project.
1 When updating the version in JIRA, do not add Y.Z+1 and make sure you remove any future versions.
-
-
### Clean up after the release
-
-
- 1 Remove the `.Jenkinsfile` from all branches. This will remove the project from https://builds.apache.org/job/maven-box/
+ 1 Remove the `.Jenkinsfile` from all branches. This will remove the project from <https://builds.apache.org/job/maven-box/>
1 Ask INFRA for archive git repos (gitbox + github)
1 Republish documentation, postfix project name with (RETIRED)
- 1 When relevant update summary pages for [plugins](https://maven.apache.org/plugins/index.html) or [shared components](https://maven.apache.org/shared/index.html)
+ 1 When relevant update summary pages for [plugins](https://maven.apache.org/plugins/index.html) or [shared components](https://maven.apache.org/shared/index.html)
1 Add " (RETIRED)" at the end of the project name in JIRA.
@@ -152,6 +130,4 @@ but has moved to the <Organization> <Project> project.
1 Announce the fact that the plugin has been retired/moved on the announce@m.a.o and users@m.a.o mailing lists. Explain to people what they should do if they would like to continue development of the plugin.
-
<!-- Insert template for retirement email here -->
-
diff --git a/content/markdown/developers/website/component-reference-documentation-helper.md b/content/markdown/developers/website/component-reference-documentation-helper.md
index dc881c9b..54f110f8 100644
--- a/content/markdown/developers/website/component-reference-documentation-helper.md
+++ b/content/markdown/developers/website/component-reference-documentation-helper.md
@@ -34,7 +34,7 @@ select component category, then type artifact id and version to generate svn com
<li><a href="?doxia-tools">Doxia Tools</a></li>
<li><a href="?others">others</a></li>
</ul>
-
+
</td><td>
<h3>Component information</h3>
diff --git a/content/markdown/developers/website/deploy-component-reference-documentation.md b/content/markdown/developers/website/deploy-component-reference-documentation.md
index 976a785c..ca48febc 100644
--- a/content/markdown/developers/website/deploy-component-reference-documentation.md
+++ b/content/markdown/developers/website/deploy-component-reference-documentation.md
@@ -23,102 +23,69 @@ under the License.
## Introduction
-
This document gives step-by-step instructions for deploying Maven components reference documentation inside the Maven [https://maven.apache.org/](/) website.
-
See [Maven website introduction](./index.html) for instructions on the whole website publication (main site content + components).
-
-
## Overview
-
Since December 2012, the overall website uses svnpubsub mechanism:
<img src="component-reference-documentation.png" />Components reference documentation mechanisms overview
-
## How components reference documentation publication works
-
Components don't use CMS: components reference documentation are versioned and generated from full sources, with both handwritten content (like Maven main site) and content generated from sources (javadoc, unit-test results, integration test results...).
-
### Staging component reference documentation
-
Reference documentation of a component is staged in `https://maven.apache.org/xxx-archives/yyy-LATEST/`, where `yyy` is the component name and `xxx` can be:
+- the component type, like `shared`, `plugins`, `skins`, ... (see [/shared-archives/](/shared-archives/), [/plugins-archives/](/plugins-archives/), [/pom-archives/](/pom-archives/), [/skins-archives/](/skins-archives/))
-
- - the component type, like `shared`, `plugins`, `skins`, ... (see [/shared-archives/](/shared-archives/), [/plugins-archives/](/plugins-archives/), [/pom-archives/](/pom-archives/), [/skins-archives/](/skins-archives/))
-
- - the component name for standalone components, like `archetype`, `plugin-tools`, `surefire`, `wagon`, ... (see [/archetype-archives/](/archetype-archives/), [/archetypes-archives/](/archetypes-archives/), [/plugin-tools-archives/](/plugin-tools-archives/), [/scm-archives/](/scm-archives/), [/surefire-archives/](/surefire-archives/), [/wagon-archives/](/wagon-archives/))
-
+- the component name for standalone components, like `archetype`, `plugin-tools`, `surefire`, `wagon`, ... (see [/archetype-archives/](/archetype-archives/), [/archetypes-archives/](/archetypes-archives/), [/plugin-tools-archives/](/plugin-tools-archives/), [/scm-archives/](/scm-archives/), [/surefire-archives/](/surefire-archives/), [/wagon-archives/](/wagon-archives/))
To publish component reference documentation:
-
-
1 prerequisite: eventually build the component if it has not been done previously, or some reports may miss build or integration information:
Notice: In cases where you have prepared a release you can simple change into `target/checkout` directory and continue with 2.
-
-
```
mvn -Prun-its install
```
-
1 build the reference documentation:
```
mvn -Preporting site site:stage
```
-
Notice: `site:stage` is really necessary only for multi-modules components, but added unconditionally in these instructions to keep them as straightforward as possible.
-
-
1 stage the reference documentation to website production svn area, using [maven-scm-publish-plugin](/plugins/maven-scm-publish-plugin): (TODO: explanations on configuration in pom to yyy-LATEST)
```
mvn scm-publish:publish-scm
```
-
svnpubsub mechanism transfers svn production content to live production site
-
-
-
**Notice**: content is in fact published to [/components/](/components/) directory, and symbolic links declared in `resources/\*\*/components.links` in main site source are used by Ant to create a reference from `/xxx` (= what we want to be user-visible) to `/components/xxx` (what what is checked out).
-
-
### Publishing versioned component reference documentation
-
When doing a release, `yyy-LATEST` content staged in previous section needs:
-
-
1 to be archived to versioned directory before a newer revision is published into -LATEST,
1 to replace the actual component reference documentation.
-
This is done with operations on website production svn area: you can use [Component Reference Documentation Helper](./component-reference-documentation-helper.html) to easily prepare svnmucc command line.
-
If you prefer to do everything by hand from command templates, you can do either with `svn` command:
-
-
- - Unix:
+- Unix:
```
SVNPUBSUB=https://svn.apache.org/repos/asf/maven/website/components
@@ -129,8 +96,7 @@ svn rm $SVNPUBSUB/xxx/yyy -m "Remove old site."
svn cp $SVNPUBSUB/xxx-archives/yyy-$version $SVNPUBSUB/xxx/yyy -m "Publish new site."
```
-
- - Windows:
+- Windows:
```
set SVNPUBSUB=https://svn.apache.org/repos/asf/maven/website/components
@@ -141,12 +107,8 @@ svn rm %SVNPUBSUB%/xxx/yyy -m "Remove old site."
svn cp %SVNPUBSUB%/xxx-archives/yyy-$version %SVNPUBSUB%/xxx/yyy -m "Publish new site."
```
-
-
or with [`svnmucc` command](http://svnbook.red-bean.com/en/1.8/svn.ref.svnmucc.re.html):
-
-
```
svnmucc -m "Publish yyy $version documentation" \
-U https://svn.apache.org/repos/asf/maven/website/components \
@@ -155,20 +117,12 @@ svnmucc -m "Publish yyy $version documentation" \
cp HEAD xxx-archives/yyy-LATEST xxx/yyy
```
-
### Updating index page in the Maven site
-
Some component types have an index page refering to each components of the same type. This is the case for plugins (see [index](/plugins/)), shared (see [index](/shared/)), poms (see [index](/pom/)) and skins (see [index](/skins/)).
-
Update the version number and release date for the component in the `content/apt/xxx/index.apt` page.
-
See [Deploy Maven website](../website/deploy-maven-website.html) for more in-depth instructions on main site content editing.
-
**Notice**: if you forget about updating the index page, dist-tool has a [report run daily](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/) that will gently send a failure notification on notifications@maven.a.o when "Check Errors" report is not empty.
-
-
-
diff --git a/content/markdown/developers/website/deploy-maven-website.md b/content/markdown/developers/website/deploy-maven-website.md
index 9f0940e1..aa9f1420 100644
--- a/content/markdown/developers/website/deploy-maven-website.md
+++ b/content/markdown/developers/website/deploy-maven-website.md
@@ -23,56 +23,39 @@ under the License.
## Introduction
-
This document gives step-by-step instructions for deploying the main Maven [https://maven.apache.org](/) website.
-
**Obsolete** this documentation is obsolete: with the migration of site source to Git, Apache CMS is not used any more. It is replaced by Git edit (eventually through GitHub with the "edit" link accessible from breadcrumb) followed by Jenkins job to build and commit to svnpubsub.
-
See [Maven website introduction](./index.html) for instructions on the whole website publication.
-
-
## Overview
-
Since December 2012, the overall website uses svnpubsub mechanism and the main website uses Apache CMS:
<img src="main-website.png" />Main website mechanisms overview
-
## How main website publication works
-
Maven main website ([https://maven.apache.org](https://maven.apache.org)) is generated with [maven-site-plugin](/plugins/maven-site-plugin) from a source tree stored in svn: [https://svn.apache.org/repos/asf/maven/site/trunk](https://svn.apache.org/repos/asf/maven/site/trunk).
-
### Edit source content
-
You can edit source content in 2 ways:
+ 1 use [the CMS UI](https://cms.apache.org/maven/) through your web browser:
+- Go to [https://cms.apache.org/maven/](https://cms.apache.org/maven/).
- 1 use [the CMS UI](https://cms.apache.org/maven/) through your web browser:
-
- - Go to [https://cms.apache.org/maven/](https://cms.apache.org/maven/).
-
- - Click link "Get Maven Working Copy".
-
- - Navigate to the content you want to modify.
-
- - Once you have modified the content, commit with the button "Submit".
+- 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".
1 checkout the source content locally, modify it with your favorite text editor, eventually test the result (`mvn site`), then check-in source modifications.
-
- After source tree is modified in svn, [a Buildbot job](http://ci.apache.org/builders/maven-site-staging) is triggered:
-
-
+ After source tree is modified in svn, [a Buildbot job](http://ci.apache.org/builders/maven-site-staging) is triggered:
1 it builds the HTML site using [maven-site-plugin](/plugins/maven-site-plugin): `mvn site`,
@@ -80,42 +63,28 @@ under the License.
1 svnpubsub mecanism transfers svn CMS staging content to live CMS staging site: [http://maven.staging.apache.org](http://maven.staging.apache.org),
-
-
### Publish site content
-
If everything is good, **publish modifications** using [CMS publish](https://cms.apache.org/maven/publish) action.
-
Under the hood:
-
-
1 CMS copies CMS staging svn area content to [website production svn area](https://svn.apache.org/repos/infra/websites/production/maven/content/),
1 svnpubsub mecanism transfers svn production content to live production site: [http://maven.apache.org](http://maven.apache.org).
-
-
-
## How Doxia website publication works
-
Doxia uses the exact same mecanisms:
+- you can edit [svn source tree](https://svn.apache.org/repos/asf/maven/doxia/site/trunk) either locally or through [CMS UI](https://cms.apache.org/maven-doxia/),
+- [a Buildbot job](http://ci.apache.org/builders/maven-doxia-site-staging) builds the site and updates [website staging svn area](https://svn.apache.org/repos/infra/websites/staging/maven-doxia/trunk/content/),
- - you can edit [svn source tree](https://svn.apache.org/repos/asf/maven/doxia/site/trunk) either locally or through [CMS UI](https://cms.apache.org/maven-doxia/),
-
- - [a Buildbot job](http://ci.apache.org/builders/maven-doxia-site-staging) builds the site and updates [website staging svn area](https://svn.apache.org/repos/infra/websites/staging/maven-doxia/trunk/content/),
-
- - svnpubsub published to [live staging site](http://maven-doxia.staging.apache.org),
-
- - if everything is good, **publish modifications** using [CMS publish](https://cms.apache.org/maven-doxia/publish) action,
-
- - CMS copies CMS staging svn area content to [website production svn area](https://svn.apache.org/repos/infra/websites/production/maven-doxia/content/),
+- svnpubsub published to [live staging site](http://maven-doxia.staging.apache.org),
- - svnpubsub mecanism transfers svn production content to live production site: [http://maven.apache.org/doxia](http://maven.apache.org/doxia), with its [`extpaths.txt`](/doxia/extpaths.txt)
+- if everything is good, **publish modifications** using [CMS publish](https://cms.apache.org/maven-doxia/publish) action,
+- CMS copies CMS staging svn area content to [website production svn area](https://svn.apache.org/repos/infra/websites/production/maven-doxia/content/),
+- svnpubsub mecanism transfers svn production content to live production site: [http://maven.apache.org/doxia](http://maven.apache.org/doxia), with its [`extpaths.txt`](/doxia/extpaths.txt)
diff --git a/content/markdown/developers/website/index.md b/content/markdown/developers/website/index.md
index 75ee1501..46baa0d4 100644
--- a/content/markdown/developers/website/index.md
+++ b/content/markdown/developers/website/index.md
@@ -23,45 +23,30 @@ under the License.
## Introduction
-
The Maven [https://maven.apache.org](https://maven.apache.org) website is composed from:
+- a main content,
-
- - a main content,
-
- - multiple components reference documentation, published for each component release.
-
+- multiple components reference documentation, published for each component release.
And [Doxia](https://maven.apache.org/doxia/) website has the same dual structure.
-
These contents are stored in svn, and svnpubsub/svnwcsub maintains a working copy on the webservers in `/www/maven.apache.org/content` (see [`svnwcsub` configured in infra Puppet](https://github.com/apache/infrastructure-puppet/blob/deployment/modules/svnwcsub/files/svnwcsub.conf#L123)):
+- `/` comes from [https://svn.apache.org/repos/asf/maven/website/content/](https://svn.apache.org/viewvc/maven/website/content/)
+- [`/components`](https://maven.apache.org/components) comes from [https://svn.apache.org/repos/asf/maven/website/components/](https://svn.apache.org/repos/asf/maven/website/components/)
- - `/` comes from [https://svn.apache.org/repos/asf/maven/website/content/](https://svn.apache.org/viewvc/maven/website/content/)
-
- - [`/components`](https://maven.apache.org/components) comes from [https://svn.apache.org/repos/asf/maven/website/components/](https://svn.apache.org/repos/asf/maven/website/components/)
-
- - `/doxia` comes from [https://svn.apache.org/repos/asf/maven/doxia/website/content/](https://svn.apache.org/viewvc/maven/doxia/website/content/)
-
- - [`/doxia/components`](https://maven.apache.org/doxia/components) comes from [https://svn.apache.org/repos/asf/maven/doxia/website/components/](https://svn.apache.org/repos/asf/maven/doxia/website/components/)
+- `/doxia` comes from [https://svn.apache.org/repos/asf/maven/doxia/website/content/](https://svn.apache.org/viewvc/maven/doxia/website/content/)
+- [`/doxia/components`](https://maven.apache.org/doxia/components) comes from [https://svn.apache.org/repos/asf/maven/doxia/website/components/](https://svn.apache.org/repos/asf/maven/doxia/website/components/)
and the link between main content and components reference documentation (for example from `/plugins/maven-xxx-plugin` to internal `/components/plugins/maven-xxx-plugin`) is done with symbolic links. These links are configured in `components.links` files in `content/resources/` and subdirectories, for example [plugins/components.links](https://github.com/apache/maven-site/blob/master/content/resources/plugins/components.links).
-
-
## How website publication works
-
Instructions on how to publish website content are split in separate documents:
+- on every main content source commit ([maven-site.git](https://github.com/apache/maven-site) and [maven-doxia-site.git](https://github.com/apache/maven-doxia-site)), main content rebuild and publish is triggered through Jenkins jobs ( [maven-site job](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-site/) and [doxia-site job](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-doxia-site/)), which basically run `mvn site-deploy` (it can be run locally if CI is off...),
-
- - on every main content source commit ([maven-site.git](https://github.com/apache/maven-site) and [maven-doxia-site.git](https://github.com/apache/maven-doxia-site)), main content rebuild and publish is triggered through Jenkins jobs ( [maven-site job](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-site/) and [doxia-site job](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-doxia-site/)), which basically run `mvn site-deploy` (it can be run locally if CI is off...),
-
- - on every Maven component release, release manager follows "[deploying Maven components reference documentation](./deploy-component-reference-documentation.html)", eventually using [Component Reference Documentation Helper](./component-reference-documentation-helper.html) to easily prepare `svnmucc` command line.
-
-
+- on every Maven component release, release manager follows "[deploying Maven components reference documentation](./deploy-component-reference-documentation.html)", eventually using [Component Reference Documentation Helper](./component-reference-documentation-helper.html) to easily prepare `svnmucc` command line.
diff --git a/content/markdown/developers/website/website-overview.md b/content/markdown/developers/website/website-overview.md
index 21fe3bb8..fe6d8aa8 100644
--- a/content/markdown/developers/website/website-overview.md
+++ b/content/markdown/developers/website/website-overview.md
@@ -22,17 +22,12 @@ under the License.
-->
## Introduction
-
The Maven [https://maven.apache.org](/) website is composed from:
+- a main content
-
- - a main content
-
- - multiple components reference documentation
+- multiple components reference documentation
<img src="website-overview.png" />Website mechanisms overview
See [Maven website introduction](./index.html) for instructions on website publication.
-
-
diff --git a/content/markdown/developers/welcome-to-new-committers.md b/content/markdown/developers/welcome-to-new-committers.md
index 3d47244b..2bd6315d 100644
--- a/content/markdown/developers/welcome-to-new-committers.md
+++ b/content/markdown/developers/welcome-to-new-committers.md
@@ -22,45 +22,30 @@ under the License.
-->
## Guide for new Maven committers
-
First of all congratulations, thank you, and welcome to the fold! If you are reading this you've recently been voted in as committer on an Apache Maven project and there are a few things that need to be sorted out before you can participate fully.
-
The first thing to get out of the way is sending in your contributor's license agreement (CLA). You can't participate at Apache until we have received your signed CLA, so go to the [Apache website](http://www.apache.org/licenses/#clas), print out the CLA, sign it, and send it in ASAP.
-
Once you've dealt with your CLA, there are a some documents that pertain to Apache as a whole you should read:
+- [How the ASF works](http://www.apache.org/foundation/how-it-works.html)
+- [Guide for new committers](http://www.apache.org/dev/new-committers-guide.html)
- - [How the ASF works](http://www.apache.org/foundation/how-it-works.html)
-
- - [Guide for new committers](http://www.apache.org/dev/new-committers-guide.html)
-
- - [The committers FAQ](http://www.apache.org/dev/committers.html)
-
- - [How voting works](http://www.apache.org/foundation/voting.html)
+- [The committers FAQ](http://www.apache.org/dev/committers.html)
+- [How voting works](http://www.apache.org/foundation/voting.html)
Here are the documents that pertain to Maven specifically:
+- [Guide to Maven development](/guides/development/guide-maven-development.html)
-
- - [Guide to Maven development](/guides/development/guide-maven-development.html)
-
- - [Setup your committer environment](/developers/committer-environment.html)
-
+- [Setup your committer environment](/developers/committer-environment.html)
And here are the specifics on setting up your Git access:
-
-
- - [Apache's Source Code Repository](http://www.apache.org/dev/version-control.html)
-
+- [Apache's Source Code Repository](http://www.apache.org/dev/version-control.html)
If you have any questions just ask! We're here to help, and looking forward to working with you!
-
The Maven Team!
-
-
diff --git a/content/markdown/docs/3.2.1/release-notes.md b/content/markdown/docs/3.2.1/release-notes.md
index 170cf101..f09242a2 100644
--- a/content/markdown/docs/3.2.1/release-notes.md
+++ b/content/markdown/docs/3.2.1/release-notes.md
@@ -99,7 +99,6 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
-[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330185
[5]: ../../docs/history.html
[MNG-2315]: https://issues.apache.org/jira/browse/MNG-2315
@@ -107,9 +106,6 @@ See [complete release notes for all versions][5]
[MNG-5582]: https://issues.apache.org/jira/browse/MNG-5582
[MNG-5230]: https://issues.apache.org/jira/browse/MNG-5230
[MNG-5389]: https://issues.apache.org/jira/browse/MNG-5389
-[MNG-5578]: https://issues.apache.org/jira/browse/MNG-5578
-[MNG-5530]: https://issues.apache.org/jira/browse/MNG-5530
-[MNG-5549]: https://issues.apache.org/jira/browse/MNG-5549
[MNG-5575]: https://issues.apache.org/jira/browse/MNG-5575
[MNG-5576]: https://issues.apache.org/jira/browse/MNG-5576
[MNG-5581]: https://issues.apache.org/jira/browse/MNG-5581
diff --git a/content/markdown/docs/3.2.2/release-notes.md b/content/markdown/docs/3.2.2/release-notes.md
index a9db4484..d5814845 100644
--- a/content/markdown/docs/3.2.2/release-notes.md
+++ b/content/markdown/docs/3.2.2/release-notes.md
@@ -71,7 +71,7 @@ Multiple profile activation conditions are now ANDed instead of ORed. We believe
### Support resolution of Import Scope POMs from Repo that contains a ${parameter} ([MNG-5639][MNG-5639])
-This feature helps support the pattern where many streams of development are setup with an individually sandboxed repository holding specific version of several shared components. A repository configuration might use the pattern ${nexus.baseurl}/content/groups/${stream.name} where the properties are set in settings.xml file.
+This feature helps support the pattern where many streams of development are setup with an individually sandboxed repository holding specific version of several shared components. A repository configuration might use the pattern ${nexus.baseurl}/content/groups/${stream.name} where the properties are set in settings.xml file.
### Update maven-plugin-plugin:descriptor default binding from generate-resources phase to process-classes ([MNG-5346][MNG-5346])
@@ -117,7 +117,6 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
-[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330186
[5]: ../../docs/history.html
[MNG-2199]: https://issues.apache.org/jira/browse/MNG-2199
diff --git a/content/markdown/docs/3.2.3/release-notes.md b/content/markdown/docs/3.2.3/release-notes.md
index 3518c412..abf5e38a 100644
--- a/content/markdown/docs/3.2.3/release-notes.md
+++ b/content/markdown/docs/3.2.3/release-notes.md
@@ -53,11 +53,6 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
-[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330187
[5]: ../../docs/history.html
[MNG-5672]: https://issues.apache.org/jira/browse/MNG-5672
-[MNG-4565]: https://issues.apache.org/jira/browse/MNG-4565
-[MNG-5346]: https://issues.apache.org/jira/browse/MNG-5346
-[MNG-5452]: https://issues.apache.org/jira/browse/MNG-5452
-[MNG-5639]: https://issues.apache.org/jira/browse/MNG-5639
diff --git a/content/markdown/docs/3.2.5/release-notes.md b/content/markdown/docs/3.2.5/release-notes.md
index c4484194..2d987cc8 100644
--- a/content/markdown/docs/3.2.5/release-notes.md
+++ b/content/markdown/docs/3.2.5/release-notes.md
@@ -47,6 +47,5 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
-[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330189
[5]: ../../docs/history.html
diff --git a/content/markdown/docs/3.3.1/release-notes.md b/content/markdown/docs/3.3.1/release-notes.md
index 69950e46..918c407b 100644
--- a/content/markdown/docs/3.3.1/release-notes.md
+++ b/content/markdown/docs/3.3.1/release-notes.md
@@ -21,7 +21,7 @@
## Overview
-The Apache Maven team would like to announce the release of Maven Version 3.3.1. The new
+The Apache Maven team would like to announce the release of Maven Version 3.3.1. The new
Maven Version is [available for download][0].
Maven is a software project management and comprehension tool. Based on the concept of a project object model
@@ -47,43 +47,43 @@ Maven project][5].
The new [Maven 3.3.1 Release is just out](http://mail-archives.apache.org/mod_mbox/maven-announce/201503.mbox/%3C1954448.IV3m89R0sE%40herve-desktop%3E). Let us take a deeper look into the new features/improvements:
-* The first and most important thing is that [Maven 3.3.1 needs JDK 1.7][MNG-5780].
+- The first and most important thing is that [Maven 3.3.1 needs JDK 1.7][MNG-5780].
### Toolchains
-* In our days it becomes more and more important to be able to use different JDK
+- In our days it becomes more and more important to be able to use different JDK
to be used by Maven itself and which is used to compile/test your production code.
- This concept is know under the name [Toolchains][0] which is unfortunately not very
+ This concept is know under the name [Toolchains][0] which is unfortunately not very
well-known.
-* The handling of the [`toolchains.xml`][MNG-3891] file has been adjusted with the
+- The handling of the [`toolchains.xml`][MNG-3891] file has been adjusted with the
handling of `settings.xml` which means it will be searched within the
`${maven.home}/conf/` directory and furthermore within the `${user.home}/.m2/` directory.
-* For a better understanding and as an example of the `toolchains.xml` file has been added
+- For a better understanding and as an example of the `toolchains.xml` file has been added
to the [Maven distribution][MNG-5745].
-* Maven has been improved to read the `toolchains.xml` file [during initialization][MNG-5754] instead
+- Maven has been improved to read the `toolchains.xml` file [during initialization][MNG-5754] instead
of waiting till [maven-toolchains-plugin][maven-toolchains-plugin] will read it.
-* Maven has a new option to handle global toolchains file `-gt file` or `--global-toolchains file`
+- Maven has a new option to handle global toolchains file `-gt file` or `--global-toolchains file`
in the spirit of global settings file[MNG-3891][MNG-3891].
### Core Extensions
-* Core Extension mechanism has [been improved][MNG-5771] to make
+- Core Extension mechanism has [been improved][MNG-5771] to make
it simpler to use.
-* The old way (up to Maven 3.2.5) was to create a jar (must be shaded if you have other dependencies)
- which contains the extension and put it manually into the `${MAVEN_HOME}/lib/ext` directory.
- This means you had to change the Maven installation. The consequence was that everyone who likes
- to use this needed to change it's installation and makes the on-boarding for a developer much
- more inconvenient. The other option was to give the path to the jar on command line via
+- The old way (up to Maven 3.2.5) was to create a jar (must be shaded if you have other dependencies)
+ which contains the extension and put it manually into the `${MAVEN_HOME}/lib/ext` directory.
+ This means you had to change the Maven installation. The consequence was that everyone who likes
+ to use this needed to change it's installation and makes the on-boarding for a developer much
+ more inconvenient. The other option was to give the path to the jar on command line via
`mvn -Dmaven.ext.class.path=extension.jar`. This has the drawback giving those
options to your Maven build every time you are calling Maven. Not very convenient as well.
-
-* From now on this can be done much more simpler and in a more Maven like way. So
- you can define an `${maven.projectBasedir}/.mvn/extensions.xml` file which looks
+
+- From now on this can be done much more simpler and in a more Maven like way. So
+ you can define an `${maven.projectBasedir}/.mvn/extensions.xml` file which looks
like the following:
``` xml
@@ -97,7 +97,7 @@ The new [Maven 3.3.1 Release is just out](http://mail-archives.apache.org/mod_mb
</extensions>
```
-* Now you can simply use an extension by defining the usual maven coordinates
+- Now you can simply use an extension by defining the usual maven coordinates
`groupId`, `artifactId`, `version` as any other artifact. Furthermore all
transitive dependencies of those extensions will automatically being downloaded
from your repository. So no need to create a shaded artifact anymore.
@@ -114,28 +114,28 @@ The new [Maven 3.3.1 Release is just out](http://mail-archives.apache.org/mod_mb
### JVM and Command Line Options
-* [Project specific jvm and command line otions][MNG-5767]
+- [Project specific jvm and command line otions][MNG-5767]
-* It's really hard to define a general set of options for calling the maven
+- It's really hard to define a general set of options for calling the maven
command line. Usually this will be solved by putting this options to a script
but this can now simple being done by defining
`${maven.projectBasedir}/.mvn/maven.config` file which contains the
configuration options for the command line. For example things like `-T3 -U
--fail-at-end`. So you only have to call maven just by using `mvn clean
package` instead of `mvn -T3 -U --fail-at-end clean package` and not to miss
- the `-T3 -U --fail-at-end` options. The `${maven.projectBasedir}/.mvn/maven.config`
- is located in the `${maven.projectBasedir}/.mvn/` directory which is in the root
- of a multi module build. This directory is part of the project and will be checked
- in into your version control. This results in being picked by everybody who
- checks out the project and no need to remember to call this project
+ the `-T3 -U --fail-at-end` options. The `${maven.projectBasedir}/.mvn/maven.config`
+ is located in the `${maven.projectBasedir}/.mvn/` directory which is in the root
+ of a multi module build. This directory is part of the project and will be checked
+ in into your version control. This results in being picked by everybody who
+ checks out the project and no need to remember to call this project
via `mvn -T3 -U --fail-at-end clean package` instead of `mvn clean package`.
-* In Maven it is not simple to define JVM configuration on a per project base.
+- In Maven it is not simple to define JVM configuration on a per project base.
The existing mechanism based on an environment variable `MAVEN_OPTS` and the
usage of `${user.home}/.mavenrc` is an other
option with the drawback of not being part of the project.
-* Starting with this release you can define JVM configuration via
+- Starting with this release you can define JVM configuration via
`${maven.projectBasedir}/.mvn/jvm.config` file which means you can define the
options for your build on a per project base. This file will become part of
your project and will be checked in along with your project. So no need anymore
@@ -146,20 +146,19 @@ The new [Maven 3.3.1 Release is just out](http://mail-archives.apache.org/mod_mb
-Xmx2048m -Xms1024m -XX:MaxPermSize=512m -Djava.awt.headless=true
```
-* you don't need to remember of using this options in `MAVEN_OPTS` or switching
+- you don't need to remember of using this options in `MAVEN_OPTS` or switching
between different configurations.
-
### Plugin Goal Invocation from Command Line
-
- * Improvement for [Plugin Goal Invocation from command line][MNG-5768]
+- Improvement for [Plugin Goal Invocation from command line][MNG-5768]
If you call a plugin directly from command line like the following:
```
mvn exec:java
```
+
The configuration which is used here can be defined in your pom by using an execution id `default-cli`.
```
@@ -225,18 +224,15 @@ mvn exec:java@second-cli
```
So now you can define more than one configuration for command line executions.
-
- * The Maven team has decided to [drop support for Win9x in launch scripts](https://issues.apache.org/jira/browse/MNG-5776)
- at long last. Yeah.
+- The Maven team has decided to [drop support for Win9x in launch scripts](https://issues.apache.org/jira/browse/MNG-5776)
+ at long last. Yeah.
-The above release notes have [originally been written by Karl Heinz Marbaise
+The above release notes have [originally been written by Karl Heinz Marbaise
and migrated afterwards to the Apache Maven project](http://blog.soebes.de/blog/2015/03/17/apache-maven-3-dot-3-1-features/).
-
[0]: ../../download.html
[1]: ../../plugins/index.html
-[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330193
[5]: ../../docs/history.html
diff --git a/content/markdown/docs/3.3.3/release-notes.md b/content/markdown/docs/3.3.3/release-notes.md
index 4ed25601..52180e9d 100644
--- a/content/markdown/docs/3.3.3/release-notes.md
+++ b/content/markdown/docs/3.3.3/release-notes.md
@@ -47,6 +47,5 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
-[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12332054
[5]: ../../docs/history.html
diff --git a/content/markdown/docs/3.3.9/release-notes.md b/content/markdown/docs/3.3.9/release-notes.md
index d38486bd..899e2aa1 100644
--- a/content/markdown/docs/3.3.9/release-notes.md
+++ b/content/markdown/docs/3.3.9/release-notes.md
@@ -35,142 +35,138 @@ We hope you enjoy using Maven! If you have any questions, please consult:
- the maven-user mailing list: [http://maven.apache.org/mailing-lists.html](/mailing-lists.html)
- the reference documentation: [http://maven.apache.org/ref/3.3.9/](/ref/3.3.9/)
-
Reporters and Contributors of this release
------------------------------------------
Bugs:
- * [MNG-5297] - contributor: Joseph Walton
- * [MNG-5721] - reporter/contributor Martin Schäf
- * [MNG-5786] - reporter Stephan Schroevers
- * [MNG-5787] - reporter Christian Schlichtherle
- * [MNG-5796] - reporter Brandon Enochs
- * [MNG-5812] - contributor tssp
- * [MNG-5816] - contributor tssp
- * [MNG-5858] - contributor Dave Syer
- * [MNG-5877] - contributor Joseph Walton; reporter Anders Forsell
- * [MNG-5882] - contributor Ben Caradoc-Davies
- * [MNG-5884] - contributor Stephen Kitt
- * [MNG-5886] - reporter Shubham Chaurasia
- * [MNG-5891] - reporter Keith Turner
- * [MNG-5898] - reporter Jonathan Radon
+- [MNG-5297] - contributor: Joseph Walton
+- [MNG-5721] - reporter/contributor Martin Schäf
+- [MNG-5786] - reporter Stephan Schroevers
+- [MNG-5787] - reporter Christian Schlichtherle
+- [MNG-5796] - reporter Brandon Enochs
+- [MNG-5812] - contributor tssp
+- [MNG-5816] - contributor tssp
+- [MNG-5858] - contributor Dave Syer
+- [MNG-5877] - contributor Joseph Walton; reporter Anders Forsell
+- [MNG-5882] - contributor Ben Caradoc-Davies
+- [MNG-5884] - contributor Stephen Kitt
+- [MNG-5886] - reporter Shubham Chaurasia
+- [MNG-5891] - reporter Keith Turner
+- [MNG-5898] - reporter Jonathan Radon
Improvements:
- * [MNG-5805] - contributor Anton Tanasenko
- * [MNG-5844] - contributor Tang Xinye
- * [MNG-5871] - make url inheritance algorithm more visible
- * [MNG-5923] - reporter/contributor: Stuart McCulloch
- * [MNG-5924] - reporter/contributor: Stuart McCulloch
+- [MNG-5805] - contributor Anton Tanasenko
+- [MNG-5844] - contributor Tang Xinye
+- [MNG-5871] - make url inheritance algorithm more visible
+- [MNG-5923] - reporter/contributor: Stuart McCulloch
+- [MNG-5924] - reporter/contributor: Stuart McCulloch
Many thanks to all reporters and contributors and for their time and support.
Improvements
------------
- * The `par` lifecycle has been removed from the default life cycle bindings and the maven-ejb3-plugin
+- The `par` lifecycle has been removed from the default life cycle bindings and the maven-ejb3-plugin
has been removed from default bindings, cause it does not exist [MNG-5892][MNG-5892], [MNG-5894][MNG-5894].
- * The default bindings defined two different versions for the [maven-resources-plugin][maven-resources-plugin]
+- The default bindings defined two different versions for the [maven-resources-plugin][maven-resources-plugin]
which has been fixed by [MNG-5893][MNG-5893].
- * Switch to official [Guice](https://github.com/google/guice/wiki/Motivation) 4.0, upgrade to
+- Switch to official [Guice](https://github.com/google/guice/wiki/Motivation) 4.0, upgrade to
[Eclipse/Sisu](https://www.eclipse.org/sisu/) 0.3.2 has been done with [MNG-5923][MNG-5923] and [MNG-5924][MNG-5924].
-
- * Several areas of Maven Core have been changed to use
- [Commons Lang](https://commons.apache.org/proper/commons-lang/)'s Validate to intercept invalid
+
+- Several areas of Maven Core have been changed to use
+ [Commons Lang](https://commons.apache.org/proper/commons-lang/)'s Validate to intercept invalid
input [MNG-5649][MNG-5649].
- * Upgrade Java minimum version prerequisite from Java 6 to Java 7 [MNG-5780][MNG-5780].
+- Upgrade Java minimum version prerequisite from Java 6 to Java 7 [MNG-5780][MNG-5780].
- * Custom packaging types: configuring DefaultLifecycleMapping mojo executions [MNG-5805][MNG-5805].
+- Custom packaging types: configuring DefaultLifecycleMapping mojo executions [MNG-5805][MNG-5805].
- * Disallow the programmatic injection of project dependencies [MNG-5818][MNG-5818].
+- Disallow the programmatic injection of project dependencies [MNG-5818][MNG-5818].
- * Close IO streams in finally or try-with-resource statement [MNG-5844][MNG-5844].
+- Close IO streams in finally or try-with-resource statement [MNG-5844][MNG-5844].
- * Make url inheritance algorithm more visible [MNG-5871][MNG-5871].
+- Make url inheritance algorithm more visible [MNG-5871][MNG-5871].
- * Update used [Modello](https://codehaus-plexus.github.io/modello/) version from 1.8.1 to 1.8.3 [MNG-5888][MNG-5888].
+- Update used [Modello](https://codehaus-plexus.github.io/modello/) version from 1.8.1 to 1.8.3 [MNG-5888][MNG-5888].
- * Maven build does not work with Maven 2.2.1 [MNG-5905][MNG-5905].
+- Maven build does not work with Maven 2.2.1 [MNG-5905][MNG-5905].
- * Use canonical name for UTC timezone [MNG-5906][MNG-5906].
+- Use canonical name for UTC timezone [MNG-5906][MNG-5906].
- * Upgrade [maven-parent](/pom/maven/) to version 27 [MNG-5911][MNG-5911].
+- Upgrade [maven-parent](/pom/maven/) to version 27 [MNG-5911][MNG-5911].
- * Upgrade [Wagon](/wagon/) version to 2.10 [MNG-5915][MNG-5915].
+- Upgrade [Wagon](/wagon/) version to 2.10 [MNG-5915][MNG-5915].
- * Upgraded to [plexus-component-*](https://codehaus-plexus.github.io/plexus-containers/) 1.6 that uses
+- Upgraded to [plexus-component-*](https://codehaus-plexus.github.io/plexus-containers/) 1.6 that uses
[asm](http://asm.ow2.org/) 5.x [MNG-5921][MNG-5921].
- * Upgrade [plexus-utils](https://codehaus-plexus.github.io/plexus-utils/) to 3.0.22 to support `combine.id` as configuration attribute for Map merging [MNG-5922][MNG-5922].
-
- * Update [animal-sniffer-maven-plugin](https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/) to 1.14. MANIMALSNIFFER-49 required when building with JDK9 [MNG-5925][MNG-5925].
+- Upgrade [plexus-utils](https://codehaus-plexus.github.io/plexus-utils/) to 3.0.22 to support `combine.id` as configuration attribute for Map merging [MNG-5922][MNG-5922].
+- Update [animal-sniffer-maven-plugin](https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/) to 1.14. MANIMALSNIFFER-49 required when building with JDK9 [MNG-5925][MNG-5925].
Bugs
----
- * Moving from Maven 3.0.5 to 3.3.3 breaks plugins with some dependencies on the classpath.
+- Moving from Maven 3.0.5 to 3.3.3 breaks plugins with some dependencies on the classpath.
This has been fixed with [MNG-5787][MNG-5787].
- * The Cygwin Shell related handling of the `MAVEN_PROJECTBASEDIR` has been fixed
+- The Cygwin Shell related handling of the `MAVEN_PROJECTBASEDIR` has been fixed
with [MNG-5812][MNG-5812].
- * The scripts to call Maven has introduced a bug related to the handling of the
+- The scripts to call Maven has introduced a bug related to the handling of the
`MAVEN_OPTS` and debugging options which has been fixed by [MNG-5813][MNG-5813].
- * Since Maven 3.3.1 it is possible to have configurations stored on a per project base in the
- `${maven.projectBasedir}/.mvn` directory of the project. There you can use the `maven.config`
+- Since Maven 3.3.1 it is possible to have configurations stored on a per project base in the
+ `${maven.projectBasedir}/.mvn` directory of the project. There you can use the `maven.config`
file to store command line options instead of repeating them every time you call Maven.
In cases where this file has been empty Maven ended with a failure. This has been fixed
with [MNG-5816][MNG-5816].
- * The handling of the relativePath in a parent has been fixed related to the case
+- The handling of the relativePath in a parent has been fixed related to the case
that the parent has the same groupId:artifactId but a different version. In this
case the resolution must be done against the repository.
This has been fixed by [MNG-5840][MNG-5840].
- * In cases where you start Maven in the root of a windows drive Maven will fail.
- This has been fixed by [MNG-5796][MNG-5796].
+- In cases where you start Maven in the root of a windows drive Maven will fail.
+ This has been fixed by [MNG-5796][MNG-5796].
- * The `<prerequisites>` elements is intended for [buildtime checking but not for runtime checks][MNG-4840]
- which should be left to [maven-enforcer-plugin][maven-enforcer-plugin].
+- The `<prerequisites>` elements is intended for [buildtime checking but not for runtime checks][MNG-4840]
+ which should be left to [maven-enforcer-plugin][maven-enforcer-plugin].
This has not been documented accordingly. This has been done with [MNG-5297][MNG-5297].
- * In situations like this: `mvn -Dtest=\"anton\" clean package` the trailing quote
+- In situations like this: `mvn -Dtest=\"anton\" clean package` the trailing quote
is stripped away which could cause problems. This has been fixed with [MNG-5681][MNG-5681].
- * Possible NullPointerException in org.apache.maven.repository.MetadataResolutionResult
+- Possible NullPointerException in org.apache.maven.repository.MetadataResolutionResult
has been fixed with [MNG-5721].
- * There had been several issues with the `mvn` script which are for example
+- There had been several issues with the `mvn` script which are for example
wrong locating the `.mvn` directory, nonportable shell constructs, wrongly setting
'maven.multiModuleProjectDirectory' variable or directories which contain spaces. Those
- issues have been fixed [MNG-5786][MNG-5786], [MNG-5858][MNG-5858],
+ issues have been fixed [MNG-5786][MNG-5786], [MNG-5858][MNG-5858],
[MNG-5882][MNG-5882] and [MNG-5884][MNG-5884].
- * Broken link of 'Building Maven' in README.md has been fixed by [MNG-5886][MNG-5886].
+- Broken link of 'Building Maven' in README.md has been fixed by [MNG-5886][MNG-5886].
- * [maven-aether-provider][maven-aether-provider]/[maven-compat][maven-compat]
- does not always generate snapshot versions using Gregorian calendar year
- fixed in [MNG-5877][MNG-5877]
+- [maven-aether-provider][maven-aether-provider]/[maven-compat][maven-compat]
+ does not always generate snapshot versions using Gregorian calendar year
+ fixed in [MNG-5877][MNG-5877]
- * Log file command line option description contains an extra word has been fixed by [MNG-5891][MNG-5891]
+- Log file command line option description contains an extra word has been fixed by [MNG-5891][MNG-5891]
- * org.apache.maven.repository.internal.RemoteSnapshotMetadataTest fails to start at midnight fixed with
+- org.apache.maven.repository.internal.RemoteSnapshotMetadataTest fails to start at midnight fixed with
[MNG-5907][MNG-5907].
- * Multi-module build with ear fails to resolve war in 3.3.3 fixed in [MNG-5898][MNG-5898].
-
+- Multi-module build with ear fails to resolve war in 3.3.3 fixed in [MNG-5898][MNG-5898].
Task
----
- * Update [Modello site url](https://codehaus-plexus.github.io/modello/) [MNG-5887][MNG-5887].
-
+- Update [Modello site url](https://codehaus-plexus.github.io/modello/) [MNG-5887][MNG-5887].
The full list of changes can be found in our [issue management system][4].
@@ -180,7 +176,6 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
-[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12333074
[5]: ../../docs/history.html
[maven-enforcer-plugin]: /enforcer/maven-enforcer-plugin/
diff --git a/content/markdown/docs/3.5.0-alpha-1/release-notes.md b/content/markdown/docs/3.5.0-alpha-1/release-notes.md
index dd5f4b01..059ee4d8 100644
--- a/content/markdown/docs/3.5.0-alpha-1/release-notes.md
+++ b/content/markdown/docs/3.5.0-alpha-1/release-notes.md
@@ -24,7 +24,7 @@ The Apache Maven team would like to announce the release of Maven 3.5.0-alpha-1.
<div class="alert alert-error" role="alert">
<p><b>NOTE:</b></p>
<p>This is an <i>ALPHA</i> release. There is the potential that features may be added/removed between this release and the first GA release in the 3.5.x release line.</p>
-<p><i>Please consult the Known Issues section below before use</i></p>
+<p><i>Please consult the Known Issues section below before use</i></p>
</div>
Maven 3.5.0-alpha-1 is [available for download][0].
@@ -45,8 +45,8 @@ We hope you enjoy using Maven! If you have any questions, please consult:
The following issues were identified during release testing of this _ALPHA_ release but have not been deemed as release blockers:
-* [MNG-6177] The `--file` and `-f` option to specify a `pom.xml` to use does not work if the path includes characters that need quoting such as whitespace or `&`.
-* [MNG-6115] If Maven is installed in a writable location, every build will create a new `lib/ext/jansi-....` file.
+- [MNG-6177] The `--file` and `-f` option to specify a `pom.xml` to use does not work if the path includes characters that need quoting such as whitespace or `&`.
+- [MNG-6115] If Maven is installed in a writable location, every build will create a new `lib/ext/jansi-....` file.
## Why not Maven 3.4.0?
@@ -58,29 +58,29 @@ The migration of the code between the two foundations took longer than expected
In order to refocus on the original intent for 3.4.0, the decision was taken to revert the Maven core history to the point of the 3.3.9 release and merge in the desired changes one at a time.
-Because there had been a lot of communication about different features being delivered and bugs fixed in Maven 3.4.0 and the new history may not contain them in the first release, the decision was taken to forever burn the 3.4.x release line.
+Because there had been a lot of communication about different features being delivered and bugs fixed in Maven 3.4.0 and the new history may not contain them in the first release, the decision was taken to forever burn the 3.4.x release line.
More detail on this decision can be read in the [mailing list archive](http://www.mail-archive.com/dev@maven.apache.org/msg112103.html).
## Reporters and Contributors of this release
-Bugs:
+Bugs:
- * [MNG-5963] reporter: Larry Singer
- * [MNG-5962] reporter/contributor: Miriam Lee
- * [MNG-5961] reporter: Mike Drob
- * [MNG-5958] reporter: Meytal Genah, contributor: Anton Tanasenko
- * [MNG-5852] reporter: Jeffrey Alexander
- * [MNG-5823] reporter: Tobias Oberlies
- * [MNG-5815] reporter: Peter Kjær Guldbæk
- * [MNG-5368] reporter: Andrew Haines
+- [MNG-5963] reporter: Larry Singer
+- [MNG-5962] reporter/contributor: Miriam Lee
+- [MNG-5961] reporter: Mike Drob
+- [MNG-5958] reporter: Meytal Genah, contributor: Anton Tanasenko
+- [MNG-5852] reporter: Jeffrey Alexander
+- [MNG-5823] reporter: Tobias Oberlies
+- [MNG-5815] reporter: Peter Kjær Guldbæk
+- [MNG-5368] reporter: Andrew Haines
Improvements:
- * [MNG-6030] reporter: Andriy contributor: Andriy
- * [MNG-5934] reporter/contributor: Alex Henrie
- * [MNG-5883] reporter: Ben Caradoc-Davies
- * [MNG-3507] contributors: Jason Dillon, Sébastian Le Merdy
+- [MNG-6030] reporter: Andriy contributor: Andriy
+- [MNG-5934] reporter/contributor: Alex Henrie
+- [MNG-5883] reporter: Ben Caradoc-Davies
+- [MNG-3507] contributors: Jason Dillon, Sébastian Le Merdy
Many thanks to all reporters and contributors for their time and support.
@@ -90,46 +90,45 @@ Thank you also for your time and feedback.
## Overview about the changes
- * The most obvious change you may encounter is that the console output
+- The most obvious change you may encounter is that the console output
has colors now [MNG-3507], [MNG-6093].
- * The new `project.directory` special property adds support in every calculated URLs (project, SCM, site)
+- The new `project.directory` special property adds support in every calculated URLs (project, SCM, site)
for module directory name that does not match artifactId [MNG-5878]
-
- * The `JAVA_HOME` discovery has been reduced to simply check if `JAVA_HOME` is set
+
+- The `JAVA_HOME` discovery has been reduced to simply check if `JAVA_HOME` is set
or not then trying to discover via `which java`, nothing more [MNG-6003].
- * The build bootstrapping support via Apache Ant has been removed. You can now only bootstrap Maven
+- The build bootstrapping support via Apache Ant has been removed. You can now only bootstrap Maven
build with a previous version of Maven, but not with Ant any more [MNG-5904].
- * Based on problems in using `M2_HOME` related to different Maven versions installed and
+- Based on problems in using `M2_HOME` related to different Maven versions installed and
to simplify things, the usage of `M2_HOME` has been removed and is not
supported any more [MNG-5823], [MNG-5836], [MNG-5607].
- * Important change for windows users: The usage of `%HOME%` has been replaced
+- Important change for windows users: The usage of `%HOME%` has been replaced
with `%USERPROFILE%` [MNG-6001]
- * Several issues have been reported and fixed related to the `mvn` script either
+- Several issues have been reported and fixed related to the `mvn` script either
for Unix/Linux/Cygwin/Solaris or for Windows
[MNG-5815], [MNG-5852], [MNG-5963], [MNG-6022].
- * In Maven 3.3.9, we have removed bindings for maven-ejb3-plugin because it
+- In Maven 3.3.9, we have removed bindings for maven-ejb3-plugin because it
does not exist. We follow-up and removed the artifact handler for `ejb3`
and the `par` lifecycle [MNG-6014], [MNG-6017].
- * In previous Maven versions, there had been a larger problem related to
+- In previous Maven versions, there had been a larger problem related to
memory usage in case of very large reactors (200-300 modules or more)
which caused failures with out of memeory exceptions or the need to increase
the memory settings. This problem has been fixed with [MNG-6030].
- * If you have defined a property within the `.mvn/maven.config` file,
+- If you have defined a property within the `.mvn/maven.config` file,
it was not possible to overwrite the property via command line.
This has been fixed with [MNG-6078][MNG-6078].
- * If you have are using `<prerequisites>..</prerequisites>` for a non
+- If you have are using `<prerequisites>..</prerequisites>` for a non
maven-plugin project, you will get a WARNING which looks like this:
-
```
[INFO] Scanning for projects...
[WARNING] The project org.apache.maven:maven:pom:3.5.0-SNAPSHOT uses prerequisites which is only intended for maven-plugin projects but not for non maven-plugin projects. For such purposes you should use the maven-enforcer-plugin. See https://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html
@@ -139,94 +138,90 @@ Thank you also for your time and feedback.
you are expecting to build your project with, instead of using `prerequisites`
[MNG-5297], [MNG-6092].
- * Replaced Eclipse Aether with [Maven Resolver][maven-resolver]
+- Replaced Eclipse Aether with [Maven Resolver][maven-resolver]
[MNG-6110], [MNG-6140].
Improvements:
-
Bugs:
- * [MNG-5297] - Site should tell 'prerequisites.maven is deprecated'
- * [MNG-5368] - UnsupportedOperationException thrown when version range is not correct in dependencyManagement definitions
- * [MNG-5629] - ClosedChannelException from DefaultUpdateCheckManager.read
- * [MNG-5815] - "mvn.cmd" does not indicate failure properly when using "&&"
- * [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces - missing quotes
- * [MNG-5829] - mvn shell script fails with syntax error on Solaris 10
- * [MNG-5836] - logging config is overridden by $M2_HOME/lib/ext/*.jar
- * [MNG-5852] - mvn shell script invokes /bin/sh but requires Bash functions
- * [MNG-5958] - java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
- * [MNG-5961] - Maven possibly not aware of log4j2
- * [MNG-5962] - mvn.cmd fails when the current directory has spaces in between
- * [MNG-5963] - mvn.cmd does not return ERROR_CODE
- * [MNG-6022] - mvn.cmd fails if directory contains an ampersand (&)
- * [MNG-6053] - Unsafe System Properties copy in MavenRepositorySystemUtils, causing NPEs
- * [MNG-6105] - properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
- * [MNG-6109] - PluginDescriptor doesn't read since value of parameter
- * [MNG-6117] - ${session.parallel} not correctly set
- * [MNG-6144] - DefaultWagonManagerTest#testGetMissingJarForced() passed incorrect value
- * [MNG-6166] - mvn dependency:go-offline fails due to missing transitive dependency jdom:jdom:jar:1.1
- * [MNG-6171] - REGRESSION: WARNING about usage of a non threadsafe marked plugin is not showed anymore
- * [MNG-6172] - Precedence of command-line system property options has changed
+- [MNG-5297] - Site should tell 'prerequisites.maven is deprecated'
+- [MNG-5368] - UnsupportedOperationException thrown when version range is not correct in dependencyManagement definitions
+- [MNG-5629] - ClosedChannelException from DefaultUpdateCheckManager.read
+- [MNG-5815] - "mvn.cmd" does not indicate failure properly when using "&&"
+- [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces - missing quotes
+- [MNG-5829] - mvn shell script fails with syntax error on Solaris 10
+- [MNG-5836] - logging config is overridden by $M2_HOME/lib/ext/*.jar
+- [MNG-5852] - mvn shell script invokes /bin/sh but requires Bash functions
+- [MNG-5958] - java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
+- [MNG-5961] - Maven possibly not aware of log4j2
+- [MNG-5962] - mvn.cmd fails when the current directory has spaces in between
+- [MNG-5963] - mvn.cmd does not return ERROR_CODE
+- [MNG-6022] - mvn.cmd fails if directory contains an ampersand (&)
+- [MNG-6053] - Unsafe System Properties copy in MavenRepositorySystemUtils, causing NPEs
+- [MNG-6105] - properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
+- [MNG-6109] - PluginDescriptor doesn't read since value of parameter
+- [MNG-6117] - ${session.parallel} not correctly set
+- [MNG-6144] - DefaultWagonManagerTest#testGetMissingJarForced() passed incorrect value
+- [MNG-6166] - mvn dependency:go-offline fails due to missing transitive dependency jdom:jdom:jar:1.1
+- [MNG-6171] - REGRESSION: WARNING about usage of a non threadsafe marked plugin is not showed anymore
+- [MNG-6172] - Precedence of command-line system property options has changed
Dependency upgrade:
- * [MNG-5967] - Dependency updates
- * [MNG-6110] - Upgrade Aether to Maven Resolver
+- [MNG-5967] - Dependency updates
+- [MNG-6110] - Upgrade Aether to Maven Resolver
Improvements:
- * [MNG-5579] - Unify error output/check logic from shell and batch scripts
- * [MNG-5607] - Don't use M2_HOME in mvn shell/command scripts anymore
- * [MNG-5883] - Silence unnecessary legacy local repository warning
- * [MNG-5889] - .mvn directory should be picked when using --file
- * [MNG-5904] - Remove the whole Ant build
- * [MNG-5931] - Fixing documentation
- * [MNG-5934] - String handling issues identified by PMD
- * [MNG-5946] - Fix links etc. in README.txt which is part of the delivery
- * [MNG-5968] - Default plugin version updates
- * [MNG-5975] - Use Java 7's SimpleDateFormat in CLIReportingUtils#formatTimestamp
- * [MNG-5977] - Improve output readability of our MavenTransferListener implementations
- * [MNG-5993] - Confusing error message in case of missing/empty artifactId and version in pluginManagement
- * [MNG-6001] - Replace %HOME% with %USERPROFILE% in mvn.cmd
- * [MNG-6003] - Drastically reduce JAVA_HOME discovery code
- * [MNG-6014] - Removing ArtifactHandler for ejb3
- * [MNG-6017] - Removing ArtifactHandler for par LifeCycle
- * [MNG-6030] - ReactorModelCache do not used effectively after maven version 3.0.5 which cause a large memory footprint
- * [MNG-6032] - WARNING during build based on absolute path in assembly-descriptor.
- * [MNG-6068] - Document default scope compile in pom XSD and reference documentation
- * [MNG-6078] - Can't overwrite properties which have been defined in .mvn/maven.config
- * [MNG-6081] - Log refactoring - Method Invocation Replaced By Variable
- * [MNG-6102] - Introduce ${maven.conf} in m2.conf
- * [MNG-6145] - Remove non-existent m2 include in component.xml
- * [MNG-6146] - Several small stylistic and spelling improvements to code and documentation
- * [MNG-6147] - MetadataResolutionResult#getGraph() contains duplicate if clause
- * [MNG-6150] - Javadoc improvements for 3.5.0
- * [MNG-6163] - Introduce CLASSWORLDS_JAR in shell startup scripts
- * [MNG-6165] - Deprecate and replace incorrectly spelled public API
+- [MNG-5579] - Unify error output/check logic from shell and batch scripts
+- [MNG-5607] - Don't use M2_HOME in mvn shell/command scripts anymore
+- [MNG-5883] - Silence unnecessary legacy local repository warning
+- [MNG-5889] - .mvn directory should be picked when using --file
+- [MNG-5904] - Remove the whole Ant build
+- [MNG-5931] - Fixing documentation
+- [MNG-5934] - String handling issues identified by PMD
+- [MNG-5946] - Fix links etc. in README.txt which is part of the delivery
+- [MNG-5968] - Default plugin version updates
+- [MNG-5975] - Use Java 7's SimpleDateFormat in CLIReportingUtils#formatTimestamp
+- [MNG-5977] - Improve output readability of our MavenTransferListener implementations
+- [MNG-5993] - Confusing error message in case of missing/empty artifactId and version in pluginManagement
+- [MNG-6001] - Replace %HOME% with %USERPROFILE% in mvn.cmd
+- [MNG-6003] - Drastically reduce JAVA_HOME discovery code
+- [MNG-6014] - Removing ArtifactHandler for ejb3
+- [MNG-6017] - Removing ArtifactHandler for par LifeCycle
+- [MNG-6030] - ReactorModelCache do not used effectively after maven version 3.0.5 which cause a large memory footprint
+- [MNG-6032] - WARNING during build based on absolute path in assembly-descriptor.
+- [MNG-6068] - Document default scope compile in pom XSD and reference documentation
+- [MNG-6078] - Can't overwrite properties which have been defined in .mvn/maven.config
+- [MNG-6081] - Log refactoring - Method Invocation Replaced By Variable
+- [MNG-6102] - Introduce ${maven.conf} in m2.conf
+- [MNG-6145] - Remove non-existent m2 include in component.xml
+- [MNG-6146] - Several small stylistic and spelling improvements to code and documentation
+- [MNG-6147] - MetadataResolutionResult#getGraph() contains duplicate if clause
+- [MNG-6150] - Javadoc improvements for 3.5.0
+- [MNG-6163] - Introduce CLASSWORLDS_JAR in shell startup scripts
+- [MNG-6165] - Deprecate and replace incorrectly spelled public API
New Feature:
- * [MNG-3507] - ANSI color logging for improved output visibility
- * [MNG-5878] - add support for module name != artifactId in every calculated URLs (project, SCM, site): special project.directory property
- * [MNG-6093] - create a slf4j-simple provider extension that supports level color rendering Task
- * [MNG-5954] - Remove outdated maven-embedder/src/main/resources/META-INF/MANIFEST.MF
- * [MNG-6106] - Remove maven.home default value setter from m2.conf
- * [MNG-6136] - Upgrade Maven Wagon from 2.10 to 2.12
- * [MNG-6137] - Clean up duplicate dependencies caused by incomplete Wagon HTTP Provider exclusions
- * [MNG-6138] - Remove obsolete message_*.properties form maven-core
- * [MNG-6140] - update documentation's dependency graph with resolver + resolver-provider + slf4j-provider
- * [MNG-6151] - Force Push master from 737de43e392fc15a0ce366db98d70aa18b3f6c03
- * [MNG-6152] - Add a Jenkinsfile so that builds.apache.org can use multibranch pipeline
+- [MNG-3507] - ANSI color logging for improved output visibility
+- [MNG-5878] - add support for module name != artifactId in every calculated URLs (project, SCM, site): special project.directory property
+- [MNG-6093] - create a slf4j-simple provider extension that supports level color rendering Task
+- [MNG-5954] - Remove outdated maven-embedder/src/main/resources/META-INF/MANIFEST.MF
+- [MNG-6106] - Remove maven.home default value setter from m2.conf
+- [MNG-6136] - Upgrade Maven Wagon from 2.10 to 2.12
+- [MNG-6137] - Clean up duplicate dependencies caused by incomplete Wagon HTTP Provider exclusions
+- [MNG-6138] - Remove obsolete message_*.properties form maven-core
+- [MNG-6140] - update documentation's dependency graph with resolver + resolver-provider + slf4j-provider
+- [MNG-6151] - Force Push master from 737de43e392fc15a0ce366db98d70aa18b3f6c03
+- [MNG-6152] - Add a Jenkinsfile so that builds.apache.org can use multibranch pipeline
Wishes:
- * [MNG-2199] - Support version ranges in parent elements
- * [MNG-6088] - after forked execution success, add an empty line
- * [MNG-6092] - warn if prerequisites.maven is used for non-plugin projects
-
-
-
+- [MNG-2199] - Support version ranges in parent elements
+- [MNG-6088] - after forked execution success, add an empty line
+- [MNG-6092] - warn if prerequisites.maven is used for non-plugin projects
The full list of changes can be found in our [issue management system][4].
@@ -236,13 +231,8 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
-[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12339664&styleName=Text
[5]: ../../docs/history.html
-[maven-enforcer-plugin]: /enforcer/maven-enforcer-plugin/
-[maven-resources-plugin]: /enforcer/maven-resources-plugin/
-[maven-aether-provider]: /ref/3.5.0-alpha-1/maven-aether-provider/
-[maven-compat]: /ref/3.5.0-alpha-1/maven-compat/
[maven-resolver]: /resolver/
[MNG-2199]: https://issues.apache.org/jira/browse/MNG-2199
diff --git a/content/markdown/docs/3.5.0-beta-1/release-notes.md b/content/markdown/docs/3.5.0-beta-1/release-notes.md
index 5ad1b536..95954465 100644
--- a/content/markdown/docs/3.5.0-beta-1/release-notes.md
+++ b/content/markdown/docs/3.5.0-beta-1/release-notes.md
@@ -45,10 +45,9 @@ We hope you enjoy using Maven! If you have any questions, please consult:
The following issues were identified during release testing of this _BETA_ release but have not been deemed as release blockers:
-* [MNG-6190] maven-resolver-provider's `DefaultArtifactDescriptorReader` has mismatched constructor and initService methods (this issue does not affect normal usage of Maven)
-* [MNG-6191] `mvn -f` complains about illegal `readlink` option under macOS
-* [MNG-6192] The distribution zip file has unordered entries and some tools - most notably Maven wrapper - will fail to unzip the distribution
-
+- [MNG-6190] maven-resolver-provider's `DefaultArtifactDescriptorReader` has mismatched constructor and initService methods (this issue does not affect normal usage of Maven)
+- [MNG-6191] `mvn -f` complains about illegal `readlink` option under macOS
+- [MNG-6192] The distribution zip file has unordered entries and some tools - most notably Maven wrapper - will fail to unzip the distribution
## Why not Maven 3.4.0?
@@ -68,8 +67,8 @@ More detail on this decision can be read in the [mailing list archive](http://ww
Bugs:
- * [MNG-6090] reporter: Harald Wellmann
- * [MNG-6173] reporter/contributor: Christoph Böhme
+- [MNG-6090] reporter: Harald Wellmann
+- [MNG-6173] reporter/contributor: Christoph Böhme
Many thanks to all reporters and contributors for their time and support.
@@ -79,43 +78,43 @@ Thank you also for your time and feedback.
## Overview about the changes
- * The most obvious change you may encounter is that the console output
+- The most obvious change you may encounter is that the console output
has colors now [MNG-3507], [MNG-6093].
- * The new `project.directory` special property adds support in every calculated URLs (project, SCM, site)
+- The new `project.directory` special property adds support in every calculated URLs (project, SCM, site)
for module directory name that does not match artifactId [MNG-5878]
- * The `JAVA_HOME` discovery has been reduced to simply check if `JAVA_HOME` is set
+- The `JAVA_HOME` discovery has been reduced to simply check if `JAVA_HOME` is set
or not then trying to discover via `which java`, nothing more [MNG-6003].
- * The build bootstrapping support via Apache Ant has been removed. You can now only bootstrap Maven
+- The build bootstrapping support via Apache Ant has been removed. You can now only bootstrap Maven
build with a previous version of Maven, but not with Ant any more [MNG-5904].
- * Based on problems in using `M2_HOME` related to different Maven versions installed and
+- Based on problems in using `M2_HOME` related to different Maven versions installed and
to simplify things, the usage of `M2_HOME` has been removed and is not
supported any more [MNG-5823], [MNG-5836], [MNG-5607].
- * Important change for windows users: The usage of `%HOME%` has been replaced
+- Important change for windows users: The usage of `%HOME%` has been replaced
with `%USERPROFILE%` [MNG-6001]
- * Several issues have been reported and fixed related to the `mvn` script either
+- Several issues have been reported and fixed related to the `mvn` script either
for Unix/Linux/Cygwin/Solaris or for Windows
[MNG-5815], [MNG-5852], [MNG-5963], [MNG-6022].
- * In Maven 3.3.9, we have removed bindings for maven-ejb3-plugin because it
+- In Maven 3.3.9, we have removed bindings for maven-ejb3-plugin because it
does not exist. We follow-up and removed the artifact handler for `ejb3`
and the `par` lifecycle [MNG-6014], [MNG-6017].
- * In previous Maven versions, there had been a larger problem related to
+- In previous Maven versions, there had been a larger problem related to
memory usage in case of very large reactors (200-300 modules or more)
which caused failures with out of memory exceptions or the need to increase
the memory settings. This problem has been fixed with [MNG-6030].
- * If you have defined a property within the `.mvn/maven.config` file,
+- If you have defined a property within the `.mvn/maven.config` file,
it was not possible to overwrite the property via command line.
This has been fixed with [MNG-6078][MNG-6078].
- * If you have are using `<prerequisites>..</prerequisites>` for a non
+- If you have are using `<prerequisites>..</prerequisites>` for a non
maven-plugin project, you will get a WARNING which looks like this:
```
@@ -127,42 +126,42 @@ Thank you also for your time and feedback.
you are expecting to build your project with, instead of using `prerequisites`
[MNG-5297], [MNG-6092].
- * Replaced Eclipse Aether with [Maven Resolver][maven-resolver]
+- Replaced Eclipse Aether with [Maven Resolver][maven-resolver]
[MNG-6110], [MNG-6140].
- * Using of CI friendly versions via `${revision}`, `${sha1}` and/or `${changelist}`
+- Using of CI friendly versions via `${revision}`, `${sha1}` and/or `${changelist}`
has been fixed [MNG-6057], [MNG-6090] and [MNG-5895]. It is very important to
know if you are using the previously named properties for a version in your
pom you have to use [flatten-maven-plugin] if you like to do an `mvn install`
or `mvn deploy` more details can be found at [Maven CI Friendly](/maven-ci-friendly.html).
- * The two known issues from 3.5.0-alpha-1 have been fixed [MNG-6177], [MNG-6115]
+- The two known issues from 3.5.0-alpha-1 have been fixed [MNG-6177], [MNG-6115]
Improvements:
Bugs:
-* [MNG-5895] - Problem with CI friendly usage of ${..} which is already defined via property in pom file.
-* [MNG-6057] - Problem with CI friendly usage of ${..} reactor order is changed
-* [MNG-6090] - CI friendly properties break submodule builds
-* [MNG-6170] - NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
-* [MNG-6173] - MavenSession.getAllProjects() should return all projects in the reactor
-* [MNG-6176] - Javadoc errors prevent release with Java 8
-* [MNG-6177] - The --file command line option of the Windows and Unix launchers does not work for directory names like "Spaces & Special Char"
-* [MNG-6180] - groupId has plain color when goal fails
-* [MNG-6181] - HttpClient produces a lot of noise at debug loglevel
-* [MNG-6183] - Dependency management debug message corrections.
+- [MNG-5895] - Problem with CI friendly usage of ${..} which is already defined via property in pom file.
+- [MNG-6057] - Problem with CI friendly usage of ${..} reactor order is changed
+- [MNG-6090] - CI friendly properties break submodule builds
+- [MNG-6170] - NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
+- [MNG-6173] - MavenSession.getAllProjects() should return all projects in the reactor
+- [MNG-6176] - Javadoc errors prevent release with Java 8
+- [MNG-6177] - The --file command line option of the Windows and Unix launchers does not work for directory names like "Spaces & Special Char"
+- [MNG-6180] - groupId has plain color when goal fails
+- [MNG-6181] - HttpClient produces a lot of noise at debug loglevel
+- [MNG-6183] - Dependency management debug message corrections.
Improvements:
-* [MNG-6078] - Can't overwrite properties which have been defined in .mvn/maven.config
-* [MNG-6115] - Add Jansi native library search path to our start scripts to avoid extraction to temp file on each run
-* [MNG-6179] - Remove unused prerequisites
-* [MNG-6189] - WARN if maven-site-plugin configuration contains reportPlugins element
+- [MNG-6078] - Can't overwrite properties which have been defined in .mvn/maven.config
+- [MNG-6115] - Add Jansi native library search path to our start scripts to avoid extraction to temp file on each run
+- [MNG-6179] - Remove unused prerequisites
+- [MNG-6189] - WARN if maven-site-plugin configuration contains reportPlugins element
New Feature:
-* [MNG-6182] - ModelResolver interface enhancement: addition of resolveModel( Dependency ) supporting version ranges
+- [MNG-6182] - ModelResolver interface enhancement: addition of resolveModel( Dependency ) supporting version ranges
The full list of changes can be found in our [issue management system][4].
@@ -172,13 +171,8 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
-[2]: http://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12339664&styleName=Text
[5]: ../../docs/history.html
-[maven-enforcer-plugin]: /enforcer/maven-enforcer-plugin/
-[maven-resources-plugin]: /enforcer/maven-resources-plugin/
-[maven-aether-provider]: /ref/3.5.0-alpha-1/maven-aether-provider/
-[maven-compat]: /ref/3.5.0-alpha-1/maven-compat/
[maven-resolver]: /resolver/
[MNG-3507]: https://issues.apache.org/jira/browse/MNG-3507
diff --git a/content/markdown/docs/3.5.0/release-notes.md b/content/markdown/docs/3.5.0/release-notes.md
index 93e72f20..4fbf31e6 100644
--- a/content/markdown/docs/3.5.0/release-notes.md
+++ b/content/markdown/docs/3.5.0/release-notes.md
@@ -75,16 +75,16 @@ Many thanks to all reporters and contributors for their time and support.
The following members of the Maven community provided valuable feedback during the release process:
-* Grzegorz Grzybek
-* Petr Široký
-* Mark Derricutt,
-* Dejan Stojadinović
-* Thomas Collignon
-* Fred Cooke
-* Raphael Ackermann
-* Elliot Metsger
-* Chas Honton
-* Dennis Kieselhorst
+- Grzegorz Grzybek
+- Petr Široký
+- Mark Derricutt,
+- Dejan Stojadinović
+- Thomas Collignon
+- Fred Cooke
+- Raphael Ackermann
+- Elliot Metsger
+- Chas Honton
+- Dennis Kieselhorst
Thank you for your time and feedback.
@@ -242,11 +242,8 @@ See [complete release notes for all versions][7]
[6]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12336084&styleName=Text
[7]: ../../docs/history.html
[flatten-maven-plugin]: https://www.mojohaus.org/flatten-maven-plugin/
-[maven-aether-provider]: /ref/3.5.0/maven-aether-provider/
-[maven-compat]: /ref/3.5.0/maven-compat/
[maven-enforcer-plugin]: /enforcer/maven-enforcer-plugin/
[maven-resolver]: /resolver/
-[MNG-2199]: https://issues.apache.org/jira/browse/MNG-2199
[MNG-3507]: https://issues.apache.org/jira/browse/MNG-3507
[MNG-5297]: https://issues.apache.org/jira/browse/MNG-5297
[MNG-5368]: https://issues.apache.org/jira/browse/MNG-5368
@@ -266,7 +263,6 @@ See [complete release notes for all versions][7]
[MNG-5931]: https://issues.apache.org/jira/browse/MNG-5931
[MNG-5934]: https://issues.apache.org/jira/browse/MNG-5934
[MNG-5946]: https://issues.apache.org/jira/browse/MNG-5946
-[MNG-5954]: https://issues.apache.org/jira/browse/MNG-5954
[MNG-5958]: https://issues.apache.org/jira/browse/MNG-5958
[MNG-5961]: https://issues.apache.org/jira/browse/MNG-5961
[MNG-5962]: https://issues.apache.org/jira/browse/MNG-5962
@@ -283,35 +279,24 @@ See [complete release notes for all versions][7]
[MNG-6022]: https://issues.apache.org/jira/browse/MNG-6022
[MNG-6030]: https://issues.apache.org/jira/browse/MNG-6030
[MNG-6032]: https://issues.apache.org/jira/browse/MNG-6032
-[MNG-6053]: https://issues.apache.org/jira/browse/MNG-6053
[MNG-6057]: https://issues.apache.org/jira/browse/MNG-6057
[MNG-6068]: https://issues.apache.org/jira/browse/MNG-6068
[MNG-6078]: https://issues.apache.org/jira/browse/MNG-6078
[MNG-6081]: https://issues.apache.org/jira/browse/MNG-6081
-[MNG-6088]: https://issues.apache.org/jira/browse/MNG-6088
[MNG-6090]: https://issues.apache.org/jira/browse/MNG-6090
[MNG-6092]: https://issues.apache.org/jira/browse/MNG-6092
[MNG-6093]: https://issues.apache.org/jira/browse/MNG-6093
[MNG-6102]: https://issues.apache.org/jira/browse/MNG-6102
[MNG-6105]: https://issues.apache.org/jira/browse/MNG-6105
-[MNG-6106]: https://issues.apache.org/jira/browse/MNG-6106
[MNG-6109]: https://issues.apache.org/jira/browse/MNG-6109
[MNG-6110]: https://issues.apache.org/jira/browse/MNG-6110
[MNG-6115]: https://issues.apache.org/jira/browse/MNG-6115
[MNG-6117]: https://issues.apache.org/jira/browse/MNG-6117
-[MNG-6136]: https://issues.apache.org/jira/browse/MNG-6136
-[MNG-6137]: https://issues.apache.org/jira/browse/MNG-6137
-[MNG-6138]: https://issues.apache.org/jira/browse/MNG-6138
[MNG-6140]: https://issues.apache.org/jira/browse/MNG-6140
[MNG-6144]: https://issues.apache.org/jira/browse/MNG-6144
[MNG-6145]: https://issues.apache.org/jira/browse/MNG-6145
[MNG-6146]: https://issues.apache.org/jira/browse/MNG-6146
[MNG-6147]: https://issues.apache.org/jira/browse/MNG-6147
-[MNG-6150]: https://issues.apache.org/jira/browse/MNG-6150
-[MNG-6151]: https://issues.apache.org/jira/browse/MNG-6151
-[MNG-6152]: https://issues.apache.org/jira/browse/MNG-6152
-[MNG-6163]: https://issues.apache.org/jira/browse/MNG-6163
-[MNG-6165]: https://issues.apache.org/jira/browse/MNG-6165
[MNG-6166]: https://issues.apache.org/jira/browse/MNG-6166
[MNG-6168]: https://issues.apache.org/jira/browse/MNG-6168
[MNG-6170]: https://issues.apache.org/jira/browse/MNG-6170
@@ -320,13 +305,9 @@ See [complete release notes for all versions][7]
[MNG-6173]: https://issues.apache.org/jira/browse/MNG-6173
[MNG-6176]: https://issues.apache.org/jira/browse/MNG-6176
[MNG-6177]: https://issues.apache.org/jira/browse/MNG-6177
-[MNG-6179]: https://issues.apache.org/jira/browse/MNG-6179
[MNG-6180]: https://issues.apache.org/jira/browse/MNG-6180
[MNG-6181]: https://issues.apache.org/jira/browse/MNG-6181
-[MNG-6182]: https://issues.apache.org/jira/browse/MNG-6182
[MNG-6183]: https://issues.apache.org/jira/browse/MNG-6183
-[MNG-6185]: https://issues.apache.org/jira/browse/MNG-6185
-[MNG-6189]: https://issues.apache.org/jira/browse/MNG-6189
[MNG-6190]: https://issues.apache.org/jira/browse/MNG-6190
[MNG-6191]: https://issues.apache.org/jira/browse/MNG-6191
[MNG-6192]: https://issues.apache.org/jira/browse/MNG-6192
diff --git a/content/markdown/docs/3.5.2/release-notes.md b/content/markdown/docs/3.5.2/release-notes.md
index 11632a81..911923cf 100644
--- a/content/markdown/docs/3.5.2/release-notes.md
+++ b/content/markdown/docs/3.5.2/release-notes.md
@@ -37,19 +37,19 @@ We hope you enjoy using Maven! If you have any questions, please consult:
Bugs:
-* Marcel Schutte (reporter)
-* Mario Krizmanic (reporter, contributor)
-* Charles Gould (reporter)
-* Brian Oxley (reporter)
-* Dejan Stojadinovic (contributor)
+- Marcel Schutte (reporter)
+- Mario Krizmanic (reporter, contributor)
+- Charles Gould (reporter)
+- Brian Oxley (reporter)
+- Dejan Stojadinovic (contributor)
Improvements:
-* Anton Tanasenko (reporter, contributor)
-* Gregor B. Rosenauer (reporter)
-* Sylwester Lachiewicz (reporter)
-* Stefan Eicher (reporter, contributor)
-* Manuel Ryan (reporter)
+- Anton Tanasenko (reporter, contributor)
+- Gregor B. Rosenauer (reporter)
+- Sylwester Lachiewicz (reporter)
+- Stefan Eicher (reporter, contributor)
+- Manuel Ryan (reporter)
Many thanks to all reporters and contributors and for their time and support.
@@ -57,13 +57,13 @@ Many thanks to all reporters and contributors and for their time and support.
The following members of the Maven community provided valuable feedback during the release process:
-* Mark Derricutt
-* Dejan Stojadinovic
-* Thomas Collignon
-* Grzegorz Grzybek
-* Petar Tahchiev
-* jieryn
-* Petr Široký
+- Mark Derricutt
+- Dejan Stojadinovic
+- Thomas Collignon
+- Grzegorz Grzybek
+- Petar Tahchiev
+- jieryn
+- Petr Široký
Thank you for your time and feedback.
@@ -86,10 +86,12 @@ The full list of changes as well as detailed descriptions of same can be found i
- [MNG-6242][] - No color for maven on Cygwin
### Sub-tasks
+
- [MNG-6186][] - switch to improved HawtJNI
- [MNG-6280][] - ArrayIndexOutOfBoundsException caused by pom.xml with process instructions
### Improvements
+
- [MNG-5457][] - Show repository id when downloading or uploading from/to a remote repository
- [MNG-6025][] - Add a ProjectArtifactsCache similar to PluginArtifactsCache
- [MNG-6123][] - detect self references in POM and fail fast
@@ -101,10 +103,12 @@ The full list of changes as well as detailed descriptions of same can be found i
- [MNG-6228][] - Optionality not displayed in dependency tree when run in debug mode
### New Features
+
- [MNG-6084][] - Support JSR 250 annotations
- [MNG-6220][] - Add CLI options to control color output
### Tasks
+
- [MNG-6167][] - Clean up dependency mess (reported by dependency:analyze)
- [MNG-6258][] - Upgrade to Maven Resolver 1.1.0
diff --git a/content/markdown/docs/3.5.3/release-notes.md b/content/markdown/docs/3.5.3/release-notes.md
index 45275985..51b735f6 100644
--- a/content/markdown/docs/3.5.3/release-notes.md
+++ b/content/markdown/docs/3.5.3/release-notes.md
@@ -179,7 +179,6 @@ See [complete release notes for all versions][5]
[0]: ../../download.html
[1]: ../../plugins/index.html
[2]: https://maven.apache.org/
-[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12341428
[5]: ../../docs/history.html
[MNG-5992]: https://issues.apache.org/jira/browse/MNG-5992
[MNG-6188]: https://issues.apache.org/jira/browse/MNG-6188
diff --git a/content/markdown/docs/3.5.4/release-notes.md b/content/markdown/docs/3.5.4/release-notes.md
index 5b2fbf90..e0d53219 100644
--- a/content/markdown/docs/3.5.4/release-notes.md
+++ b/content/markdown/docs/3.5.4/release-notes.md
@@ -39,7 +39,7 @@ We really value the contributions of these non committers, so this section is fo
Bugs:
-- [MNG-6370][] reporter and contributor: Sylwester Lachiewicz
+- [MNG-6370][] reporter and contributor: Sylwester Lachiewicz
- [MNG-6382][] reporter: Falko Modler
- [MNG-6388][] reporter: Mike Kelly
- [MNG-6410][] reporter and contributor: Łukasz Dywicki
@@ -75,6 +75,7 @@ There are some additional minor improvements, the most notable of which is:
## [The detailed issue list](#details)
### Bugs
+
- [MNG-6370][] `ConcurrencyDependencyGraph#getNumberOfBuilds()` does not remove finished projects from unfinished ones
- [MNG-6372][] On Windows Maven can output spurious ANSI escapes such as `[0m [0m`
- [MNG-6382][] JANSI fails frequently with `NumberFormatException` when building in parallel
@@ -84,6 +85,7 @@ There are some additional minor improvements, the most notable of which is:
- [MNG-6410][] Add `groupId` to `--resume-from` suggestion if `artifactId` is not unique in reactor
### Improvements
+
- [MNG-5756][] Java home output in `mvn -v` is misleading
- [MNG-5940][] Change the `maven-source-plugin` `jar` goal into `jar-no-fork` in Maven Super POM
- [MNG-6362][] Add documentation information for GitHub
@@ -92,9 +94,11 @@ There are some additional minor improvements, the most notable of which is:
- [MNG-6411][] Improve readability of project list returned when `--resume-from` option value is invalid
### Tasks
+
- [MNG-6377][] switch from Git-WIP to Gitbox
### Dependency upgrades
+
- [MNG-6344][] Upgrade Guice to 4.2.0
- [MNG-6423][] Upgrade to Wagon 3.1.0
diff --git a/content/markdown/docs/3.6.0/release-notes.md b/content/markdown/docs/3.6.0/release-notes.md
index a9d034cd..3e5437b7 100644
--- a/content/markdown/docs/3.6.0/release-notes.md
+++ b/content/markdown/docs/3.6.0/release-notes.md
@@ -41,22 +41,22 @@ the [end of these release notes](#details).
Code Contributors of this release:
- * [MNG-6383] Christoph Kunze
- * [MNG-6311] David Churcher
+- [MNG-6383] Christoph Kunze
+- [MNG-6311] David Churcher
Issue Reporters of this release:
- * [MNG-4508] Richard van der Hoff
- * [MNG-5951] Jörg Sesterhenn
- * [MNG-6311] David Churcher
- * [MNG-6358] Adam John Burley
- * [MNG-6383] Christoph Kunze
- * [MNG-6391] Alexander Griesbaum
- * [MNG-6412] Christoph Amshoff
- * [MNG-6415] Seckin Onur Selamet
- * [MNG-6475] Phillip Webb
- * [MNG-6490] John Canny
- * [MNG-6492] Hoa Phan
+- [MNG-4508] Richard van der Hoff
+- [MNG-5951] Jörg Sesterhenn
+- [MNG-6311] David Churcher
+- [MNG-6358] Adam John Burley
+- [MNG-6383] Christoph Kunze
+- [MNG-6391] Alexander Griesbaum
+- [MNG-6412] Christoph Amshoff
+- [MNG-6415] Seckin Onur Selamet
+- [MNG-6475] Phillip Webb
+- [MNG-6490] John Canny
+- [MNG-6492] Hoa Phan
Many thanks to all reporters and contributors for their time and support.
@@ -64,7 +64,7 @@ Many thanks to all reporters and contributors for their time and support.
Thanks to the following preliminary testers:
-- Filipe Sousa
+- Filipe Sousa
- Eric Lilja
- Enrico Olivelli
- Gary Gregory
@@ -80,7 +80,7 @@ At the time of release, there are no known regressions introduced by this releas
been increased in previous version which influenced some of our users.
This should have been fixed [MNG-6311], [MNG-6383] and [MNG-6412].
-- The output in the reactor summary has been improved [MNG-6391]
+- The output in the reactor summary has been improved [MNG-6391]
cause it confused people. In Maven 3.6.0 the reactor summary now
looks like the following:
@@ -105,12 +105,13 @@ At the time of release, there are no known regressions introduced by this releas
[INFO] ------------------------------------------------------------------------
```
- The `parent` in the above output is the artifact name of the root module and
+ The `parent` in the above output is the artifact name of the root module and
the `5.0.4-SNAPSHOT` is the versions number for all modules in this
reactor build.
If you have an aggregator pom which contains different modules with different
versions each line will contain the appropriate versions which looks like this:
+
```
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
@@ -128,12 +129,12 @@ At the time of release, there are no known regressions introduced by this releas
...
```
-- There was an issue related to the classpath ordering [MNG-6415] in Maven which
+- There was an issue related to the classpath ordering [MNG-6415] in Maven which
can cause issues which has been fixed.
## [The detailed issue list](#details)
-### Bugs:
+### Bugs
- [MNG-6311] - Maven intolerably slow when import scope used heavily in large project
- [MNG-6358] - Maven build should not require access to apache.org
@@ -143,7 +144,7 @@ At the time of release, there are no known regressions introduced by this releas
- [MNG-6472] - Mockito cannot mock this class: interface org.eclipse.aether.impl.RepositoryEventDispatcher
- [MNG-6490] - Maven shall not fail reporting circular dependency when the dependency is a classified secondary artifact
-### Improvements:
+### Improvements
- [MNG-4508] - No way to avoid adding artifactId to site urls
- [MNG-5951] - add an option to avoid path addition to inherited URLs
diff --git a/content/markdown/docs/3.6.1/release-notes.md b/content/markdown/docs/3.6.1/release-notes.md
index 7d32def7..f7bce3be 100644
--- a/content/markdown/docs/3.6.1/release-notes.md
+++ b/content/markdown/docs/3.6.1/release-notes.md
@@ -41,38 +41,37 @@ the [end of these release notes](#details).
Issue Reporters of this release:
- * [MNG-5705] Ondra Žižka
- * [MNG-5965] Matthias Schmalz
- * [MNG-6059] Andreas Sewe
- * [MNG-6159] Christian Aistleitner
- * [MNG-6213] Jin Kwon
- * [MNG-6256] Christoph Etzel
- * [MNG-6261] Dawid Weiss
- * [MNG-6262] Gene Smith
- * [MNG-6346] Patrik Jetzer
- * [MNG-6374] Rohan Padhye
- * [MNG-6495] Elliotte Rusty Harold
- * [MNG-6506] Andreas Veithen
- * [MNG-6526] Olaf Otto
- * [MNG-6529] Michael Istria
- * [MNG-6530] Michael Istria
- * [MNG-6533] Michael Istria
- * [MNG-6543] Romain Manni-Bucau
- * [MNG-6558] Guy Brand
- * [MNG-6577] Rohan Padhye
- * [MNG-6591] Olaf Otto
- * [MNG-6605] Gunnar Wagenknecht
- * [MNG-6618] Viacheslav Yakunin
+- [MNG-5705] Ondra Žižka
+- [MNG-5965] Matthias Schmalz
+- [MNG-6059] Andreas Sewe
+- [MNG-6159] Christian Aistleitner
+- [MNG-6213] Jin Kwon
+- [MNG-6256] Christoph Etzel
+- [MNG-6261] Dawid Weiss
+- [MNG-6262] Gene Smith
+- [MNG-6346] Patrik Jetzer
+- [MNG-6374] Rohan Padhye
+- [MNG-6495] Elliotte Rusty Harold
+- [MNG-6506] Andreas Veithen
+- [MNG-6526] Olaf Otto
+- [MNG-6529] Michael Istria
+- [MNG-6530] Michael Istria
+- [MNG-6533] Michael Istria
+- [MNG-6543] Romain Manni-Bucau
+- [MNG-6558] Guy Brand
+- [MNG-6577] Rohan Padhye
+- [MNG-6591] Olaf Otto
+- [MNG-6605] Gunnar Wagenknecht
+- [MNG-6618] Viacheslav Yakunin
Code Contributors of this release:
- * [MNG-6374] Gabriel Belingueres (indirectly via plexus-utils PR)
- * [MNG-6529] Michael Istria
- * [MNG-6530] Michael Istria
- * [MNG-6558] Guy Brand
- * [MNG-6261] Fabiano C. de Oliveira
- * [MNG-6533] Michael Istria
-
+- [MNG-6374] Gabriel Belingueres (indirectly via plexus-utils PR)
+- [MNG-6529] Michael Istria
+- [MNG-6530] Michael Istria
+- [MNG-6558] Guy Brand
+- [MNG-6261] Fabiano C. de Oliveira
+- [MNG-6533] Michael Istria
Many thanks to all reporters and contributors for their time and support.
@@ -82,16 +81,16 @@ Many thanks to all reporters and contributors for their time and support.
Thanks to the following preliminary testers:
- * Gabriel Belingueres
- * Francois Papon
- * Eric Lilja
+- Gabriel Belingueres
+- Francois Papon
+- Eric Lilja
## Known Issues
- * New attributes for URLs inheritance (see [User Visible Changes](./release-notes.html#User_visible_Changes)) are not yet
+- New attributes for URLs inheritance (see [User Visible Changes](./release-notes.html#User_visible_Changes)) are not yet
accepted during POM structure control on [upload to the Central Repository](/repository/guide-central-repository-upload.html):
see [MVNCENTRAL-4841](https://issues.sonatype.org/browse/MVNCENTRAL-4841) to track progress
- * If you are using Maven reporting, it might happen that you will get an exception which looks like this:
+- If you are using Maven reporting, it might happen that you will get an exception which looks like this:
```
[INFO] Scanning for projects...
@@ -104,7 +103,7 @@ Caused by: java.lang.NullPointerException
...
```
-This is caused by using a `<reportSet>..</reportSet>` which does not contain
+This is caused by using a `<reportSet>..</reportSet>` which does not contain
a `<report></report>` element.
Temporarily this issue can circumvented by adding an empty `<report></report>` element
@@ -121,18 +120,17 @@ inside the `<reportSet></reportSet>`.
executions of phases. This has been fixed with [MNG-5965].
- NullPointerException related to call in parallel build like `mvn -T 1C clean javadoc:aggregate`
- [MNG-5705]
+ [MNG-5705]
-- A performance issue related to artifact transfer has been found related to [WAGON-537]. It
+- A performance issue related to artifact transfer has been found related to [WAGON-537]. It
has been solved via the update to [Maven Wagon 3.3.1][MNG-6526].
- There had been issues related calling Maven script like this: `mvn -f ..`
- - Having parentheses within the path, which has been fixed with [MNG-6346].
- - Script can break having special characters as part of the path, which has
+ - Having parentheses within the path, which has been fixed with [MNG-6346].
+ - Script can break having special characters as part of the path, which has
been solved with [MNG-6256].
-
-- Issue related to the Maven Resolver API which broke some IDEs (for example https://youtrack.jetbrains.com/issue/IDEA-201282);
+- Issue related to the Maven Resolver API which broke some IDEs (for example <https://youtrack.jetbrains.com/issue/IDEA-201282>);
this has been fixed by [MNG-6538].
- Issue related to missing event for ToolchainsBuildingResult on EventSpy [MNG-6558].
@@ -147,22 +145,22 @@ inside the `<reportSet></reportSet>`.
- Missing export for org.slf4j.event.Level has been done with [MNG-6618]
-
## User visible Changes
- - Maven has now a an option to suppress the transfer progress when downloading/uploading
+- Maven has now a an option to suppress the transfer progress when downloading/uploading
in interactive mode.
```
mvn --no-transfer-progress ....
```
+
or in short:
```
mvn -ntp ... ....
```
- - There had been an issues like [MNG-6505] and [MNG-6059] related to the construction of
+- There had been an issues like [MNG-6505] and [MNG-6059] related to the construction of
URL's etc. within `project`, `distributionManagement` and `scm` part in the pom for multi module
builds like this:
@@ -188,68 +186,66 @@ builds like this:
Detailed explanations can be found in [Inheritance Assembly][inheritance-assembly] and in [MNG-6059]
-
[inheritance-assembly]: https://maven.apache.org/ref/3.6.1/maven-model-builder/index.html#Inheritance_Assembly
## The detailed issue list[](#details)
-### Bugs:
-
- - [MNG-5705] - NPE on parallel build in BuilderCommon.handleBuildError(BuilderCommon.java:147)
- - [MNG-5965] - Parallel build multiplies work if multiple goals are given
- - [MNG-5995] - Maven itself cannot run without maven-compat
- - [MNG-6256] - Maven script can break if "-f" path contains special characters
- - [MNG-6261] - Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
- - [MNG-6262] - getCanonicalFile() is not used consistently during project resolution
- - [MNG-6346] - ... was unexpected at this time when using -f option and path contains brackets
- - [MNG-6374] - ModelBuilder hangs with malformed pom.xml
- - [MNG-6429] - Integration Test site publishing requires Java 7 (or javadoc errors ignored)
- - [MNG-6495] - ModelResolver cannot be null
- - [MNG-6505] - child.(x.y).inherit.append.path value should be inherited
- - [MNG-6506] - Mojos are unable to load package annotations on Java >= 9
- - [MNG-6529] - `ProjectBuilder.build(List<File> projects, boolean, ProjectBuildingRequest)` doesn't honor `ProjectBuildingRequest.isResolveDependencies()`
- - [MNG-6530] - Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
- - [MNG-6533] - `ProjectBuilder.build(list_of_projects,...)` does not contain MavenProject in exception report
- - [MNG-6543] - Upgrade plexus classworld to support java 9+ `ClassLoader.findClass(String moduleName, String name)` in Mojos
- - [MNG-6558] - ToolchainsBuildingResult event is not sent on EventSpy
- - [MNG-6577] - pom.xml: Uncaught IllegalArgumentException when parsing unicode entity ref
- - [MNG-6590] - DefaultProjectArtifactsCache java.lang.IllegalStateException: Duplicate artifact resolution result
- - [MNG-6599] - unknown version in model id when version is defined from parent
+### Bugs
+
+- [MNG-5705] - NPE on parallel build in BuilderCommon.handleBuildError(BuilderCommon.java:147)
+- [MNG-5965] - Parallel build multiplies work if multiple goals are given
+- [MNG-5995] - Maven itself cannot run without maven-compat
+- [MNG-6256] - Maven script can break if "-f" path contains special characters
+- [MNG-6261] - Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
+- [MNG-6262] - getCanonicalFile() is not used consistently during project resolution
+- [MNG-6346] - ... was unexpected at this time when using -f option and path contains brackets
+- [MNG-6374] - ModelBuilder hangs with malformed pom.xml
+- [MNG-6429] - Integration Test site publishing requires Java 7 (or javadoc errors ignored)
+- [MNG-6495] - ModelResolver cannot be null
+- [MNG-6505] - child.(x.y).inherit.append.path value should be inherited
+- [MNG-6506] - Mojos are unable to load package annotations on Java >= 9
+- [MNG-6529] - `ProjectBuilder.build(List<File> projects, boolean, ProjectBuildingRequest)` doesn't honor `ProjectBuildingRequest.isResolveDependencies()`
+- [MNG-6530] - Regression in ProjectBuilder when file change between invocations (introduced by MNG-6311)
+- [MNG-6533] - `ProjectBuilder.build(list_of_projects,...)` does not contain MavenProject in exception report
+- [MNG-6543] - Upgrade plexus classworld to support java 9+ `ClassLoader.findClass(String moduleName, String name)` in Mojos
+- [MNG-6558] - ToolchainsBuildingResult event is not sent on EventSpy
+- [MNG-6577] - pom.xml: Uncaught IllegalArgumentException when parsing unicode entity ref
+- [MNG-6590] - DefaultProjectArtifactsCache java.lang.IllegalStateException: Duplicate artifact resolution result
+- [MNG-6599] - unknown version in model id when version is defined from parent
### Improvements
- - [MNG-6059] - Important use cases not covered, as child.inherit.append.path affects all children
- - [MNG-6159] - Child path adjustments break git scm urls
- - [MNG-6213] - Maven doesn't check the validity of scope value
- - [MNG-6481] - Allow to compile and test Maven with Java 11
- - [MNG-6513] - Replace depreated Plexus javadoc tags with annotations in ITs
- - [MNG-6515] - Fix javadoc build errors under Java 8 and 11
- - [MNG-6520] - Update assembly descriptors to 2.0.0
- - [MNG-6522] - Prepare Maven's Core Integration Test Suite to test with Java 12 and 13-ea
- - [MNG-6572] - use int or long instead of BigIntegers for little numbers in ComparableVersion
- - [MNG-6593] - track input location for super-pom
- - [MNG-6597] - add input location tracking for plugins configuration
- - [MNG-6600] - add input location tracking for default lifecycle bindings executions
- - [MNG-6601] - add input location tracking for site's reportPlugins injected by reports conversion
- - [MNG-6605] - Allow to suppress download messages in interactive mode
- - [MNG-6611] - Update animal-sniffer-maven-plugin to 1.17
+- [MNG-6059] - Important use cases not covered, as child.inherit.append.path affects all children
+- [MNG-6159] - Child path adjustments break git scm urls
+- [MNG-6213] - Maven doesn't check the validity of scope value
+- [MNG-6481] - Allow to compile and test Maven with Java 11
+- [MNG-6513] - Replace depreated Plexus javadoc tags with annotations in ITs
+- [MNG-6515] - Fix javadoc build errors under Java 8 and 11
+- [MNG-6520] - Update assembly descriptors to 2.0.0
+- [MNG-6522] - Prepare Maven's Core Integration Test Suite to test with Java 12 and 13-ea
+- [MNG-6572] - use int or long instead of BigIntegers for little numbers in ComparableVersion
+- [MNG-6593] - track input location for super-pom
+- [MNG-6597] - add input location tracking for plugins configuration
+- [MNG-6600] - add input location tracking for default lifecycle bindings executions
+- [MNG-6601] - add input location tracking for site's reportPlugins injected by reports conversion
+- [MNG-6605] - Allow to suppress download messages in interactive mode
+- [MNG-6611] - Update animal-sniffer-maven-plugin to 1.17
### Wish
- - [MNG-6571] - Maven memory consumption issue
+- [MNG-6571] - Maven memory consumption issue
### Task
- - [MNG-6538] - Upgrade Maven Artifact Resolver to 1.3.3 to restore API
- - [MNG-6544] - Replace CacheUtils#{eq,hash} with Objects
- - [MNG-6573] - Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI
- - [MNG-6618] - Maven doesn't export org.slf4j.event.Level
+- [MNG-6538] - Upgrade Maven Artifact Resolver to 1.3.3 to restore API
+- [MNG-6544] - Replace CacheUtils#{eq,hash} with Objects
+- [MNG-6573] - Use latest Maven 3.6.0 to build Maven Core and plugins with ASF CI
+- [MNG-6618] - Maven doesn't export org.slf4j.event.Level
### Dependency upgrade
- - [MNG-6526] - Upgrade to Wagon 3.3.1 (from 3.2.0)
- - [MNG-6591] - Upgrade to Wagon 3.3.2
-
+- [MNG-6526] - Upgrade to Wagon 3.3.1 (from 3.2.0)
+- [MNG-6591] - Upgrade to Wagon 3.3.2
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/3.6.2/release-notes.md b/content/markdown/docs/3.6.2/release-notes.md
index 3a70e194..18db3673 100644
--- a/content/markdown/docs/3.6.2/release-notes.md
+++ b/content/markdown/docs/3.6.2/release-notes.md
@@ -43,12 +43,11 @@ Issue Reporters of this release: Benoit GUERIN, Christian Schulte, Elliotte Rust
Code Contributors of this release: Guillaume Nodet, Mickael Istria, Ray Tsang, Stefan Oehme, Joseph Walton, Bo Zhang, AElMehdi, Christian Schulte, Mao Shuai, MartinKanters, Sergey Chernov, Jesse Glick.
-
Many thanks to all reporters and contributors for their time and support.
(Please send an email to the dev list if we missed anyone).
-## Overview about the changes
+## Overview about the changes
- This release focuses mostly performance improvements, better memory footprint, and less CPU usage.
@@ -130,7 +129,6 @@ Dependency upgrade
[MNG-6674] - Upgrade Wagon to 3.3.3
[MNG-6738] - Upgrade maven-resolver to 1.4.1
-
The full list of changes can be found in our [issue management system][4].
## Complete Release Notes
@@ -142,4 +140,3 @@ See [complete release notes for all versions][5]
[2]: https://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12345234
[5]: ../../docs/history.html
-
diff --git a/content/markdown/docs/3.6.3/release-notes.md b/content/markdown/docs/3.6.3/release-notes.md
index 9980fd54..42064d4e 100644
--- a/content/markdown/docs/3.6.3/release-notes.md
+++ b/content/markdown/docs/3.6.3/release-notes.md
@@ -41,22 +41,24 @@ the [end of these release notes](#details).
Issue Reporters of this release: Jonathan Chen, Charles Oliver Nutter, Lucas Ludueño, Stig Rohde Døssing, Vladimir Sitnikov
-Contributors of this release: Stuart McCulloch, Mickael Istria, Peter Lynch, Christian Wansart, Dezhi Cai, Anatoly Zaretsky, Stig Rohde Døssing
-
+Contributors of this release: Stuart McCulloch, Mickael Istria, Peter Lynch, Christian Wansart, Dezhi Cai, Anatoly Zaretsky, Stig Rohde Døssing
+
Many thanks to all reporters and contributors for their time and support.
(Please send an email to the dev list if we missed anyone).
-## Overview about the changes
+## Overview about the changes
- This is a regression release to fix some critical issues shipped with 3.6.2.
- Some license issues on binary distribution have been fixed.
- This Maven distribution is now Reproducible: if you [download Maven source archive](/download.cgi) (`apache-maven-3.6.3-src.zip` or `.tar.gz`), build it on Windows with JDK 8 using following command:
+
```
mvn -DbuildNumber=cecedd343002696d0abb50b32b541b8a6ba2883f package
```
+
you'll get bit-by-bit identical output (`apache-maven-3.6.3-bin.zip` and `.tar.gz` in `apache-maven/target/`) that you can check with sha512 fingerprints against official release.
If you're building on any Unix system, you'll need to add "`-Dline.separator=$'\r\n'`".
See the [Maven - Guide to Configuring for Reproducible Builds](/guides/mini/guide-reproducible-builds.html) for more details.
@@ -96,4 +98,3 @@ See [complete release notes for all versions][5]
[2]: https://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12346152
[5]: ../../docs/history.html
-
diff --git a/content/markdown/docs/3.8.1/release-notes.md b/content/markdown/docs/3.8.1/release-notes.md
index b4045bef..17218a84 100644
--- a/content/markdown/docs/3.8.1/release-notes.md
+++ b/content/markdown/docs/3.8.1/release-notes.md
@@ -33,7 +33,7 @@ If you have any questions, please consult:
- the maven-user mailing list: [https://maven.apache.org/mailing-lists.html](/mailing-lists.html)
- the reference documentation: [https://maven.apache.org/ref/3.8.1/](/ref/3.8.1/)
-## Overview about the changes
+## Overview about the changes
This release covers two CVEs:
@@ -42,19 +42,19 @@ This release covers two CVEs:
We received a report from Jonathan Leitschuh about a vulnerability of custom repositories in dependency POMs.
We've split this up into three separate issues:
- - Possible Man-In-The-Middle-Attack due to custom repositories using HTTP\
+- Possible Man-In-The-Middle-Attack due to custom repositories using HTTP\
More and more repositories use HTTPS nowadays, but this hasn't always been the case. This means that Maven Central contains POMs with custom repositories that refer to a URL over HTTP.
- This makes downloads via such repository a target for a MITM attack.
- At the same time, developers are probably not aware that for some downloads an insecure URL is being used.
+ This makes downloads via such repository a target for a MITM attack.
+ At the same time, developers are probably not aware that for some downloads an insecure URL is being used.
Because uploaded POMs to Maven Central are immutable, a change for Maven was required.
To solve this, we extended the mirror configuration with `<blocked>` parameter,
and we added a new `external:http:*` mirror selector (like existing `external:*`), meaning "any external URL using HTTP".\
The decision was made to block such external HTTP repositories by default: this is done by providing a mirror in the `conf/settings.xml` blocking insecure HTTP external URLs.
- - Possible Domain Hijacking due to custom repositories using abandoned domains\
- Sonatype has analyzed which domains were abandoned and has claimed these domains.
+- Possible Domain Hijacking due to custom repositories using abandoned domains\
+ Sonatype has analyzed which domains were abandoned and has claimed these domains.
- - Possible hijacking of downloads by redirecting to custom repositories\
+- Possible hijacking of downloads by redirecting to custom repositories\
This one was the hardest to analyze and explain. The short story is: you're safe, dependencies are only downloaded from repositories within their context.
So there are two main questions: what is the context and what is the order?
The order is described on the [Repository Order](/guides/mini/guide-multiple-repositories.html#repository-order) page.
@@ -70,20 +70,19 @@ This release covers two CVEs:
## Why does this version have the value 3.8.1?
- - Why not 3.6.4?\
+- Why not 3.6.4?\
This is not just a bugfix as it contains three features that **cause a change of default behavior** (external HTTP insecure URLs are now blocked by default):
your builds may fail when using this new Maven release, if you use now blocked repositories. Please check and eventually fix before upgrading.
- - Why not 3.7.0?\
+- Why not 3.7.0?\
Apache Maven 3.7.0 has been advertised in the past that it would be the first release where you could optionally activate the build/consumer feature:
the version containing this feature has been renamed to 4.0.0.
Reusing 3.7.0 might lead to confusion, hence we picked the next available minor version.
- - Why not 3.8.0?\
+- Why not 3.8.0?\
With every release there's a 72h+ voting period. During the vote of 3.8.0 a bug was discovered, one that was important enough to cancel the vote.
With Maven we burn versions, to ensure we're always talking about the same "version". This way there will be never confusion about which Maven 3.8.0 one was using.
-
## How to fix when I get a HTTP repository blocked?
If the repository is defined in your `pom.xml`, please fix it in your source code.
@@ -96,16 +95,16 @@ This release covers two CVEs:
Options to fix are:
- - upgrade the dependency version to a newer version that replaced the obsolete HTTP repository URL with a HTTPS one,
+- upgrade the dependency version to a newer version that replaced the obsolete HTTP repository URL with a HTTPS one,
- - keep the dependency version but [define a mirror in your settings](/guides/mini/guide-mirror-settings.html).
+- keep the dependency version but [define a mirror in your settings](/guides/mini/guide-mirror-settings.html).
## The detailed issue list[](#details)
Bug
[MNG-7128] - improve error message when blocked repository defined in build POM
-
+
New Feature
[MNG-7116] - Add support for mirror selector on external:http:*
@@ -116,7 +115,7 @@ Dependency upgrade
[MNG-7119] - Upgrade Maven Wagon to 3.4.3
[MNG-7123] - Upgrade Maven Resolver to 1.6.2
-
+
The full list of changes can be found in our [issue management system][4].
## Complete Release Notes
@@ -128,4 +127,3 @@ See [complete release notes for all versions][5]
[2]: https://maven.apache.org/
[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12350032
[5]: ../../docs/history.html
-
diff --git a/content/markdown/docs/3.8.3/release-notes.md b/content/markdown/docs/3.8.3/release-notes.md
index 0c414008..baf4cfd4 100644
--- a/content/markdown/docs/3.8.3/release-notes.md
+++ b/content/markdown/docs/3.8.3/release-notes.md
@@ -35,9 +35,9 @@ If you have any questions, please consult:
## Overview About the Changes
-* Regression fixes from Maven 3.8.2
-* [Drop CDI API][6] to avoid leakage into code
-* Speed improvements with [MNG-7235][7] and [MNG-7236][8]
+- Regression fixes from Maven 3.8.2
+- [Drop CDI API][6] to avoid leakage into code
+- Speed improvements with [MNG-7235][7] and [MNG-7236][8]
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/3.8.4/release-notes.md b/content/markdown/docs/3.8.4/release-notes.md
index a52f945a..6057c3ba 100644
--- a/content/markdown/docs/3.8.4/release-notes.md
+++ b/content/markdown/docs/3.8.4/release-notes.md
@@ -35,8 +35,8 @@ If you have any questions, please consult:
## Overview About the Changes
-* Regression fixes from Maven 3.8.3
-* Upgrade to Jansi 2.4.0 which supports macOS on ARM natively
+- Regression fixes from Maven 3.8.3
+- Upgrade to Jansi 2.4.0 which supports macOS on ARM natively
The full list of changes can be found in our [issue management system][4].
@@ -55,4 +55,3 @@ See [complete release notes for all versions][5]
[5]: ../../docs/history.html
[6]: https://issues.apache.org/jira/browse/MNG-6843
[7]: https://issues.apache.org/jira/browse/MNG-7335
-
diff --git a/content/markdown/docs/3.8.5/release-notes.md b/content/markdown/docs/3.8.5/release-notes.md
index 2616dccf..76c2f688 100644
--- a/content/markdown/docs/3.8.5/release-notes.md
+++ b/content/markdown/docs/3.8.5/release-notes.md
@@ -35,7 +35,7 @@ If you have any questions, please consult:
## Overview About the Changes
-* Regression fixes from Maven 3.8.4
+- Regression fixes from Maven 3.8.4
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/3.8.6/release-notes.md b/content/markdown/docs/3.8.6/release-notes.md
index 618e5e19..f1243ea0 100644
--- a/content/markdown/docs/3.8.6/release-notes.md
+++ b/content/markdown/docs/3.8.6/release-notes.md
@@ -35,8 +35,8 @@ If you have any questions, please consult:
## Overview About the Changes
-* Regression fixes from Maven 3.8.5
-* Improve locking for multithreaded builds
+- Regression fixes from Maven 3.8.5
+- Improve locking for multithreaded builds
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/3.8.7/release-notes.md b/content/markdown/docs/3.8.7/release-notes.md
index 0cfe6bc0..ad6416bd 100644
--- a/content/markdown/docs/3.8.7/release-notes.md
+++ b/content/markdown/docs/3.8.7/release-notes.md
@@ -35,9 +35,9 @@ If you have any questions, please consult:
## Overview About the Changes
-* Regression fixes from Maven 3.8.6
-* General fixes
-* Maven Wagon upgrade
+- Regression fixes from Maven 3.8.6
+- General fixes
+- Maven Wagon upgrade
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/3.9.0/release-notes.md b/content/markdown/docs/3.9.0/release-notes.md
index f24f6256..8a6531bc 100644
--- a/content/markdown/docs/3.9.0/release-notes.md
+++ b/content/markdown/docs/3.9.0/release-notes.md
@@ -35,44 +35,44 @@ If you have any questions, please consult:
## Overview About the Changes
-* Minimum Java version to use with Maven 3.9.0 is raised to Java 8.
-* With Java 8, upgrade of several key dependencies became possible as well.
-* Several backports from Maven 4.x line.
-* Long outstanding issue fixes from Maven 3.x line.
-* Cutting ties with Maven 2 backward compatibility, preparing grounds for Maven 4.
-* General fixes and improvements.
+- Minimum Java version to use with Maven 3.9.0 is raised to Java 8.
+- With Java 8, upgrade of several key dependencies became possible as well.
+- Several backports from Maven 4.x line.
+- Long outstanding issue fixes from Maven 3.x line.
+- Cutting ties with Maven 2 backward compatibility, preparing grounds for Maven 4.
+- General fixes and improvements.
### Potentially Breaking Core Changes
-* Maven 2.x was auto-injecting an ancient version of `plexus-utils` dependency into the plugin classpath, and Maven 3.x continued doing this to preserve backward compatibility. Starting with Maven 3.9, it does not happen anymore. This change may lead to plugin breakage. The fix for affected plugin maintainers is to explicitly declare a dependency on `plexus-utils`. The workaround for affected plugin users is to add this dependency to plugin dependencies until issue is fixed by the affect [...]
-* Mojos are prevented to boostrap new instance of `RepositorySystem` (for example by using deprecated `ServiceLocator`), they should reuse `RepositorySystem` instance provided by Maven instead. See [MNG-7471](https://issues.apache.org/jira/browse/MNG-7471).
-* Each line in `.mvn/maven.config` is now interpreted as a single argument. That is, if the file contains multiple arguments, these must now be placed on separate lines, see [MNG-7684](https://issues.apache.org/jira/browse/MNG-7684).
+- Maven 2.x was auto-injecting an ancient version of `plexus-utils` dependency into the plugin classpath, and Maven 3.x continued doing this to preserve backward compatibility. Starting with Maven 3.9, it does not happen anymore. This change may lead to plugin breakage. The fix for affected plugin maintainers is to explicitly declare a dependency on `plexus-utils`. The workaround for affected plugin users is to add this dependency to plugin dependencies until issue is fixed by the affect [...]
+- Mojos are prevented to boostrap new instance of `RepositorySystem` (for example by using deprecated `ServiceLocator`), they should reuse `RepositorySystem` instance provided by Maven instead. See [MNG-7471](https://issues.apache.org/jira/browse/MNG-7471).
+- Each line in `.mvn/maven.config` is now interpreted as a single argument. That is, if the file contains multiple arguments, these must now be placed on separate lines, see [MNG-7684](https://issues.apache.org/jira/browse/MNG-7684).
### Notable Core Improvements
-* Help with projects maintenance: Maven now warns about use of deprecated plugins, goals, parameters, etc.
-* Add support for "mvn pluginPrefix:version:goal" invocation, and align console logging as well (make it copy-paste-able).
-* Add profile activation by packaging.
-* Maven 3.9.0 is now fully compatible with new 3.x line of install and deploy plugins (previous versions warns about this).
+- Help with projects maintenance: Maven now warns about use of deprecated plugins, goals, parameters, etc.
+- Add support for "mvn pluginPrefix:version:goal" invocation, and align console logging as well (make it copy-paste-able).
+- Add profile activation by packaging.
+- Maven 3.9.0 is now fully compatible with new 3.x line of install and deploy plugins (previous versions warns about this).
### Notable Resolver 1.9.x Improvements
-* Shared local repository (advisory file locking, Hazelcast or Redis, see [documentation](https://maven.apache.org/resolver/local-repository.html#shared-access-to-local-repository)).
-* Split local repository, plus "workspace" support for branched development (see [documentation](https://maven.apache.org/resolver/local-repository.html#split-local-repository)).
-* Switchable and alternative resolver transports included, with default switched to native transport.
-* Pluggable checksum algorithms API (is not tied to MessageDigest anymore, see [documentation](https://maven.apache.org/resolver/about-checksums.html)).
-* Choice of resolver collectors: a new BF collector (with parallel POM downloads) has been added along the existing DF one.
-* Remote repository filtering (see [documentation](https://maven.apache.org/resolver/remote-repository-filtering.html)).
-* Trusted checksum sources (ability to provide some or all artifact checksums ahead of time).
-* Pluggable artifact resolver post-processor, with "trustedChecksums" implementation.
-* Chained local repository (for IT isolation between "outer" and "inner" builds).
-* Recording reverse dependency tree tracking information into local repository.
+- Shared local repository (advisory file locking, Hazelcast or Redis, see [documentation](https://maven.apache.org/resolver/local-repository.html#shared-access-to-local-repository)).
+- Split local repository, plus "workspace" support for branched development (see [documentation](https://maven.apache.org/resolver/local-repository.html#split-local-repository)).
+- Switchable and alternative resolver transports included, with default switched to native transport.
+- Pluggable checksum algorithms API (is not tied to MessageDigest anymore, see [documentation](https://maven.apache.org/resolver/about-checksums.html)).
+- Choice of resolver collectors: a new BF collector (with parallel POM downloads) has been added along the existing DF one.
+- Remote repository filtering (see [documentation](https://maven.apache.org/resolver/remote-repository-filtering.html)).
+- Trusted checksum sources (ability to provide some or all artifact checksums ahead of time).
+- Pluggable artifact resolver post-processor, with "trustedChecksums" implementation.
+- Chained local repository (for IT isolation between "outer" and "inner" builds).
+- Recording reverse dependency tree tracking information into local repository.
The full list of changes can be found in our [issue management system][4].
## Known Issues
-* Observed roughly 10% slow-down on large builds when compared to Maven 3.8.7, tracked on [MNG-7677](https://issues.apache.org/jira/browse/MNG-7677).
+- Observed roughly 10% slow-down on large builds when compared to Maven 3.8.7, tracked on [MNG-7677](https://issues.apache.org/jira/browse/MNG-7677).
## Complete Release Notes
diff --git a/content/markdown/docs/4.0.0-alpha-2/release-notes.md b/content/markdown/docs/4.0.0-alpha-2/release-notes.md
index 632f0d5d..33c7b9d1 100644
--- a/content/markdown/docs/4.0.0-alpha-2/release-notes.md
+++ b/content/markdown/docs/4.0.0-alpha-2/release-notes.md
@@ -37,10 +37,10 @@ If you have any questions, please consult:
## Overview About the Changes
-* cli improvement: `--also-make` , `--resume`, `--non-recursive`, `--fail-on-severity`
-* consistent timestamps
-* build/consumer POMs (automatic parent versioning, automatic versioning of reactor dependencies, automatic detection of child modules)
-* new maven 4 api
+- cli improvement: `--also-make` , `--resume`, `--non-recursive`, `--fail-on-severity`
+- consistent timestamps
+- build/consumer POMs (automatic parent versioning, automatic versioning of reactor dependencies, automatic detection of child modules)
+- new maven 4 api
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/4.0.0-alpha-3/release-notes.md b/content/markdown/docs/4.0.0-alpha-3/release-notes.md
index 5cbd242a..7236f755 100644
--- a/content/markdown/docs/4.0.0-alpha-3/release-notes.md
+++ b/content/markdown/docs/4.0.0-alpha-3/release-notes.md
@@ -37,9 +37,9 @@ If you have any questions, please consult:
## Overview About the Changes
-* upgrade maven resolver 1.9.2
-* chained local repository
-* profile activation by packaging
+- upgrade maven resolver 1.9.2
+- chained local repository
+- profile activation by packaging
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/docs/4.0.0-alpha-4/release-notes.md b/content/markdown/docs/4.0.0-alpha-4/release-notes.md
index 81ac7419..1a981a81 100644
--- a/content/markdown/docs/4.0.0-alpha-4/release-notes.md
+++ b/content/markdown/docs/4.0.0-alpha-4/release-notes.md
@@ -37,11 +37,11 @@ If you have any questions, please consult:
## Overview About the Changes
-* upgrade maven resolver 1.9.4
-* improved resolution of modules within a multi-module build
-* do not parse all projects in the reactor when building a subtree
-* fix some compatibility issues (with flatten-maven-plugin)
-* re-implement the consumer pom feature to support the maven-gpg-plugin
+- upgrade maven resolver 1.9.4
+- improved resolution of modules within a multi-module build
+- do not parse all projects in the reactor when building a subtree
+- fix some compatibility issues (with flatten-maven-plugin)
+- re-implement the consumer pom feature to support the maven-gpg-plugin
The full list of changes can be found in our [issue management system][4].
diff --git a/content/markdown/examples/index.md b/content/markdown/examples/index.md
index 4fec2827..a7995fb8 100644
--- a/content/markdown/examples/index.md
+++ b/content/markdown/examples/index.md
@@ -23,8 +23,6 @@ under the License.
## Examples
- - [Injecting POM Properties via settings.xml](./injecting-properties-via-settings.html)
-
- - [Maven 3 lifecycle extensions](./maven-3-lifecycle-extensions.html)
-
+- [Injecting POM Properties via settings.xml](./injecting-properties-via-settings.html)
+- [Maven 3 lifecycle extensions](./maven-3-lifecycle-extensions.html)
diff --git a/content/markdown/examples/injecting-properties-via-settings.md b/content/markdown/examples/injecting-properties-via-settings.md
index f884dcc0..51aef3de 100644
--- a/content/markdown/examples/injecting-properties-via-settings.md
+++ b/content/markdown/examples/injecting-properties-via-settings.md
@@ -22,18 +22,12 @@ under the License.
-->
## Example: Injecting POM Properties via Settings.xml
-
### Impetus
-
You have a plugin parameter that should contain a user-specific value. This parameter has a common format (relative directory structure), but depends on knowing the directory of the installed application or something.
-
-
### Plugin Configuration
-
-
```
<project>
[...]
@@ -51,11 +45,8 @@ under the License.
</build>
```
-
### `settings.xml`
-
-
```
<settings>
[...]
@@ -74,11 +65,6 @@ under the License.
</settings>
```
-
### Explanation
-
When Maven loads the project's POM, it will pickup the activated profiles from the `activeProfiles` section of the `settings.xml` file, and inject the properties declared within the profile. When the POM is interpolated, the `application-home` property will already have been injected, so will allow the plugin's parameter value to be resolved.
-
-
-
diff --git a/content/markdown/faq-unoffical.md b/content/markdown/faq-unoffical.md
index bfaafe59..4fd4dbc1 100644
--- a/content/markdown/faq-unoffical.md
+++ b/content/markdown/faq-unoffical.md
@@ -17,13 +17,14 @@ specific language governing permissions and limitations
under the License.
-->
-*NOTE:* _This page contains drafts of user contributed FAQ entries. The content you see here might not be fully fool-proof or might not comply with the best practices promoted by Maven. What is only guaranteed is that they have worked once for some members. It is best to treat these items as "works in progress" until they have been reviewed and promoted to the main Maven documentation site._
+*NOTE:* *This page contains drafts of user contributed FAQ entries. The content you see here might not be fully fool-proof or might not comply with the best practices promoted by Maven. What is only guaranteed is that they have worked once for some members. It is best to treat these items as "works in progress" until they have been reviewed and promoted to the main Maven documentation site.*
Please follow the format that is being used because it will help in our automated extraction of material which can then be incorporated into the main site.
This page serves as a collection of questions *with* answers. If you have a frequently asked question that doesn't yet have an answer, please list that question on [the other page](FAQs].
# Answered Questions (Index)
+
### Reports & Site Docs
[How do I merge a list of configuration items in a parent POM with those in a child POM?](#How do I merge a list of configuration items in a parent POM with those in a child POM?)
@@ -234,6 +235,7 @@ NOTE: I fixed this behavior in Maven's trunk; previously, it had been putting th
So, to recap:
parent:
+
```xml
<configuration>
<items>
@@ -242,7 +244,9 @@ parent:
</items>
</configuration>
```
+
child:
+
```
<configuration>
<items combine.children="append">
@@ -250,7 +254,9 @@ child:
</items>
</configuration>
```
+
result:
+
```
<configuration>
<items>
@@ -260,6 +266,7 @@ result:
</items>
</configuration>
```
+
(If you're using an earlier version of Maven than trunk (revId 545315), the order above will be three, one, two.)
### Why do I not get an index.html page generated for my project website?
@@ -289,12 +296,13 @@ The usual cause of this is configuring maven-project-info-reports plugin and lea
This error indicates that Maven is either unable to access the required plug-in from your local repository, or unable to access the official or `central` Maven plug-in repository.
To resolve this error:
+
- If you are behind a http proxy, please check the Maven2 [proxy settings guide](http://maven.apache.org/guides/mini/guide-proxies.html).
- If you are upgrading Maven from an older version, try running with \-U. This will force an update check on all plug-ins.
If the error persists, browse [archived discussions](http://www.mail-archive.com/users@maven.apache.org/), post to the Maven user list, or log a [ticket](http://jira.codehaus.org/browse/MNG) describing your problem, if you think it is a bug. Tickets may also be issued for feature enhancement requests, and other tasks.
-_Errors, Dependencies, Plugins_
+*Errors, Dependencies, Plugins*
### How do I install a file in my local repository along with a generic POM?
@@ -313,11 +321,12 @@ mvn install:install-file
This command installs the jar in your local repository with the generated generic pom.
{{Well, this doesn't work in Maven 2.0.2. It just gives the message "Cannot execute mojo: install-file. It requires a project with an existing pom.xml, but the build is not using one." \--kreiger@imcode.com}}
- _Repositories_
+ *Repositories*
### How do I install a file in my local repository along with my customized POM?
The solution requires the `-DpomFile=<path-to-pom>` parameter just like the sample below.
+
```
mvn install:install-file
-DgroupId=<group-id>
@@ -327,23 +336,24 @@ mvn install:install-file
-Dpackaging=<packaging> (i.e. jar)
-DpomFile=<path-to-pom>
```
+
This command will install the file in your local repository along with your customed pom.
-_Repositories_
+*Repositories*
### How do I include/exclude the other modules in the navigation menu in the parent site?
[MNG-661](http://jira.codehaus.org/browse/MNG-661), provides a simple patch which provides parent and module links using the project URLs which as you
correctly point out only work when the site is deployed.
-_Plugins & Lifecycle_
+*Plugins & Lifecycle*
-_General_
+*General*
### What is the difference between Maven and Ivy?
For a comparison of Maven's features vs Ivy's you can refer to our [feature comparison](http://docs.codehaus.org/display/MAVEN/Feature+Comparisons)
-_General_
+*General*
### How do I get a plug-in's dependencies from a Mojo?
@@ -394,7 +404,7 @@ public class MyMojo
}
}
}
-```
+```
### Does the v4.0.0 POM include a < versions/ > element?
@@ -402,19 +412,20 @@ The POM does not inlcude a `<versions/>` element. The POM reflects the current s
However, if the SCM tag of the `<scm>` section of the POM is populated, the repository records build versions, enabling developers to reconstruct the information for each released build.
-_POM, General_
+*POM, General*
### How do I create a report that does not require Doxia's Sink interface?
Make it a report and override the `isExternalReport()` method to return true.
-_Sites & Reporting_
+*Sites & Reporting*
### How do I prevent verification warnings with custom repositories?
Warnings from custom repositories (usually located within the organization's network, or even on the same workstation) are triggered when Maven tries to verify the integrity of the files in the repository. This verification is done via the SHA1 or MD5 sum of the file. If these sum files do not exist, then a warning appears.
Support for downloading the security sum files is not yet included in the Maven2 distribution. There are free command-line utilities on the Internet that generate these sums. Below is an example of a bash script (use [Cygwin](http://cygwin.com) if you are using a windows machine) that generates sha1sum for all jar, xml and pom files contained in the directory where it is executed:
+
```
#!/usr/bin/bash
@@ -455,23 +466,24 @@ rm "$tmpFile"
```
The script above has been tested on [Cygwin](http://cygwin.com) and is provided "as-is" and with no guarantee.
-_Errors, Repositories_
+*Errors, Repositories*
### What does the "ERROR: Cannot override read-only parameter: `<parameter_name>` " message, when running <plugin_name>: mean?
This means that the parameter being overriden in the pom.xml is read-only. Hence, it is not possible to override this parameter.
-_Errors, POM_
+*Errors, POM*
### How do I generate Maven plug-in sites, with pages that include an overview of the goals and parameters for each plug-in?
Include maven-plugin-plugin as a report.
-_Plugin Requests, Sites & Reporting_
+*Plugin Requests, Sites & Reporting*
### Can I define the antrun plugin to be executed on demand like "mvn antrun:run"?
The antrun plugin can be executed on demand only if:
+
- the top level configuration of the plugin contains all the information
- a variable is passed from the command line, eg `-Dtarget=foo antrun:run`
- the appropriate target in the script is executed based on the variable
@@ -479,7 +491,7 @@ The antrun plugin can be executed on demand only if:
However, it is recommended that developers write plugins for their goals (Ant support for
plugins will be available soon, currently you must write them in java or beanshell).
-_Plugins and Lifecycle, Ant-related_
+*Plugins and Lifecycle, Ant-related*
### How do I properly populate variables, when extending a mojo from another plugin?
@@ -487,7 +499,7 @@ When creating plugins, the field metadata is read from source files, so it is no
It is currently recommended that plug-ins be built using composition, instead of inheritence.
-_Plugin Requests, Design, Patterns & Best Practices_
+*Plugin Requests, Design, Patterns & Best Practices*
### How do I access artifacts if Ibiblio is down?
@@ -495,11 +507,11 @@ To access artifacts if Ibiblio is down, use any of its mirror sites.
[Guide mirror settings](http://maven.apache.org/guides/mini/guide-mirror-settings.html)
-_Repositories, General_
+*Repositories, General*
### How do I get a list of archetypes?
-To get a list of archetypes, refer to the following page [http://svn.apache.org/viewcvs.cgi/maven/archetype/trunk/maven-archetypes)
+To get a list of archetypes, refer to the following page [<http://svn.apache.org/viewcvs.cgi/maven/archetype/trunk/maven-archetypes)>
### How do I specify my remote repo in Maven?
@@ -514,8 +526,9 @@ To specify a remote repo in Maven, add the `<repositories>` element to the POM:
</repository>
</repositories>
```
-Or, refer to the following page [http://maven.apache.org/guides/mini/guide-multiple-repositories.html)
-_Repositories_
+
+Or, refer to the following page [<http://maven.apache.org/guides/mini/guide-multiple-repositories.html)>
+*Repositories*
### How do I specify which output directories the Eclipse plugin puts into the .classpath file?
@@ -536,15 +549,15 @@ _Repositories_
...
</build>
```
-_Plugins and Lifecycle, IDEs_
+*Plugins and Lifecycle, IDEs*
-_General, Plugins and Lifecycle_
+*General, Plugins and Lifecycle*
### Can a profile inherit the configuration of a "sibling" profile?
No. Profiles merge when their ID's match - so you can inherit them from a parent POM (but you can't inherit profiles from the same POM).
-_Inheritence and Interpolation, Plugins and Lifecycle, POM_
+*Inheritence and Interpolation, Plugins and Lifecycle, POM*
### How do I run an ant task twice, against two different phases?
@@ -583,11 +596,12 @@ You can specify multiple execution elements under the executions tag, giving eac
</plugin>
```
-_Ant-related_
+*Ant-related*
### How do I prevent tests from running twice, after adding a configuration for the surefire plugin?
Declare the configuration outside of the executions tag of the plugin.
+
```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -603,13 +617,14 @@ Declare the configuration outside of the executions tag of the plugin.
</configuration>
</plugin>
```
-_Plugins and Lifecycle, Sites & Reporting_
+*Plugins and Lifecycle, Sites & Reporting*
### How do I integrate static (x)html into my Maven site?
You can integrate your static pages in this several steps,
-* Put your static pages in the resources directory, ${basedir}/src/site/resources.
-* Create your site.xml and put it in `${basedir}/src/site`. An example below:
+- Put your static pages in the resources directory, ${basedir}/src/site/resources.
+- Create your site.xml and put it in `${basedir}/src/site`. An example below:
+
```
<project name="Maven War Plugin">
<bannerLeft>
@@ -634,7 +649,7 @@ You can integrate your static pages in this several steps,
</project>
```
-* Link the static pages by modifying the `<menu>` section, create items and map it with the filename of the static pages.
+- Link the static pages by modifying the `<menu>` section, create items and map it with the filename of the static pages.
```
<menu name="Overview">
@@ -643,27 +658,29 @@ You can integrate your static pages in this several steps,
<item name="<put-name-here>" xhref="<filename-of-the-static-page>"/>
</menu>
```
- _Sites & Reporting_
+
+ *Sites & Reporting*
### How do I specify that all web modules will inherit the group's common files from a parent web module?
maven-war-plugin 2.0-beta-3 and later supports merging of wars. Just reference the common WAR project from another WAR project as a dependency of `<type>war</type>` and it will automatically be merged.
-See [http://jira.codehaus.org/browse/MWAR-8)
+See [<http://jira.codehaus.org/browse/MWAR-8)>
-_Inheritence and Interpolation_
+*Inheritence and Interpolation*
### How do I determine which POM contains missing transitive dependency?
run `mvn -X`
-_POM, Dependencies_
+*POM, Dependencies*
-_General, POM, Plugins and Lifecycle, Command Line_
+*General, POM, Plugins and Lifecycle, Command Line*
### How do I determine the stale resources in a Mojo to avoid reprocessing them?
This can be done using the following piece of code:
+
```
// Imports needed
import org.codehaus.plexus.compiler.util.scan.InclusionScanException;
@@ -675,8 +692,10 @@ import org.codehaus.plexus.compiler.util.scan.mapping.SuffixMapping;
scanner.addSourceMapping( new SuffixMapping( ".xml", ".html" ) );
Set<File> staleFiles = (Set<File>) scanner.getIncludedSources( this.sourceDirectory, this.targetDirectory );
```
+
The second parameter to the StaleSourceScanner is the set of includes, while the third parameter is the set of excludes. You must add a source mapping to the scanner (second line). In this case we're telling the scanner what is the extension of the result file (.html) for each source file extension (.xml). Finally we get the stale files as a `Set<File>` calling the `getIncludedSources` method, passing as parameters the source and target directories (of type File). The Maven API doesn't s [...]
In order to use this API you must include the following dependency in your pom:
+
```
<dependencies>
<dependency>
@@ -687,18 +706,21 @@ In order to use this API you must include the following dependency in your pom:
</dependencies>
```
-_POM, Plugin API_
+*POM, Plugin API*
### What does the FATAL ERROR with the message *"Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log"* when using the maven-checkstyle-plugin mean?
Checkstyle uses commons-logging, which has classloader problems when initialized within a Maven plugin's container. This results in the above message - if you run with '-e', you'll see something like the following:
---
+
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log
---
+
buried deep in the stacktrace.
The only workaround we currently have for this problem is to include another commons-logging Log implementation in the plugin itself. So, you can solve the problem by adding the following to your plugin declaration in your POM:
+
```
<project>
...
@@ -727,11 +749,12 @@ The only workaround we currently have for this problem is to include another com
</reporting>
</project>
```
+
While this may seem a counter-intuitive way of configuring a report, it's important to remember that Maven plugins can have a mix of reports and normal mojos. When a POM has to configure extra dependencies for a plugin, it should do so in the normal plugins section.
We will probably try to fix this problem before the next release of the checkstyle plugin.
*UPDATE:* This problem has been fixed in the SVN trunk version of the checkstyle plugin, which should be released very soon.
- _Plugins and Lifecycle, Sites & Reporting, Errors_
+ *Plugins and Lifecycle, Sites & Reporting, Errors*
### Where do I configure report plug-ins, like javadoc?
@@ -741,7 +764,7 @@ Configuration in the build section is only used during the normal lifecycle or t
Configuration should go there if you do not want the report on the site, or the configuration differs from what is on the site (eg, some plugins have a fail build option).
-_Sites & Reporting, Plugins and Lifecycle, Command Line_
+*Sites & Reporting, Plugins and Lifecycle, Command Line*
### How do I deploy my binary during the deploy phase?
@@ -762,12 +785,14 @@ _Sites & Reporting, Plugins and Lifecycle, Command Line_
</executions>
</plugin>
```
+
Then run `mvn deploy`.
-_Deployment_
+*Deployment*
### How do I add main class in a generated jar's manifest?
Configure the maven-jar-plugin and add your main class.
+
```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -780,7 +805,7 @@ Configure the maven-jar-plugin and add your main class.
</archive>
</configuration>
</plugin>
-```
+```
### How do I install artifacts to a remote repository?
@@ -797,13 +822,13 @@ mvn deploy:deploy-file
-Durl=<url-of-remote-repo>
```
-_Repositories, Command Line_
+*Repositories, Command Line*
### Does a POM inherit its resources?
Yes, resources are inherited, but only if the child pom does not define any resources. If it does, then the project just uses those resources defined in its pom and the parents resources are overridden.
-_POM, Inheritence and Interpolation_
+*POM, Inheritence and Interpolation*
### How do I use SNAPSHOT versions of plug-ins?
@@ -818,6 +843,7 @@ Also refer to [How do I skip unit tests when building a project?](How do I skip
### How do I execute the assembly plugin with different configurations?
Add this to your pom,
+
```
<build>
...
@@ -856,8 +882,8 @@ Add this to your pom,
</build>
```
-and run `mvn install`, this will execute the assembly plugin twice with different config.
+and run `mvn install`, this will execute the assembly plugin twice with different config.
### What is Maven's order of inheritance?
@@ -868,7 +894,7 @@ and run `mvn install`, this will execute the assembly plugin twice with differen
where the last overrides the previous.
-_General, Inheritence and Interpolation, Design, Patterns & Best Practices_
+*General, Inheritence and Interpolation, Design, Patterns & Best Practices*
### How do I add my generated sources to the compile path of Maven, when using modello?
@@ -876,7 +902,7 @@ Modello generate the sources in the generate-sources phase and automatically add
You have to declare the modello-plugin in the build of your plugin for source generation (in that way the sources are generated each time).
-_Plugins and Lifecycle_
+*Plugins and Lifecycle*
### Can I add a java source to my war package?
@@ -886,19 +912,20 @@ Please refer to these sites for more info
[http://maven.apache.org/guides/mini/guide-assemblies.html]
[http://maven.apache.org/plugins/maven-assembly-plugin/howto.html]
-_Deployments, Plugins and Lifecycle_
+*Deployments, Plugins and Lifecycle*
### What does the "You cannot have two plugin executions with the same (or missing) `<id/>` elements" message mean?
It means that you have executed a plugin multiple times with the same `<id>`. Provide each `<execution>` with a unique `<id>` then it would be ok.
-_Errors, Plugins and Lifecycle_
+*Errors, Plugins and Lifecycle*
### Can I disable transitive dependencies?
No you can't, but you may exclude the dependencies you dont want to include in your project.
Following is a sample on how to exclude transitive dependencies.
+
```
<project>
...
@@ -917,13 +944,13 @@ Following is a sample on how to exclude transitive dependencies.
</project>
```
-_Dependencies, Design, Patterns & Best Practices_
+*Dependencies, Design, Patterns & Best Practices*
### Where can I get offline documentation for Maven?
Check it out from [http://svn.apache.org/repos/asf/maven/site/trunk] and run mvn site:site
-_General, Sites & Reporting_
+*General, Sites & Reporting*
### How do I skip unit tests when building a project?
@@ -931,7 +958,7 @@ Run the mvn command with `-Dmaven.test.skip=true` argument.
Also see [How do I run a build/package/deploy process without waiting for reports or unit tests, so that I can quickly deploy to an integration box?]
-_Sites & Reporting, General_
+*Sites & Reporting, General*
### How do I create a command line parameter (i.e., \-Dname=value ) in my mojo?
@@ -943,14 +970,16 @@ In your mojo, put `expression=${<exp>}` in your parameter field
*/
private String exp;
```
+
You may now able to pass parameter values to the command line.
`mvn \-Dexpression.name=value install`
-_Command Line_
+*Command Line*
### What is the purpose of displaying read-only, plug-in fields in user documentation, if they are not configurable in the project descriptor?
Often, parameters are specified as read-only to indicate that its value should be changed indirectly, rather than in the plugins `<configuration/>` section. For instance, I may have a plugin that declares a parameter as such:
+
```
/**
* @parameter default-value="${project.build.directory}"
@@ -959,14 +988,14 @@ Often, parameters are specified as read-only to indicate that its value should b
*/
private File buildDir;
```
-In this case, my plugin wants to output something to the project's build directory. If this were configured directly on the plugin, it might not be cleaned up when the user issued *'mvn clean'*, so instead I mark it as `@readonly`. This tells the user that she should modify the structure referenced by *default-value*(i.e. `<project><build><directory/>` in the POM) instead, which will allow this plugin to be a good citizen in the build process.
+In this case, my plugin wants to output something to the project's build directory. If this were configured directly on the plugin, it might not be cleaned up when the user issued *'mvn clean'*, so instead I mark it as `@readonly`. This tells the user that she should modify the structure referenced by *default-value*(i.e. `<project><build><directory/>` in the POM) instead, which will allow this plugin to be a good citizen in the build process.
### I've just created a maven plugin. Is there a sample plugin integration test I can use?
Each integration test is a separate project. For a plugin, you may want to create a project that will use your plugin and probably put it inside src/test/projects like maven-antrun-plugin, maven-eclipse-plugin, maven-javadoc-plugin and several others. These plugins can be found here: [https://svn.apache.org/repos/asf/maven/plugins/trunk]
-_Plugins and Lifecycle, Sites & Reporting, Integration tests_
+*Plugins and Lifecycle, Sites & Reporting, Integration tests*
### The snapshot version of the plugin is not updated in the snapshot repo, What should I do to update my copy of the plugin?
@@ -976,13 +1005,13 @@ If the plugin in the snapshot repo ([http://snapshots.maven.codehaus.org/maven2]
Currently, this type of summary information is not built into the compiler plugin, but it would be possible to add. If this feature is important to you, add your vote to [MNG-1854](http://jira.codehaus.org/browse/MNG-1854).
-_Sites & Reporting_
+*Sites & Reporting*
### In a multi-module project, is there any way for Maven to build only those modules that have changed from the previous build and leave the unchanged modules alone (i.e. not build them)?
Currently, this is not possible. The main reason is that it's non-trivial to determine whether an entire project's build is stale (the project here being one of the modules). It will be dependent on the phase being called, and the packaging of the particular module.
-_Design, Patterns & Best Practices_
+*Design, Patterns & Best Practices*
### Where can I get the Maven plugin for Eclipse?
@@ -990,7 +1019,7 @@ _Design, Patterns & Best Practices_
There are some flash demos to show the user how to use the plugin.
-_IDEs_
+*IDEs*
### Handle special characters in site
@@ -1004,6 +1033,7 @@ Honor encoding
Default to ISO-8859-1
Configuration in pom
+
```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -1013,16 +1043,18 @@ Configuration in pom
</configuration>
</plugin>
```
+
On the solaris machine
In `$HOME/.profile`
`MAVEN_OPTS="-Xmx512m -Xms512m -Dfile.encoding=ISO-8859-1` (mx/ms not mandatory for m2 but for m1).
`LANG=en_US.ISO8859-15`
- _Sites & Reporting, IDEs_
+ *Sites & Reporting, IDEs*
### How do I generate sources with the antrun plug-in?
For instance to generate sources add the following to your plugins section
NOTE: this may only work in the latest plugin version in SVN
+
```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -1053,20 +1085,21 @@ NOTE: this may only work in the latest plugin version in SVN
</executions>
</plugin>
```
- _Ant-related_
+ *Ant-related*
### Where is the plugin-registry.xml?
From the settings.xml, you may enable it by setting `<usePluginRegistry/>` to true and the file will be in `~/.m2/plugin-registry.xml`
-_General, Plugins and Lifecycle_
+*General, Plugins and Lifecycle*
### Is there a way to specify a different output directory without having to edit the pom or configuration file each time I do a build?
Yes. You can make use of the pom's `<properties>` element to accomplish this.
To do so, simply add the following fragment to your pom:
+
```
<project>
...
@@ -1081,8 +1114,10 @@ To do so, simply add the following fragment to your pom:
...
</project>
```
+
Now, to specify a different output directory at runtime simply use the directory property as a mvn command line parameter;
{code}mvn -Ddirectory=tmp package
+
```
This will send the build's output files to the ${basedir}/tmp directory.
@@ -1111,7 +1146,7 @@ i.e.
</build>
...
</project>
-```
+```
### How do I change the default remote repository?
@@ -1129,11 +1164,12 @@ Define in your POM a repository with "central" as the repository id.
</repositories>
```
- _Repositories_
+ *Repositories*
### I have my web.xml in my customed directory layout for my webapp, but why am I getting the error "Deployment descriptor `<Path>\WEB-INF\web.xml` does not exist"?
You may specify the path of your web.xml in your webapp by configuring maven-war-plugin.
+
```
<build>
...
@@ -1148,8 +1184,7 @@ You may specify the path of your web.xml in your webapp by configuring maven-war
</plugins>
</build>
```
-_Errors, Deployment_
-
+*Errors, Deployment*
### Is it possible to specify multiple `<module>`(s) in a POM at a greater depth than 1 level?
@@ -1171,45 +1206,55 @@ Add the following at the top level POM:
...
<modules>
```
+
For the second solution:
Add the following at the top level POM:
+
```
<modules>
<module>B</module>
<modules>
```
+
And in directory A/B/, add an extra parent POM and add the following:
+
```
<modules>
<module>C</module>
<modules>
```
+
Both ways are effectively the same, but if you have that inheritance structure, the second gives a more natural grouping (eg, you can cd
into "B" and build all its subprojects only).
If you do the first solution, the children poms should have the following hint in the parent element:
+
```<parent>
...
<artifactId>A</artifactId>
<relativePath>../../pom.xml</relativePath>
</parent>
```
+
The repository is still used if ../../pom.xml is not found or the versions don't match, but the hint makes it easier to use local modifications without installing the parent.
-_POM_
+*POM*
### How to list all goals available for a certain plugin?
We can use the describe goal of maven-projecthelp-plugin to list the goals available, see sample syntax below.
+
```
mvn projecthelp:describe -Dplugin=org.apache.maven.plugins:maven-eclipse-plugin -Dfull=true
```
+
This would display all the goals and descriptions of the parameters used by maven-eclipse-plugin.
\\
To get a quick overview about available mojos you can use the 'help' mojo which automatically gets generated in newer plugins.
+
```
mvn [pluginname]:help
e.g. mvn eclipse:help
```
-_Plugins and Lifecycle, IDEs_
+*Plugins and Lifecycle, IDEs*
### What does aggregator mean in mojo?
@@ -1243,8 +1288,8 @@ You can use the Maven Help Plugin's describe goal. For example, to find out the
### How can I use Ant tasks in Maven?
There are currently 2 alternatives:
-* For use in a plugin written in Java, Beanshell or other Java-like scripting language, you can construct the Ant tasks [using the instructions given in the Ant documentation](http://ant.apache.org/manual/antexternal.html)
-* If you have very small amounts of Ant script specific to your project, you can use the [AntRun plugin](http://maven.apache.org/plugins/maven-antrun-plugin/index.html).
+- For use in a plugin written in Java, Beanshell or other Java-like scripting language, you can construct the Ant tasks [using the instructions given in the Ant documentation](http://ant.apache.org/manual/antexternal.html)
+- If you have very small amounts of Ant script specific to your project, you can use the [AntRun plugin](http://maven.apache.org/plugins/maven-antrun-plugin/index.html).
### Is it possible to create my own directory structure?
@@ -1254,7 +1299,7 @@ By configuring `<sourceDirectory>`, `<resources>` and other elements of the `<bu
In addition, you may need to change the plugin configuration if you are not using plugin defaults for their files/directories.
-### Where is the source code? I couldn't seem to find a link anywhere on the Maven site.
+### Where is the source code? I couldn't seem to find a link anywhere on the Maven site
The source code can be found in subversion: [http://svn.apache.org/repos/asf/maven/components/trunk].
@@ -1264,6 +1309,7 @@ For more information, see [Building Maven](http://maven.apache.org/guides/develo
Tests are run by the surefire plugin. The surefire plugin can be configured to run certain test classes and you may have unintentionally done so by specifying a value to $
{test}. Check your settings.xml and pom.xml for a property named "test" which would like this:
+
```
...
<properties>
@@ -1274,7 +1320,9 @@ Tests are run by the surefire plugin. The surefire plugin can be configured to r
</properties>
...
```
+
or
+
```
...
<properties>
@@ -1282,16 +1330,19 @@ or
</properties>
...
```
+
### Where are the Maven XSD schemas?
The Maven XSD is located here and the Maven Settings XSD is located here.
Your favorite IDE probably supports XSD schema's for pom.xml and settings.xml editing. You need to specify the following:
+
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
...
</project>
```
+
```
<settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
@@ -1309,7 +1360,7 @@ We have compiled a list of available resources on the [getting help page](http:/
The source for the model package is generated by modello. From your maven-model source, build it and you should able to see tha java files inside /target/generated-sources directory.
-### List of available Maven mirrors.
+### List of available Maven mirrors
Here is the list of available mirrors you can use, just use one of the following mirror entries in your settings.xml
@@ -1370,6 +1421,7 @@ Place also the commons-net jar to %M2_HOME%/lib.
### How can I have a child project not inherit a goal (like install) from the parent?
Use the `inherited` property. Set it to `false` in the plugin configuration. So for example, if you want your parent project to be installed but not your child, configure the install plugin like so:
+
```
<plugin>
<artifactId>maven-install-plugin</artifactId>
@@ -1396,6 +1448,7 @@ There are no tools.jar on a mac. The classes are included in the normal java run
Refer to this link [http://lists.apple.com/archives/java-dev/2002/Jun/msg00901.html] )
You only have to modify the `<systemPath>` pointing to your classes.jar on MacOSX.
+
```
<dependency>
<groupId>sun.jdk</groupId>
@@ -1409,6 +1462,7 @@ You only have to modify the `<systemPath>` pointing to your classes.jar on MacOS
### How do I include tools.jar in my dependencies?
The following code includes tools.jar on Sun JDKs (it is already included in the runtime for Mac OS X and some free JDKs).
+
```
...
<profiles>
@@ -1445,6 +1499,7 @@ there is already some discussion about this, Please refer to this links for more
### How to make a war artifact as a dependency?
When specifying a war as dependency, make sure that you have set the `<type>` to war.
+
```
<dependency>
<groupId><!-- groupId of the war --></groupId>
@@ -1458,6 +1513,7 @@ When specifying a war as dependency, make sure that you have set the `<type>` to
By default, the location of the generated jar is in `${project.build.directory}` or in your target directory.
We can change this by configuring the outputDirectory of maven-jar-plugin.
+
```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -1494,10 +1550,13 @@ Use `$project.artifact.resolvedVersion`.
### How do I get the top line of a table to be "headers" for that column in APT?
With the snapshot you can do:
+
```
](]( header 1 ](]( header 2 ](]( header 3 ](](
```
+
Example:
+
```
*----------------+----------------*--------------------------+
](]( header 1 ](]( ]( ](]( header 2 ](]( ]( ](]( header 2 ](](
@@ -1511,6 +1570,7 @@ cell1 ]( cell1 ]( cell3
Wagon is really for repository interaction, though it could be used for this.
To get the wagon:
+
```
/* @component roleHint="http" */
Wagon wagon;
@@ -1519,6 +1579,7 @@ Wagon wagon;
### How do I set the base directory for creating the packages created by assembly?
The assembly plugin, by default, saves the packages to your project.build.directory from your pom or
+
```
<project>
...
@@ -1529,12 +1590,14 @@ The assembly plugin, by default, saves the packages to your project.build.direct
...
</project
```
+
Also, you can have assembly plugin use a different directory by setting the plugin parameter `outputDirectory` to your desired directory.
More info about the assembly plugin can be found here: [http://maven.apache.org/plugins/maven-assembly-plugin/introduction.html]
### How do I filter which classes should be put inside the packaged jar?
All compiled classes are always put into the packaged jar. However, you can configure the compiler plugin to exclude compiling some of the java sources using the compiler parameter `excludes` as follows:
+
```
<project>
...
@@ -1563,6 +1626,7 @@ Use the assembly plugin goal {{assembly:attach}} to install the generated packag
### Is it possible to use HashMap as configurable parameter in a plugin? How do I configure that in pom.xml?
Yes. Its possible to use a HashMap field as a parameter in your plugin. To use it, your pom configuration should look like this:
+
```
<myMap>
<yourkey>yourvalue</yourkey>
@@ -1604,6 +1668,7 @@ If you don't want to change your system JAVA_HOME, set it in maven script instea
### Why does release prepare goal requires the project to be released be a snapshot? Is it possible to do a release prepare from a parent project? What about from a sub-project?
The release:prepare requires the project to be released be a snapshot because it follows the maven development process where: - during development, everyone works on snapshots
+
- at release time, the snapshot got changed to release version, checked back into SCM, labelled and then built.
- the version is then incremented with snapshot and checked into SCM again.
@@ -1614,6 +1679,7 @@ When performing release:prepare in a sub project, the parent cannot be in snapsh
### How can I create an archetype with resources mapped to the class files directory?
Specify the resources to be sources as shown below:
+
```
<sources>
<source>src/main/resources/sampleXml.xml</source>
@@ -1622,7 +1688,9 @@ Specify the resources to be sources as shown below:
```
### How do I add a description to the welcome page of the generated site when I execute mvn site?
+
Fille up the `<description>` in the pom.xml as shown below:
+
```
<project>
...
@@ -1684,7 +1752,6 @@ For an example, let's say you have a Java source at src/main/java/com/junk/JunkB
</tags>
```
-
### I don't have a domain name and I don't want use my employer's domain name. What should I name my plugin package?
How will the plugin be licensed? Is it intended to just be a binary distribution or will the source be available? Where will be the documentation be? How will people find out about it?
@@ -1708,7 +1775,9 @@ I think your choice is probably influenced by these questions. One option, of co
</pluginManagement>
</build>
```
+
Make sure the generated .classpath actually contains sourcepath attributes, like this:
+
```
<classpathentry kind="var"
path="M2_REPO/javax/servlet/servlet-api/ 2.4/servlet-api-2.4.jar"
@@ -1736,16 +1805,15 @@ Make sure the generated .classpath actually contains sourcepath attributes, like
</testResources>
```
-
### How can I stop this "WARNING While downloading artifactId-artifactId-version This artifact has been relocated to groupId-artifactId-version"?
It's probably because some other dependency has specified the dependency on artifactId:artifactId. It will only go away when that declaration is fixed in that POM.
-### I would like clarification on what version of the JDK is required for m2 - particularly with respect to creating Plugins.
+### I would like clarification on what version of the JDK is required for m2 - particularly with respect to creating Plugins
1.4 is required to run m2 there're problems when using 1.5 features in plugins. People tried and failed because qdox (used for some mojo stuff doesn't support new 1.5 language)
-### i'm wondering what a "snapshot" actually is.
+### i'm wondering what a "snapshot" actually is
A snapshot is a development version. e.g, 2.0-SNAPSHOT is thestill-in-development future 2.0.If you want to use a snapshot, just use `<version>` , e.g. `<version>2.0-SNAPSHOT</version>` . But first you must ensure that you have access to the repository containing this version.
@@ -1764,10 +1832,12 @@ The best practice guideline between settings.xml and pom.xml is that configurati
For example, `<repositories>` in pom.xml would tell all users of the project to use the `<repositories>` specified in the pom.xml. However, some users may prefer to use a mirror instead, so they'll put `<mirrors>` in their settings.xml so they can choose a faster repository server.
so there you go:
+
```
settings.xml > user scope
pom.xml > project scope
```
+
### What is reactorProjects? executedProject?
`${reactorProjects}` are the projects that the current mvn command are going to be built. This will include the parent project and all its children while `${executedProject}` is the project where you typed your mvn command.
@@ -1777,6 +1847,7 @@ pom.xml > project scope
A snapshot is a development version. e.g, 2.0-SNAPSHOT is the still-in-development future 2.0.
If you want to use a snapshot, juste use `<version>` , e.g. `<version>2.0-SNAPSHOT</version>`. But first you must ensure that you have access to
the repository containing this version. For example, for Maven snapshots as stated below, you could use :
+
```
<repositories>
<repository>
@@ -1785,7 +1856,9 @@ the repository containing this version. For example, for Maven snapshots as stat
</repository>
</repositories>
```
+
or, for plugins :
+
```
<pluginRepositories>
<pluginRepository>
@@ -1794,6 +1867,7 @@ or, for plugins :
</pluginRepository>
</pluginRepositories>
```
+
Please refer to the following links
[http://maven.apache.org/guides/getting-started/index.html#How%20do%20I%20make%20my%20first%20Maven%20project?]
[http://maven.apache.org/maven-model/maven.html#class_repository]
@@ -1811,6 +1885,7 @@ post with some examples of exclusions:
### If two versions of the same dependency are at the same depth, how do you know or predict which version will be used?
The order in which dependencies are declared effectively becomes the tie-breaker when two dependency versions are declared at the same depth...so if:
+
```
A -> B, C
B -> D (v2)
@@ -1827,12 +1902,13 @@ and A declares the following:
</dependency>
</dependencies>
```
-Maven should choose D (v2) because B is declared first in the POM.
+Maven should choose D (v2) because B is declared first in the POM.
### How do I configure a project to use a specific version of a JDK?
Use the following plugin:
+
```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
@@ -1849,6 +1925,7 @@ Use the following plugin:
### Is there a way to use the current date in the POM?
Take a look at the buildnumber plugin. It can be used to generate a build date each time I do a build, as follows:
+
```<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>maven-buildnumber-plugin</artifactId>
@@ -1871,8 +1948,8 @@ Take a look at the buildnumber plugin. It can be used to generate a build date e
</executions>
</plugin>
```
-The build date is available as $buildNumber in my POMs and resource files.
+The build date is available as $buildNumber in my POMs and resource files.
### What is the purpose of remote repository (other than ibilbilo)?
@@ -1887,11 +1964,11 @@ Using mvn deploy, after inserting proper `<distributionManagement>` section into
Actually, simply copying the artifact to the repository is not the same as using deploy. The deploy goal will update various metadata files, create the md5 and sha1 checksum files, and can optionally create missing POM files etc along with actually copying the artifact file.
So there is a significant difference between the copying the file and using deploy.
-
### When I run mvn release:prepare, I get a build failure saying "Unable to tag SCM, File (...) already exists". However, the tag does not exist. What is wrong?
The full failure will look something like this:
'/stuff/tags/example/pom.xml'
+
```
[INFO\] Tagging release with the label stuff-1.0.0...
[INFO\] Executing: svn \--non-interactive copy \--file C:\DOCUME~1\G980143\LOCALS~1\Temp\maven-scm-1259783654.commit . http://www.example.com/subversion/repo/example/tags/stuff-1.0.0
@@ -1906,6 +1983,7 @@ Command output:
svn: Commit failed (details follow):
svn: File 'subversion/repo/example/tags/stuff-1.0.0/pom.xml' already exists
```
+
This will only happen in Subversion 1.5.x, and is due to a "changed behavior" in Subversion 1.5.0 and upwards. Maven and Subversion people have at the time og writing not agreed upon who should fix it. A workaround is to downgrade Subversion to version 1.4.4 and use that. Another is to manually copy the trunk/release branch to the tags directory, commit the change and then edit the release.properties file to reflect the fact that tagging has been done.
### How do I filter resources in the war?
@@ -1925,14 +2003,15 @@ For information on this topic please visit: [http://maven.apache.org/guides/mini
If you want to read a pom file, you can use the MavenXpp3Reader#read(... ).
But if you simply want to get the version of your currently running maven project inside your pom ( which is usually the case ), you can simply do:
+
```
/**
* @parameter expression="${project.version}"
*/
private String version;
```
-Also, if you have a maven project (similar to the contents of its pom except that inheritance is already applied ) and want to get its version, you can use MavenProject#getVersion().
+Also, if you have a maven project (similar to the contents of its pom except that inheritance is already applied ) and want to get its version, you can use MavenProject#getVersion().
### How can I add two different source-directories to a project?
@@ -1945,6 +2024,7 @@ You can do this by using the maven-buildhelper-plugin. It allows you to add addi
<myproperty>propertyvalue</myproperty>
</properties>
```
+
Then `$myproperty=propertyvalue`
### How do replace `<attainGoal>` from m1 in m2?
diff --git a/content/markdown/glossary.md b/content/markdown/glossary.md
index fcb73cab..188e9452 100644
--- a/content/markdown/glossary.md
+++ b/content/markdown/glossary.md
@@ -21,54 +21,54 @@ This document describes some of the most common terms encountered while
using Maven. These terms, that have an explicit meaning for Maven, can
sometimes be confusing for newcomers.
-- **Project**: Maven thinks in terms of projects. Everything that you
+- **Project**: Maven thinks in terms of projects. Everything that you
will build are projects. Those projects follow a well defined
"Project Object Model". Projects can depend on other projects, in
which case the latter are called "dependencies". A project may
consist of several subprojects, however these subprojects are
still treated equally as projects.
-- **Project Object Model (POM)**: The Project Object Model, almost
+- **Project Object Model (POM)**: The Project Object Model, almost
always referred as the POM for brevity, is the metadata that Maven
needs to work with your project. Its name is "project.xml" and it is
located in the root directory of each project.
-- **Artifact**: An artifact is something that is either produced or
+- **Artifact**: An artifact is something that is either produced or
used by a project. Examples of artifacts produced by Maven for a
project include: JARs, source and binary distributions, WARs. Each
artifact is identified by a `group id`, an
artifact ID, a version, an extension and a classifier
(extension+classifier may be named by a [type](/ref/current/maven-core/artifact-handlers.html)).
-- **GroupId**: A group ID is a universally unique identifier for a
+- **GroupId**: A group ID is a universally unique identifier for a
project. While this is often just the project name (eg.
`commons-collections`), it is helpful to use a fully-qualified
package name to distinguish it from other projects with a similar
name (eg. `org.apache.maven`).
-- **Dependency**: A typical Java project relies on libraries to build
+- **Dependency**: A typical Java project relies on libraries to build
and/or run. Those are called "dependencies" inside Maven. Those
dependencies are usually other projects' JAR artifacts, but are
referenced by the POM that describes them.
-- **Plug-in**: Maven is organized in plugins. Every piece of
+- **Plug-in**: Maven is organized in plugins. Every piece of
functionality in Maven is provided by a plugin. Plugins provide
goals and use the metadata found in the POM to perform their task.
Examples of plugins are: jar, eclipse, war. Plugins are primarily
written in Java, but Maven also supports writing plug-ins in
Beanshell and Ant Scripting.
-- **Mojo**: A plugin written in Java consists of one or more mojos. A
+- **Mojo**: A plugin written in Java consists of one or more mojos. A
mojo is a Java class that implements the
org.apache.maven.plugin.Mojo interface. This means that a mojo is
the implementation for a **goal** in a plugin.
-- **Repository**:
+- **Repository**:
Refer to [Introduction to
Repositories](./guides/introduction/introduction-to-repositories.html)
-- **Snapshots**: Projects can (and should) have a special version
+- **Snapshots**: Projects can (and should) have a special version
including `SNAPSHOT` to indicate that they are a "work in progress",
and are not yet released. When a snapshot dependency is encountered,
it is always looked for in all remote repositories, and downloaded
@@ -79,17 +79,15 @@ sometimes be confusing for newcomers.
`1.1-SNAPSHOT`, indicating development that will be released as 1.1
(i.e. newer than 1.0, but not yet 1.1).
-- **APT**: APT is a wiki-like format of documentation that Maven
+- **APT**: APT is a wiki-like format of documentation that Maven
currently understands.
For information on how to create APT files, refer to the [Guide to
creating a site](./guides/mini/guide-site.html) document.
-- **XDoc**: XDoc is the format of documentation that Maven currently
+- **XDoc**: XDoc is the format of documentation that Maven currently
understands. It is quite simple, and allows embedding XHTML within a
simple layout that is transformed into a uniform site.
For information on how to create XDoc files, refer to the [Guide to
creating a site](./guides/mini/guide-site.html) document.
-
-
diff --git a/content/markdown/guides/development/guide-building-maven.md b/content/markdown/guides/development/guide-building-maven.md
index b1d38bc3..c1819f9d 100644
--- a/content/markdown/guides/development/guide-building-maven.md
+++ b/content/markdown/guides/development/guide-building-maven.md
@@ -23,93 +23,60 @@ under the License.
## Building Maven
-
### Why would I want to build Maven?
-
Building Maven (or a plugin, or any component) yourself is for one of two reasons:
+- to try out a bleeding edge feature or bugfix (issues can be found in [JIRA](/issue-management.html)),
-
- - to try out a bleeding edge feature or bugfix (issues can be found in [ JIRA](/issue-management.html)),
-
- - to fix a problem you are having and submit a patch to the developers team.
-
-
+- to fix a problem you are having and submit a patch to the developers team.
### Checking out the sources
-
All of the source code for Maven and its related libraries is in managed in the ASF source code repositories: for details, see [https://maven.apache.org/scm.html](/scm.html).
-
-
### Building Maven
-
#### Building a Maven Plugin or Component
-
Building a Maven plugin or component is like any Maven build:
-
-
```
mvn install
```
##### Running Integration Tests
-
Before submitting a patch, it is advised to run the integration tests, which are available in the `run-its` profile:
-
-
```
mvn -Prun-its install
```
-
-
#### Building Maven core
-
Until Maven 3.3, Maven core build could be boostrapped with an Ant build. This bootstrap has been removed in Maven 3.5: you need a pre-built Maven to build Maven from source.
-
To do this, run from the source directory:
-
-
```
mvn install
```
The assemblies will be created in `apache-maven`, and can be manually unzipped to the location where you'd like the resulting Maven installed.
-
If you want to have the resulting Maven directly copied to a directory, you can use the `distributionTargetDir` property:
-
-
```
mvn -DdistributionTargetDir="$HOME/app/maven/apache-maven-SNAPSHOT" install
```
##### Running the full Maven core integration tests
-
Before checking in a change or submitting a patch to Maven core, it is required to run the core integration tests. Using your local build of Maven, run:
-
-
```
mvn test -Prun-its
```
Consult [Core ITs documentation](/core-its/) for more options.
-
-
-
-
-
diff --git a/content/markdown/guides/development/guide-committer-school.md b/content/markdown/guides/development/guide-committer-school.md
index 507f92dd..227a7abd 100644
--- a/content/markdown/guides/development/guide-committer-school.md
+++ b/content/markdown/guides/development/guide-committer-school.md
@@ -24,52 +24,36 @@ under the License.
<!-- Original post: http://javaadventure.blogspot.nl/2012/07/do-you-want-to-become-maven-committer.html -->
## Do you want to become a Maven Committer?
-
The Apache Software Foundation is a meritocracy. By this we mean that you gain status based on the merit of your work and actions. In fact the status that you gain is a recognition of the merit of your work and actions.
-
Maven is an Apache project, that means that we have to follow the Apache rules and way. One of those rules is that we cannot hand out commit access to anyone who asks for it.
-
To gain commit access you must establish your merit by submitting patches that get picked up by existing committers.
-
After you have contributed enough patches to establish merit, the project management committee decides whether you can be trusted with commit access.
-
_The reality is that "It is what it is"TL;DR To become a Maven committer write good patches and get them applied._
-
-
## What makes a good patch?
-
A good patch is a patch that applies cleanly and includes tests that cover both the positive and negative case and has documentation where relevant.
-
For example, if you were implementing a patch to fix [MNG-4612](http://issues.apache.org/jira/browse/MNG-4612) you would first need to write a test case that is failing when trying to encrypt
-
-
```
{DESede}y+qq...==
```
and a second test case that is passing when trying to encrypt
-
-
```
password
```
This is in order to be sure that you have written an effective test case that can pass for good data. Then you implement the fix and all the tests should pass. You then take a Subversion compatible† diff of the source code and attach that to the issue in question.
-
To understand how your patch gets evaluated, here is how I apply patches:
-
-
1 I look at the actual diff, if there is a whole lot of formatting changes irrelevant to the issue being fixed => **Patch is no good, ask on JIRA for a clean patch**
1 I look at the list of files in the diff, if there are no tests => **Patch is no good, ask on JIRA for test cases**
@@ -84,37 +68,24 @@ password
1 I apply the patch a second time and run the tests. If the tests all pass => **Patch is good, I commit the patch and mark the JIRA as resolved**
-
So there you have it, my guide to writing good patches... now the next step is getting your patches noticed...
-
-
## How to get your patches noticed
-
The simplest way to get your patches noticed is to submit them to the JIRA issue that they fix.
-
- Remember that the Maven project is run by volunteers in their spare time, so very often we may not notice your patch for a few days.
-
+ Remember that the Maven project is run by volunteers in their spare time, so very often we may not notice your patch for a few days.
If you are certain that your patch is a good patch, and a week has passed with no comments on JIRA, then you should send _one and only one_ email to the [dev@maven.apache.org](mailto:dev@maven.apache.org) mailing list to see if your patch can get noticed.
-
**Note:** you need to be fairly confident that your patch is a good patch, because if you keep on pestering the Maven developers looking to have non-good patches applied, your merit will become negative and people will be less inclined to help you get your patches applied... also this is why you should send one and _only one_ email about your patch on any specific JIRA issue.
-
-
## Stephen, Arnaud & Barrie's school for potential Maven committers
-
- To help people who are interested in becoming Maven committers fulfill their goals, myself, Arnaud Heritier and Barrie Treloar (along with any other current Maven committers who decide to help) will be running an assignment based class to help people become committers.
-
+ To help people who are interested in becoming Maven committers fulfill their goals, myself, Arnaud Heritier and Barrie Treloar (along with any other current Maven committers who decide to help) will be running an assignment based class to help people become committers.
To register for the class you need to complete the following steps:
-
-
1 Read the [Apache Individual Contributor License Agreement](http://www.apache.org/licenses/icla.txt). When you graduate from the class you will be required to sign this in order to become a committer.
1 Subscribe to the [dev@maven.apache.org](mailto:dev@maven.apache.org) mailing list.
@@ -129,12 +100,8 @@ If anyone knows any issues that I could take a look at I would be very much appr
Thanks
```
-
-
Once you have registered your class assignments are basically to find JIRA issues that you want to fix. The issues can be in any part of Maven, but it is best to start with the areas you have the most interest in. Once you have found a JIRA issue that you are interested in fixing, the process will work a little something like this:
-
-
1 Make sure that nobody else is working on the issue and that the issue is one that should be fixed by sending an email to the list with a Subject line something like: `\[Committer School\] Should I fix MNG-4612?` The Message body should be something like:
```
@@ -147,7 +114,6 @@ 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:
@@ -158,17 +124,10 @@ I have tested that this is a good patch and I would appreciate if a committer co
Thanks
```
-
-
- Keep in mind that the Committer School is just a way for us to identify people who are committed to developing patches with a view to eventually becoming committers.
-
+ Keep in mind that the Committer School is just a way for us to identify people who are committed to developing patches with a view to eventually becoming committers.
When we have enough evidence that we think we can get you accepted as a committer we will nominate you and hopefully your nomination will be accepted.
-
Personally, if I see somebody averaging a good patch a week for 2-3 months and being active helping out on the [users@maven.apache.org](mailto:users@maven.apache.org) and [dev@maven.apache.org](mailto:dev@maven.apache.org) mailing lists then I think I could make a strong case for such a person being given commit access.
-
So if you think you have the right stuff and want to become a Maven committer... class enrollment is open!
-
-
diff --git a/content/markdown/guides/development/guide-documentation-style.md b/content/markdown/guides/development/guide-documentation-style.md
index 8d83b9b6..62813733 100644
--- a/content/markdown/guides/development/guide-documentation-style.md
+++ b/content/markdown/guides/development/guide-documentation-style.md
@@ -23,36 +23,24 @@ under the License.
## Guide To Maven Documentation Style
-
### Where did the style came from?
-
The documentation style guide was created to make our documentation more consistent and also to apply best practices to the documentation as well. The standard has just been started and will expand over time based on the suggestions made on the Maven dev mailing list. It is a community consensus of how we should write our documentation.
-
Each rule in this guide should come with a motivation as to why it exists. References to external sources are encouraged.
-
-
### Date format
-
How people format a date varies around the world, sometimes making it hard for people to understand each other. The solution to this problem comes in the form of the ISO-8601 standard.
-
A date in our documentation must follow this standard:
-
**YYYY-MM-DD**
-
where **YYYY** is the year in the Gregorian calendar, **MM** is the month of the year between 01 (January) and 12 (December), and **DD** is the day of the month between 01 and 31.
-
**Note**: All documentation meta-data should respect this convention, for instance for this given APT document:
-
-
```
------
Guide To Maven Documentation Style
@@ -65,37 +53,26 @@ under the License.
#### References
+- [W3C Quality Web Tips](http://www.w3.org/QA/Tips/iso-date)
+- [ISO-8601](http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26780)
- - [W3C Quality Web Tips](http://www.w3.org/QA/Tips/iso-date)
-
- - [ISO-8601](http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26780)
-
- - [Wikipedia](http://en.wikipedia.org/wiki/ISO_8601)
-
+- [Wikipedia](http://en.wikipedia.org/wiki/ISO_8601)
<!-- NOTE: Add more rules here. Follow the heading style of the rule above. -->
-
### POM Snippet
-
A POM file must use 2 spaces for each indentation. Because POM snippets are often used in documentation to show the user how to configure something, it is important that these snippets aren't too wide. If they are too wide, the page is difficult to read on a smaller screen.
-
When you use a snippet of XML from the POM as an example in documentation, make sure that the example is properly indented. A user should be able to copy and paste the example into their own POM without changing the indentation.
-
Also, you should declare all parent POM elements to improve the comprehension. You could use ellipsis (i.e. ...) if you don't want to specify elements.
-
#### Example
-
The following is an example of how the distribution management of the Maven site is configured.
-
-
```
<project>
...
@@ -111,36 +88,20 @@ under the License.
As you can see above the `<distributionManagement>` element is indented once (=2 spaces), the `<site>` element is indented twice (=4 spaces), and the `<id>` is indented three times (=6 spaces).
-
-
-
### Naming Documentation Files
-
All file names should replace space by a hyphen (-), for instance for this given APT document:
-
-
```
guide-documentation-style.apt
```
-
### Updating Documentation Files
-
A good practice is to update the date (with the correct date format) when you are updating documentation files.
-
-
### Write Thinking
-
Here are some pointers about English rules when typing material:
-
-
- - [Wikipedia:Manual of Style](https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style), specifically [Punctuation Part](https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Punctuation)
-
-
-
+- [Wikipedia:Manual of Style](https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style), specifically [Punctuation Part](https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Punctuation)
diff --git a/content/markdown/guides/development/guide-helping.md b/content/markdown/guides/development/guide-helping.md
index 4ffc01f9..83734af5 100644
--- a/content/markdown/guides/development/guide-helping.md
+++ b/content/markdown/guides/development/guide-helping.md
@@ -23,85 +23,61 @@ under the License.
## Guide to helping with Maven
-
As with any open source project, there are several ways you can help:
+- Join the [mailing lists](../../mailing-lists.html) and answer other user's questions.
+- Report bugs, feature requests and other issues in the [issue management system](../../issue-management.html).
- - Join the [mailing lists](../../mailing-lists.html) and answer other user's questions.
-
- - Report bugs, feature requests and other issues in the [issue management system](../../issue-management.html).
-
- - [ Build Maven](./guide-building-maven.html) for yourself, in order to fix bugs.
+- [Build Maven](./guide-building-maven.html) for yourself, in order to fix bugs.
- - [Submit patches](./guide-maven-development.html#Creating_and_submitting_a_patch) to reported issues (both those you find, or that others have filed)\
+- [Submit patches](./guide-maven-development.html#Creating_and_submitting_a_patch) to reported issues (both those you find, or that others have filed)\
To ease your first contribution, we have a [list of "up for grabs" issues](https://s.apache.org/for-the-grabs_maven), meaning that they should be easy to work on.
- - [ test releases](./guide-testing-releases.html) help test releases that are being voted on (see the dev@maven.apache.org [ mailing list](../../mailing-lists.html) for release votes)
+- [test releases](./guide-testing-releases.html) help test releases that are being voted on (see the dev@maven.apache.org [mailing list](../../mailing-lists.html) for release votes)
- - [ test snapshot plugins](./guide-testing-development-plugins.html) help test the latest development versions of plugins and report issues
-
- - Help with the documentation by pointing out areas that are lacking or unclear, and if you can, submitting Pull Requests to correct it: use the "edit" button in the breadcrumb, just after the page title. You can also create appropriate issues [by using the issue management system](https://issues.apache.org/jira/browse/MNGSITE).
+- [test snapshot plugins](./guide-testing-development-plugins.html) help test the latest development versions of plugins and report issues
+- Help with the documentation by pointing out areas that are lacking or unclear, and if you can, submitting Pull Requests to correct it: use the "edit" button in the breadcrumb, just after the page title. You can also create appropriate issues [by using the issue management system](https://issues.apache.org/jira/browse/MNGSITE).
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 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
-
+- 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.
+- [Maven Code Style And Convention](../../developers/conventions/code.html)
+- [Maven Jira Convention](../../developers/conventions/jira.html)
- - [Maven Code Style And Convention](../../developers/conventions/code.html)
-
- - [Maven Jira Convention](../../developers/conventions/jira.html)
-
- - [Maven Git Convention](../../developers/conventions/git.html)
-
- - [Releasing a Maven project](../../developers/release/index.html)
-
- - [Apache Maven Wiki](https://cwiki.apache.org/confluence/display/MAVEN/Index)
+- [Maven Git Convention](../../developers/conventions/git.html)
+- [Releasing a Maven project](../../developers/release/index.html)
+- [Apache Maven Wiki](https://cwiki.apache.org/confluence/display/MAVEN/Index)
## Resources for committers
+- [Developer Resources](http://www.apache.org/dev/)
+- [About the Apache Software Foundation](http://www.apache.org/foundation/)
- - [ Developer Resources](http://www.apache.org/dev/)
-
- - [ About the Apache Software Foundation](http://www.apache.org/foundation/)
-
- - [ Committer FAQ](http://www.apache.org/dev/committers.html)
-
-
+- [Committer FAQ](http://www.apache.org/dev/committers.html)
diff --git a/content/markdown/guides/development/guide-maven-development.md b/content/markdown/guides/development/guide-maven-development.md
index e9eb31b9..fc79cb27 100644
--- a/content/markdown/guides/development/guide-maven-development.md
+++ b/content/markdown/guides/development/guide-maven-development.md
@@ -23,184 +23,113 @@ under the License.
## Developing Maven
-
This document describes how to get started developing Maven itself. There is a separate page describing how to [build Maven](./guide-building-maven.html).
-
### Finding some work to do
-
First of all you need something to work on! Issues can be found in [several JIRA projects](/issue-management.html).
-
- Another good place to look for work is the [ Up for grabs](https://s.apache.org/up-for-grabs_maven) list. This list contains relatively simple issues that can be worked on without a lot of prerequisite knowledge.
-
+ Another good place to look for work is the [Up for grabs](https://s.apache.org/up-for-grabs_maven) list. This list contains relatively simple issues that can be worked on without a lot of prerequisite knowledge.
When you find a issue you would like to work on, add a comment in the issue log so the core developers and other people looking for work know that someone is already working on it.
-
-
### Where's the source?
+ See [https://maven.apache.org/scm.html](/scm.html) for information. The Maven project uses the Apache GitBox Repositories, and all of them are dual-mirrored to [GitHub](https://github.com/apache/).
- See [https://maven.apache.org/scm.html](/scm.html) for information. The Maven project uses the Apache GitBox Repositories, and all of them are dual-mirrored to [ GitHub](https://github.com/apache/).
-
-
-
-### Don't forget tests!
-
+### Don't forget tests
<!-- TODO move details to guide-building-maven.apt, keep only principles here -->
You will find many unit tests. If at all possible, create or modify a unit test to demonstrate the problem, and then validate your fix.
-
If you need to mock a class to write a test, use the Mockito framework. Parts of the Maven codebase predate Mockito so you will encounter existing tests that use EasyMock, PowerMock, and JMock. However, all newly written mocks should use Mockito, even if this means a module or a single class uses multiple mocking frameworks. If an existing test class has complicated legacy mock setup, you can add new Mockito based tests in a new test class. There is no requirement that all tests for a s [...]
-
If the problem case can't be set up in the unit tests, add an integration test. Before submitting a patch, in any case, you should run all of the integration tests. The tests require an empty local repository. See [Core IT Suite documentation](/core-its/core-it-suite/) for more details.
-
-
### Creating and submitting a patch
-
The most convenient way is to create a GitHub fork from the Git repository you are working with. When you have either completed an issue or just want some feedback on the work you have done, create a pull request. We have a couple of guidelines when submitting contributions:
+- Verify the status of the `master` branch on [Maven CI](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-master-jobs.html). If it is not SUCCCESS, then first try to figure out the problem, don't start with your own issue yet! You can use `git bisect` to figure out the problematic commit and help with that committer to solve the problem.
+- Create your branch from `master`, not from a tag. Otherwise, your patch is outdated the moment you create it and might not be applicable to the development head.
- - Verify the status of the `master` branch on [Maven CI](https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-master-jobs.html). If it is not SUCCCESS, then first try to figure out the problem, don't start with your own issue yet! You can use `git bisect` to figure out the problematic commit and help with that committer to solve the problem.
-
- - Create your branch from `master`, not from a tag. Otherwise, your patch is outdated the moment you create it and might not be applicable to the development head.
-
- - If this was a new piece of work without a JIRA issue, create a JIRA issue for it now.
+- If this was a new piece of work without a JIRA issue, create a JIRA issue for it now.
- - Name the branch after the issue number; the branch name would start with `<jira-project-id>-<ticket-id>`.
+- Name the branch after the issue number; the branch name would start with `<jira-project-id>-<ticket-id>`.
- - Push your branch with the commit(s) to your fork.
-
- - Create a [ pull request](https://help.github.com/en/articles/about-pull-requests) to submit your contribution. Shortly after, someone will review the pull request and give you feedback on it.
+- Push your branch with the commit(s) to your fork.
+- Create a [pull request](https://help.github.com/en/articles/about-pull-requests) to submit your contribution. Shortly after, someone will review the pull request and give you feedback on it.
A short note:
-
-
- - Make sure that you follow our code style, see [Further Links](#further-links).
-
-
+- Make sure that you follow our code style, see [Further Links](#further-links).
### Pull request acceptance criteria
-
There are a number of criteria that a pull request will be judged on:
+- Whether it works and does what is intended. This one is probably obvious!
+- Whether it fits the spirit of the project. Some pull requests may be rejected as they take the project in a different direction than the current development community has chosen. This is usually discussed on an issue well before a pull request is contributed, so if you are unsure, discuss it there or on the mailing lists first. Feel free to continue discussing it (with new justification) if you disagree, or appeal to a wider audience on the mailing lists.
- - Whether it works and does what is intended. This one is probably obvious!
-
- - Whether it fits the spirit of the project. Some pull requests may be rejected as they take the project in a different direction than the current development community has chosen. This is usually discussed on an issue well before a pull request is contributed, so if you are unsure, discuss it there or on the mailing lists first. Feel free to continue discussing it (with new justification) if you disagree, or appeal to a wider audience on the mailing lists.
-
- - Whether it contains tests. It is expected that any pull request relating to functionality will be accompanied by unit tests and/or integration tests. It is strongly desired (and will be requested) for bug fixes too, but will not be the basis for not applying it. At a bare minimum, the change should not decrease the amount of automated test coverage. As a community, we are focusing on increasing the current coverage, as there are several areas that do not receive automated testing.
-
- - Whether it contains documentation. All new functionality needs to be documented for users, even if it is very rough for someone to expand on later. While rough is acceptable, incomplete is not. As with automated testing, as a community we are striving to increase the current coverage of documentation.
+- Whether it contains 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**
Plexus is a full-fledged container supporting different kinds of component lifecycles. Its native lifecycle is like any other modern IoC container, using field injection of both requirements and configuration. All core Maven functionality are Plexus components.
-
-
You can [read more about Plexus](https://codehaus-plexus.github.io/).
-
-
- - **Modello**
+- **Modello**
Modello is a simple tool for representing an object model and generating code and resources from the model. Maven uses Modello to generate all Java objects, XML readers and writers, XML Schema, and HTML documentation.
-
-
You can [read more about Modello](https://codehaus-plexus.github.io/modello/).
-
-
- - **Mojo**
+- **Mojo**
"Mojo" is really two things when it comes to Maven: it is both [Maven's plug-in API](/ref/current/maven-plugin-api/) and also [a separate Mojohaus project](http://www.mojohaus.org) hosting a lot of plugins.
-
-
[The MojoHaus Project](http://www.mojohaus.org) is a plugin forge for non-core Maven plugins. There is also a lower bar for becoming a part of the project.
-
-
-
-
### Sub Projects
-
-
- - **Maven Surefire**
+- **Maven Surefire**
Surefire is a testing framework. It can run regular JUnit tests so you won't have to change anything in your code to use it. It supports scripting tests in BeanShell and Jython and has special "batteries" for writing acceptance and functional tests for the web and for testing XML-RPC code.
-
-
You can [read more about Surefire](/surefire/).
-
-
- - **Maven Doxia**
+- **Maven Doxia**
Doxia is Maven's documentation engine. It has a sink and parser API that can be used to plug in support for input and output documents.
-
-
You can read more about [Doxia](/doxia/) and the currently supported [document formats](/doxia/references/index.html).
-
-
- - **Maven SCM**
+- **Maven SCM**
Maven SCM (Source Control Management) is a reusable API which is independent of Maven itself. It is used by the SCM related Maven Plugins. The core part of Maven doesn't depend on Maven SCM.
-
-
You can [read more about Scm](/scm/).
-
-
- - **Maven Wagon**
+- **Maven Wagon**
Maven Wagon is a standalone API that dealt with transporting files and directories in Maven 2.x. Maven Core today uses the Resolver Transport API, that among other implementations, contains a wrapper for Wagon as well. Also, the site plug-in uses it to publish the site.
-
-
You can [read more about Wagon](/wagon/).
-
-
-
-
### Further Links
+- [Maven Code Style And Code Convention](../../developers/conventions/code.html)
-
- - [Maven Code Style And Code Convention](../../developers/conventions/code.html)
-
- - [Maven JIRA Convention](../../developers/conventions/jira.html)
-
-
-
+- [Maven JIRA Convention](../../developers/conventions/jira.html)
diff --git a/content/markdown/guides/development/guide-plugin-documentation.md b/content/markdown/guides/development/guide-plugin-documentation.md
index 24d4b3d3..8c3d1e7a 100644
--- a/content/markdown/guides/development/guide-plugin-documentation.md
+++ b/content/markdown/guides/development/guide-plugin-documentation.md
@@ -22,31 +22,19 @@ under the License.
-->
## Introduction
-
### Where did the standard come from?
-
- The plugin documentation standard was created to address the frequent complain of lack of documentation, specifically on the Maven plugins. The standard was based on the suggestions made on the Maven dev mailing list with some refinements. It is a community consensus of what basic documentation a Maven plugin should have.
-
-
+ The plugin documentation standard was created to address the frequent complain of lack of documentation, specifically on the Maven plugins. The standard was based on the suggestions made on the Maven dev mailing list with some refinements. It is a community consensus of what basic documentation a Maven plugin should have.
### Why do we need a documentation standard?
-
The standard is not a set of rules but a guide to help plugin developers document their plugins better, for the benefit of the users of the plugin. The standard also reminds the plugin developers of the important details that needs to be documented, to help speed up the adoption of the plugin.
+## Generated Documentation
+ It is recommended that you let Maven generate the basic information for the plugin to make sure that that the basic information is always accurate and synchronized with the plugin implementation.
-
-## 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
-
-
+ Documentation is generated by running
```
mvn site
@@ -54,48 +42,37 @@ mvn site
It will generate a plugin site based on the information in the POM, `src/site` and other reporting plugins configured in the POM. The most important reporting plugin is the [Maven Plugin Plugin](/plugins/maven-plugin-plugin/) which will generate the documentation for each plugin goal based on the mojo annotations. But in order for the generated site to be usable, the required information should be available to the Maven Site Plugin.
-
### POM Elements
-
Maven extracts the information from the POM to generate the pages under Project Information. The first step in having a good documentation is to have an accurate and visible basic project information, Maven can provide this for the plugin as long as the information in the POM is complete, descriptive and accurate.
-
#### Required Elements
-
Minimum elements for a valid POM:
+- `<modelVersion>` - POM model version, currently 4.0.0
+- `<groupId>` - the package name
- - `<modelVersion>` - POM model version, currently 4.0.0
-
- - `<groupId>` - the package name
+- `<artifactId>` - artifact name
- - `<artifactId>` - artifact name
+- `<packaging>` - type of artifact produced by the POM
- - `<packaging>` - type of artifact produced by the POM
-
- - `<version>` - the plugin version
-
-
-
-#### Optional Elements
+- `<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
- - `<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_
- - `<url>` - the site of the plugin, normally _maven.apache.org_ or _org.mojohaus_
+- `<prerequisites>` - the minimum version of Maven required to use this plugin
- - `<prerequisites>` - the minimum version of Maven required to use this plugin
-
- - `<issueManagement>` - describes the system used for reporting problems and modification requests
+- `<issueManagement>` - describes the system used for reporting problems and modification requests
```
<project>
@@ -108,10 +85,9 @@ mvn site
</project>
```
+- `<inceptionYear>` - year the plugin was first created
- - `<inceptionYear>` - year the plugin was first created
-
- - `<mailingLists>` - lists where other users or the developers can be contacted for help and discussions
+- `<mailingLists>` - lists where other users or the developers can be contacted for help and discussions
```
<project>
@@ -132,8 +108,7 @@ mvn site
</project>
```
-
- - `<licenses>` - plugin license
+- `<licenses>` - plugin license
```
<project>
@@ -149,8 +124,7 @@ mvn site
</project>
```
-
- - `<scm>` - the source code management configuration - a plugin without this would raise suspicion, might not be OSS
+- `<scm>` - the source code management configuration - a plugin without this would raise suspicion, might not be OSS
```
<project>
@@ -164,8 +138,7 @@ mvn site
</project>
```
-
- - `<organization>` - the organization maintaining the plugin, just in case we need someone to blame
+- `<organization>` - the organization maintaining the plugin, just in case we need someone to blame
```
<project>
@@ -178,17 +151,10 @@ mvn site
</project>
```
-
-
-
-
### Plugin Configuration Parameters
-
The Maven Plugin Plugin is responsible for generating the Plugin Info site and needs to be added to the `<reporting>` section unless it is already inherited from a parent POM:
-
-
```
<project>
[...]
@@ -207,9 +173,7 @@ mvn site
The comments, annotations and plugin parameter names are extracted from the plugin source and rendered in the Plugin Info page. In order for the generated site to be useful here are some guidelines you can follow when documenting your plugin.
-
-
- - all `@parameter` fields should have a descriptive comment, informative enough that even a regular user can understand
+- all `@parameter` fields should have a descriptive comment, informative enough that even a regular user can understand
```
[...]
@@ -222,8 +186,7 @@ mvn site
[...]
```
-
- - class level comment should explain what the goal does
+- class level comment should explain what the goal does
```
[...]
@@ -242,24 +205,16 @@ public class ExampleMojo
[...]
```
+- the `@component` and `@readonly` parameters are not required to have any comments but it's still a good practice to provide one
- - the `@component` and `@readonly` parameters are not required to have any comments but it's still a good practice to provide one
-
-
+### Site Organization
-### 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
+ 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>
@@ -281,14 +236,10 @@ public class ExampleMojo
##### Navigation Links
-
-
- - Introduction
+- Introduction
The introduction is the front page of the plugin documentation. This is a good place to place any section and pages that needs to be emphasized. It is also suggested that the generated plugin parameter configuration be linked here. Below is the suggested `src/site/apt/index.apt` template
-
-
```
------
Introduction
@@ -340,25 +291,18 @@ Plugin Name
```
+- Goals
- - 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.
+ `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.
- - 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
+- 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">
@@ -375,44 +319,26 @@ Plugin Name
</faqs>
```
-
- - Examples
+- Examples
The advanced configurations and examples not covered in the usage page is located here. Advanced users who wants to maximize the use of a plugin can check the items here. Tips on how to use the plugin effectively is also a good thing to put here.
-
-
For examples of items under "Examples" check these plugin sites:
+- [Maven Javadoc Plugin Examples](/plugins/maven-javadoc-plugin/)
-
- - [Maven Javadoc Plugin Examples](/plugins/maven-javadoc-plugin/)
-
- - [Maven War Plugin Examples](/plugins/maven-war-plugin/)
-
-
-
-
-
-
+- [Maven War Plugin Examples](/plugins/maven-war-plugin/)
### Recommended Configured Reports
-
There are 2 recommended report plugins to enhance the plugin documentation, Javadoc and JXR.
-
-
- - Maven Javadoc Plugin
+- Maven Javadoc Plugin
Javadocs provide documentation that makes it easier for developers to know how to use a particular class. Instead of reading and understanding the actual source code, the developer can use the Javadocs instead to lookup the class attributes and methods.
-
-
To enable javadoc for your plugin add the following to your `pom.xml`
-
-
```
<project>
[...]
@@ -438,21 +364,14 @@ Plugin Name
</project>
```
-
Check the documentation about the plugin's [`javadoc:javadoc`](/plugins/maven-javadoc-plugin/javadoc-mojo.html) goal for the advanced configurations.
-
-
- - Maven JXR Plugin
+- Maven JXR Plugin
The Maven JXR Plugin generates a cross-reference of the project sources. The generated cross-references are also linked to the corresponding javadoc if javadoc is generated. The cross-references is great for those who wants to better understand the inner workings of the plugin.
-
-
To enable source code cross-references add the following to your `pom.xml`
-
-
```
<project>
[...]
@@ -472,10 +391,4 @@ Plugin Name
</project>
```
-
Check the [JXR configuration page](/plugins/maven-jxr-plugin/jxr-mojo.html) for the possible configuration parameters.
-
-
-
-
-
diff --git a/content/markdown/guides/development/guide-testing-development-plugins.md b/content/markdown/guides/development/guide-testing-development-plugins.md
index 5dfe52be..3ec34daf 100644
--- a/content/markdown/guides/development/guide-testing-development-plugins.md
+++ b/content/markdown/guides/development/guide-testing-development-plugins.md
@@ -22,36 +22,24 @@ under the License.
-->
## Guide to Testing Development Versions of Plugins
-
### Why would I want to do this?
-
If a bug you are encountering has been reported as fixed but not yet released, you can confirm that it has been fixed for you. Or perhaps you just like to live on the bleeding edge.
-
You are highly encouraged to join the development list for the project and provide your feedback, or help promote release of the plugin in question.
-
- _Note:_ This is **not** recommended as an everyday or in production practice! Snapshots are for testing purposes only and are not official releases. For more information, see [ the Releases FAQ](http://www.apache.org/dev/release.html#what).
-
-
+ _Note:_ This is **not** recommended as an everyday or in production practice! Snapshots are for testing purposes only and are not official releases. For more information, see [the Releases FAQ](http://www.apache.org/dev/release.html#what).
### How do I do this?
-
Development versions of Maven plugins are periodically published to the repository: [https://repository.apache.org/snapshots/](https://repository.apache.org/snapshots/).
-
_Note:_ Currently, this is not done automatically by our continuous integration setup. This is coming soon.
-
Other sites may publish there own - for example, the MojoHaus project hosts theirs at [https://oss.sonatype.org/content/repositories/snapshots/](https://oss.sonatype.org/content/repositories/snapshots/)
-
The first step is to include this in your project:
-
-
```
<project>
...
@@ -67,13 +55,11 @@ under the License.
After this is included, there are three ways to use the updated versions:
+- Set the appropriate version in the plugin, eg `2.0.1-SNAPSHOT`
+- If you have not specified a version, use the `-U` switch to update plugins for the given Maven run
- - 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:
+- You can have Maven automatically check for updates on a given interval, for example:
```
<project>
@@ -88,25 +74,16 @@ under the License.
</project>
```
-
-
_Note:_ These last two techniques mean that _every_ plugin will be updated to the latest snapshot version.
-
The development version will stop being used if the `<pluginRepository>` element is removed from your POM and the version is set back to the release version. If you are using the command line or an unspecified version, you will also need to remove the version from the local repository.
-
-
### Using Settings without Modifying the Project
-
If you are using the goals from the command line on a number of projects, you should include this in your `settings.xml` file instead.
-
You need to modify your `${user.home}/.m2/settings.xml` file to include two new profiles and then when you need access to the plugin snapshots use `-Papache`. The profile only needs to be enabled once so that the plugins can be downloaded into you local repository. Once in your local repository Maven can successfully resolve the dependencies and the profile no longer needs to be activated.
-
-
```
<settings>
...
@@ -134,24 +111,14 @@ under the License.
When invoking Maven for Apache profile, do it like this:
-
-
```
mvn -Papache <phase|goal>
```
-
### Using a Repository Manager
-
- In addition to the above you may want to use a repository manager so that you can retain the builds you have been using. For information on this technique, see the [ Guide to Testing Staged Releases](./guide-testing-releases.html).
-
-
+ In addition to the above you may want to use a repository manager so that you can retain the builds you have been using. For information on this technique, see the [Guide to Testing Staged Releases](./guide-testing-releases.html).
### How do I make changes to the source and test development versions of the plugins?
-
For information on this, see the [Guide to Maven Development](./guide-maven-development.html).
-
-
-
diff --git a/content/markdown/guides/development/guide-testing-releases.md b/content/markdown/guides/development/guide-testing-releases.md
index beba1ccf..8273de10 100644
--- a/content/markdown/guides/development/guide-testing-releases.md
+++ b/content/markdown/guides/development/guide-testing-releases.md
@@ -22,29 +22,22 @@ under the License.
-->
## Guide to Testing Staged Releases
-
As part of the release process, the artifacts are staged in a temporary repository for testing and evaluation before voting. Such repositories are not available by default, so to use them your project must be configured appropriately.
-
The steps are as follows:
+- add the repository or plugin repository to your POM or settings (see below)
+- ensure you are using the version being released of the artifacts in your project, e.g. by setting the `<version>` in the `<plugin>` tag.
- - 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
+- test the release
- - remove the artifacts from your local repository when you have completed testing
+- 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>
@@ -58,65 +51,48 @@ under the License.
The important thing is that the staged release does not pollute your eventual environment as it may change if the vote fails and the release is made again. This is why clearing the local repository is necessary, but if you are using a repository manager this is also important to clear. The following provides instructions for setting Archiva up in such a way that the artifacts are isolated already.
-
### Setting up Archiva to Test Staged Releases
-
These steps will be similar for any repository manager - please refer to their individual documentation for instructions on how to configure remote proxies.
-
For Archiva, the first step is to create a new managed repository for the staged releases. This will ensure they remain isolated from your environment. On the repositories tab, add a new managed repository with the settings:
+- Identifier = `staged-releases`
+- Name = Staged Releases
- - Identifier = `staged-releases`
-
- - Name = Staged Releases
-
- - Directory = `/path/to/repositories/staged-releases`
-
- - Uncheck 'Scannable'
+- 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
- - Identifier = `dfabulich.staged.releases`
-
- - Name = dfabulich Staged Releases
-
- - URL = `http://people.apache.org/\~dfabulich/staging-repo/`
-
+- URL = `http://people.apache.org/\~dfabulich/staging-repo/`
Finally, add a proxy connector to connect the two repositories:
+- Managed repository = `staged-releases`
+- Remote repository = `dfabulich.staged`
- - Managed repository = `staged-releases`
-
- - Remote repository = `dfabulich.staged`
+- Release policy = `once`
- - Release policy = `once`
-
- - Snapshot policy = `never`
-
- - White list = `org/apache/maven/\*\*`
+- 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>
@@ -127,14 +103,10 @@ under the License.
...
```
-
### Using a Settings Profile
-
If you regularly test staged releases and want to have a more convenient way to add the repository to a build without modifying your POM, you may add a profile to your `\~/.m2/settings.xml`:
-
-
```
...
<profiles>
@@ -152,13 +124,8 @@ under the License.
With this in place, you can activate it by simply changing the plugin version to the one you are testing in the POM as above, then run the build with the following command:
-
-
```
mvn verify -Pstaged-releases
```
Note that the same conditions apply as above about cleaning out the local repository to prevent pollution of your local build environment.
-
-
-
diff --git a/content/markdown/guides/getting-started/index.md b/content/markdown/guides/getting-started/index.md
index 3c472de6..fb0c5d20 100644
--- a/content/markdown/guides/getting-started/index.md
+++ b/content/markdown/guides/getting-started/index.md
@@ -22,112 +22,86 @@ under the License.
-->
## Maven Getting Started Guide
-
This guide is intended as a reference for those working with Maven for the first time, but is also intended to serve as a cookbook with self-contained references and solutions for common use cases. For first time users, it is recommended that you step through the material in a sequential fashion. For users more familiar with Maven, this guide endeavours to provide a quick solution for the need at hand. It is assumed at this point that you have downloaded Maven and installed Maven on you [...]
-
Ok, so you now have Maven installed and we're ready to go. Before we jump into our examples we'll very briefly go over what Maven is and how it can help you with your daily work and collaborative efforts with team members. Maven will, of course, work for small projects, but Maven shines in helping teams operate more effectively by allowing team members to focus on what the stakeholders of a project require. You can leave the build infrastructure to Maven!
-
-
## Sections
+- [What is Maven?](./index.html#what-is-maven)
+- [How can Maven benefit my development process?](./index.html#how-can-maven-benefit-my-development-process)
- - [What is Maven?](./index.html#what-is-maven)
-
- - [How can Maven benefit my development process?](./index.html#how-can-maven-benefit-my-development-process)
-
- - [How do I setup Maven?](./index.html#how-do---setup-maven)
+- [How do I setup Maven?](./index.html#how-do---setup-maven)
- - [How do I make my first Maven project?](./index.html#how-do-i-make-my-first-maven-project)
+- [How do I make my first Maven project?](./index.html#how-do-i-make-my-first-maven-project)
- - [How do I compile my application sources?](./index.html#how-do-i-compile-my-application-sources)
+- [How do I compile my application sources?](./index.html#how-do-i-compile-my-application-sources)
- - [How do I compile my test sources and run my unit tests?](./index.html#how-do-i-compile-my-test-sources-and-run-my-unit-tests)
+- [How do I compile my test sources and run my unit tests?](./index.html#how-do-i-compile-my-test-sources-and-run-my-unit-tests)
- - [How do I create a JAR and install it in my local repository?](./index.html#how-do-i-create-a-jar-and-install-it-in-my-local-repository)
+- [How do I create a JAR and install it in my local repository?](./index.html#how-do-i-create-a-jar-and-install-it-in-my-local-repository)
- - [What is a SNAPSHOT version?](./index.html#what-is-a-snapshot-version)
+- [What is a SNAPSHOT version?](./index.html#what-is-a-snapshot-version)
- - [How do I use plugins?](./index.html#how-do-i-use-plugins)
+- [How do I use plugins?](./index.html#how-do-i-use-plugins)
- - [How do I add resources to my JAR?](./index.html#how-do-i-add-resources-to-my-jar)
+- [How do I add resources to my JAR?](./index.html#how-do-i-add-resources-to-my-jar)
- - [How do I filter resource files?](./index.html#how-do-i-filter-resource-files)
+- [How do I filter resource files?](./index.html#how-do-i-filter-resource-files)
- - [How do I use external dependencies?](./index.html#how-do-i-use-external-dependencies)
+- [How do I use external dependencies?](./index.html#how-do-i-use-external-dependencies)
- - [How do I deploy my jar in my remote repository?](./index.html#how-do-i-deploy-my-jar-in-my-remote-repository)
+- [How do I deploy my jar in my remote repository?](./index.html#how-do-i-deploy-my-jar-in-my-remote-repository)
- - [How do I create documentation?](./index.html#how-do-i-create-documentation)
+- [How do I create documentation?](./index.html#how-do-i-create-documentation)
- - [How do I build other types of projects?](./index.html#how-do-i-build-other-types-of-projects)
-
- - [How do I build more than one project at once?](./index.html#how-do-i-build-more-than-one-project-at-once)
+- [How do I build other types of projects?](./index.html#how-do-i-build-other-types-of-projects)
+- [How do I build more than one project at once?](./index.html#how-do-i-build-more-than-one-project-at-once)
### 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
- - Builds
-
- - Documentation
+- Reporting
- - Reporting
+- Dependencies
- - Dependencies
+- SCMs
- - SCMs
-
- - Releases
-
- - Distribution
+- Releases
+- Distribution
If you want more background information on Maven you can check out [The Philosophy of Maven](../../background/philosophy-of-maven.html) and [The History of Maven](../../background/history-of-maven.html). Now let's move on to how you, the user, can benefit from using Maven.
-
-
### How can Maven benefit my development process?
-
Maven can provide benefits for your build process by employing standard conventions and practices to accelerate your development cycle while at the same time helping you achieve a higher rate of success.
-
Now that we have covered a little bit of the history and purpose of Maven let's get into some real examples to get you up and running with Maven!
-
-
### How do I setup Maven?
-
- The defaults for Maven are often sufficient, but if you need to change the cache location or are behind a HTTP proxy, you will need to create configuration. See the [ Guide to Configuring Maven](../mini/guide-configuring-maven.html) for more information.
-
-
+ The defaults for Maven are often sufficient, but if you need to change the cache location or are behind a HTTP proxy, you will need to create configuration. See the [Guide to Configuring Maven](../mini/guide-configuring-maven.html) for more information.
### How do I make my first Maven project?
-
We are going to jump headlong into creating your first Maven project! To create our first Maven project we are going to use Maven's archetype mechanism. An archetype is defined as _an original pattern or model from which all other things of the same kind are made_. In Maven, an archetype is a template of a project which is combined with some user input to produce a working Maven project that has been tailored to the user's requirements. We are going to show you how the archetype mechani [...]
-
On to creating your first project! In order to create the simplest of Maven projects, execute the following from the command line:
-
-
```
mvn -B archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
```
Once you have executed this command, you will notice a few things have happened. First, you will notice that a directory named `my-app` has been created for the new project, and this directory contains a file named `pom.xml` that should look like this:
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -166,39 +140,32 @@ mvn -B archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -Darch
`pom.xml` contains the Project Object Model (POM) for this project. The POM is the basic unit of work in Maven. This is important to remember because Maven is inherently project-centric in that everything revolves around the notion of a project. In short, the POM contains every important piece of information about your project and is essentially one-stop-shopping for finding anything related to your project. Understanding the POM is important and new users are encouraged to refer to the [...]
-
This is a very simple POM but still displays the key elements every POM contains, so let's walk through each of them to familiarize you with the POM essentials:
+- **project** This is the top-level element in all Maven pom.xml files.
+- **modelVersion** This element indicates what version of the object model this POM is using. The version of the model itself changes very infrequently but it is mandatory in order to ensure stability of use if and when the Maven developers deem it necessary to change the model.
- - **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`).
+- **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.
- - **version** This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the `SNAPSHOT` designator in a version, which indicates that a project is in a state of development. We will discuss the use of [snapshots](./index.html#what-is-a-snapshot-version) and how they work further on in this guide.
+- **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`).
- - **name** This element indicates the display name used for the project. This is often used in Maven's generated documentation.
+- **version** This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the `SNAPSHOT` designator in a version, which indicates that a project is in a state of development. We will discuss the use of [snapshots](./index.html#what-is-a-snapshot-version) and how they work further on in this guide.
- - **url** This element indicates where the project's site can be found. This is often used in Maven's generated documentation.
+- **name** This element indicates the display name used for the project. This is often used in Maven's generated documentation.
- - **properties** This element contains value placeholders accessible anywhere within a POM.
+- **url** This element indicates where the project's site can be found. This is often used in Maven's generated documentation.
- - **dependencies** This element's children list [dependencies](/pom.html#dependencies). The cornerstone of the POM.
+- **properties** This element contains value placeholders accessible anywhere within a POM.
- - **build** This element handles things like declaring your project's directory structure and managing plugins.
+- **dependencies** This element's children list [dependencies](/pom.html#dependencies). The cornerstone of the POM.
+- **build** This element handles things like declaring your project's directory structure and managing plugins.
For a complete reference of what elements are available for use in the POM please refer to our [POM Reference](/ref/current/maven-model/maven.html). Now let's get back to the project at hand.
-
After the archetype generation of your first project you will also notice that the following directory structure has been created:
-
-
```
my-app
|-- pom.xml
@@ -219,29 +186,20 @@ my-app
As you can see, the project created from the archetype has a POM, a source tree for your application's sources and a source tree for your test sources. This is the standard layout for Maven projects (the application sources reside in `${basedir}/src/main/java` and test sources reside in `${basedir}/src/test/java`, where `${basedir}` represents the directory containing `pom.xml`).
-
If you were to create a Maven project by hand this is the directory structure that we recommend using. This is a Maven convention and to learn more about it you can read our [Introduction to the Standard Directory Layout](../introduction/introduction-to-the-standard-directory-layout.html).
-
Now that we have a POM, some application sources, and some test sources you are probably asking...
-
-
### How do I compile my application sources?
-
Change to the directory where pom.xml is created by archetype:generate and execute the following command to compile your application sources:
-
-
```
mvn compile
```
Upon executing this command you should see output like the following:
-
-
```
[INFO] Scanning for projects...
[INFO]
@@ -266,32 +224,22 @@ mvn compile
The first time you execute this (or any other) command, Maven will need to download all the plugins and related dependencies it needs to fulfill the command. From a clean installation of Maven, this can take quite a while (in the output above, it took almost 4 minutes). If you execute the command again, Maven will now have what it needs, so it won't need to download anything new and will be able to execute the command much more quickly.
-
As you can see from the output, the compiled classes were placed in `${basedir}/target/classes`, which is another standard convention employed by Maven. So, if you're a keen observer, you'll notice that by using the standard conventions, the POM above is very small and you haven't had to tell Maven explicitly where any of your sources are or where the output should go. By following the standard Maven conventions, you can get a lot done with very little effort! Just as a casual compariso [...]
-
Now, this is simply to compile a single tree of application sources and the Ant script shown is pretty much the same size as the POM shown above. But we'll see how much more we can do with just that simple POM!
-
-
### How do I compile my test sources and run my unit tests?
-
Now you're successfully compiling your application's sources and now you've got some unit tests that you want to compile and execute (because every programmer always writes and executes their unit tests \*nudge nudge wink wink\*).
-
Execute the following command:
-
-
```
mvn test
```
Upon executing this command you should see output like the following:
-
-
```
[INFO] Scanning for projects...
[INFO]
@@ -336,31 +284,22 @@ mvn test
Some things to notice about the output:
+- Maven downloads more dependencies this time. These are the dependencies and plugins necessary for executing the tests (it already has the dependencies it needs for compiling and won't download them again).
-
- - 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).
-
+- 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 -->
```
@@ -369,19 +308,14 @@ mvn package
You can now take a look in the `${basedir}/target` directory and you will see the generated JAR file.
-
Now you'll want to install the artifact you've generated (the JAR file) in your local repository (`${user.home}/.m2/repository` is the default location). For more information on repositories you can refer to our [Introduction to Repositories](../introduction/introduction-to-repositories.html) but let's move on to installing our artifact! To do so execute the following command:
-
-
```
mvn install
```
Upon executing this command you should see the following output:
-
-
```
[INFO] Scanning for projects...
[INFO]
@@ -428,54 +362,38 @@ mvn install
Note that the surefire plugin (which executes the test) looks for tests contained in files with a particular naming convention. By default the tests included are:
+- `\*\*/\*Test.java`
+- `\*\*/Test\*.java`
- - `\*\*/\*Test.java`
-
- - `\*\*/Test\*.java`
-
- - `\*\*/\*TestCase.java`
-
+- `\*\*/\*TestCase.java`
And the default excludes are:
+- `\*\*/Abstract\*Test.java`
-
- - `\*\*/Abstract\*Test.java`
-
- - `\*\*/Abstract\*TestCase.java`
-
+- `\*\*/Abstract\*TestCase.java`
You have walked through the process for setting up, building, testing, packaging, and installing a typical Maven project. This is likely the vast majority of what projects will be doing with Maven and if you've noticed, everything you've been able to do up to this point has been driven by an 18-line file, namely the project's model or POM. If you look at a typical Ant [build file](../../ant/build-a1.xml) that provides the same functionality that we've achieved thus far you'll notice it' [...]
-
So what else can you get for free? There are a great number of Maven plugins that work out of the box with even a simple POM like we have above. We'll mention one here specifically as it is one of the highly prized features of Maven: without any work on your part this POM has enough information to generate a web site for your project! You will most likely want to customize your Maven site but if you're pressed for time all you need to do to provide basic information about your project i [...]
-
-
```
mvn site
```
There are plenty of other standalone goals that can be executed as well, for example:
-
-
```
mvn clean
```
This will remove the `target` directory with all the build data before starting so that it is fresh.
-
-
### What is a SNAPSHOT version?
-
Notice the value of the **version** tag in the `pom.xml` file shown below has the suffix: `-SNAPSHOT`.
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0"
...
@@ -489,24 +407,16 @@ mvn clean
The `SNAPSHOT` value refers to the 'latest' code along a development branch, and provides no guarantee the code is stable or unchanging. Conversely, the code in a 'release' version (any version value without the suffix `SNAPSHOT`) is unchanging.
-
In other words, a SNAPSHOT version is the 'development' version before the final 'release' version. The SNAPSHOT is "older" than its release.
-
During the [release](../../plugins/maven-release-plugin/) process, a version of **x.y-SNAPSHOT** changes to **x.y**. The release process also increments the development version to **x.(y+1)-SNAPSHOT**. For example, version **1.0-SNAPSHOT** is released as version **1.0**, and the new development version is version **1.1-SNAPSHOT**.
-
-
### How do I use plugins?
-
Whenever you want to customise the build for a Maven project, this is done by adding or reconfiguring plugins.
-
For this example, we will configure the Java compiler to allow JDK 5.0 sources. This is as simple as adding this to your POM:
-
-
```
...
<build>
@@ -527,24 +437,16 @@ mvn clean
You'll notice that all plugins in Maven look much like a dependency - and in some ways they are. This plugin will be automatically downloaded and used - including a specific version if you request it (the default is to use the latest available).
+ The `configuration` element applies the given parameters to every goal from the compiler plugin. In the above case, the compiler plugin is already used as part of the build process and this just changes the configuration. It is also possible to add new goals to the process, and configure specific goals. For information on this, see the [Introduction to the Build Lifecycle](../introduction/introduction-to-the-lifecycle.html).
- The `configuration` element applies the given parameters to every goal from the compiler plugin. In the above case, the compiler plugin is already used as part of the build process and this just changes the configuration. It is also possible to add new goals to the process, and configure specific goals. For information on this, see the [ Introduction to the Build Lifecycle](../introduction/introduction-to-the-lifecycle.html).
-
-
- To find out what configuration is available for a plugin, you can see the [ Plugins List](../../plugins/) and navigate to the plugin and goal you are using. For general information about how to configure the available parameters of a plugin, have a look at the [Guide to Configuring Plugins](../mini/guide-configuring-plugins.html).
-
-
+ To find out what configuration is available for a plugin, you can see the [Plugins List](../../plugins/) and navigate to the plugin and goal you are using. For general information about how to configure the available parameters of a plugin, have a look at the [Guide to Configuring Plugins](../mini/guide-configuring-plugins.html).
### How do I add resources to my JAR?
-
Another common use case that can be satisfied which requires no changes to the POM that we have above is packaging resources in the JAR file. For this common task, Maven again relies on the [Standard Directory Layout](../introduction/introduction-to-the-standard-directory-layout.html), which means by using standard Maven conventions you can package resources within JARs simply by placing those resources in a standard directory structure.
-
You see below in our example we have added the directory `${basedir}/src/main/resources` into which we place any resources we wish to package in our JAR. The simple rule employed by Maven is this: any directories or files placed within the `${basedir}/src/main/resources` directory are packaged in your JAR with the exact same structure starting at the base of the JAR.
-
-
```
my-app
|-- pom.xml
@@ -568,8 +470,6 @@ my-app
So you can see in our example that we have a `META-INF` directory with an `application.properties` file within that directory. If you unpacked the JAR that Maven created for you and took a look at it you would see the following:
-
-
```
|-- META-INF
| |-- MANIFEST.MF
@@ -587,8 +487,6 @@ my-app
As you can see, the contents of `${basedir}/src/main/resources` can be found starting at the base of the JAR and our `application.properties` file is there in the `META-INF` directory. You will also notice some other files there like `META-INF/MANIFEST.MF` as well as a `pom.xml` and `pom.properties` file. These come standard with generation of a JAR in Maven. You can create your own manifest if you choose, but Maven will generate one by default if you don't. (You can also modify the ent [...]
-
-
```
#Generated by Maven
#Tue Oct 04 15:43:21 GMT-05:00 2005
@@ -599,8 +497,6 @@ 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
@@ -626,8 +522,6 @@ my-app
In a unit test you could use a simple snippet of code like the following to access the resource required for testing:
-
-
```
...
@@ -639,17 +533,12 @@ InputStream is = getClass().getResourceAsStream( "/test.properties" );
...
```
-
### How do I filter resource files?
-
Sometimes a resource file will need to contain a value that can only be supplied at build time. To accomplish this in Maven, put a reference to the property that will contain the value into your resource file using the syntax `${<property name>}`. The property can be one of the values defined in your pom.xml, a value defined in the user's settings.xml, a property defined in an external properties file, or a system property.
-
To have Maven filter resources when copying, simply set `filtering` to true for the resource directory in your `pom.xml`:
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -685,14 +574,10 @@ InputStream is = getClass().getResourceAsStream( "/test.properties" );
You'll notice that we had to add the `build`, `resources`, and `resource` elements which weren't there before. In addition, we had to explicitly state that the resources are located in the src/main/resources directory. All of this information was provided as default values previously, but because the default value for `filtering` is false, we had to add this to our pom.xml in order to override that default value and set `filtering` to true.
-
To reference a property defined in your pom.xml, the property name uses the names of the XML elements that define the value, with "pom" being allowed as an alias for the project (root) element. So `${project.name}` refers to the name of the project, `${project.version}` refers to the version of the project, `${project.build.finalName}` refers to the final name of the file created when the built project is packaged, etc. Note that some elements of the POM have default values, so don't ne [...]
-
To continue our example, let's add a couple of properties to the `application.properties` file (which we put in the `src/main/resources` directory) whose values will be supplied when the resource is filtered:
-
-
```
# application.properties
application.name=${project.name}
@@ -701,16 +586,12 @@ 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
@@ -719,8 +600,6 @@ 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!
@@ -728,8 +607,6 @@ 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">
@@ -768,8 +645,6 @@ my.filter.value=hello!
Then, if we add a reference to this property in the `application.properties` file:
-
-
```
# application.properties
application.name=${project.name}
@@ -779,8 +654,6 @@ 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">
@@ -820,8 +693,6 @@ message=${my.filter.value}
Filtering resources can also get values from system properties; either the system properties built into Java (like `java.version` or `user.home`) or properties defined on the command line using the standard Java -D parameter. To continue the example, let's change our `application.properties` file to look like this:
-
-
```
# application.properties
java.version=${java.version}
@@ -830,23 +701,16 @@ command.line.prop=${command.line.prop}
Now, when you execute the following command (note the definition of the command.line.prop property on the command line), the `application.properties` file will contain the values from the system properties.
-
-
```
mvn process-resources "-Dcommand.line.prop=hello again"
```
-
### How do I use external dependencies?
-
You've probably already noticed a `dependencies` element in the POM we've been using as an example. You have, in fact, been using an external dependency all this time, but here we'll talk about how this works in a bit more detail. For a more thorough introduction, please refer to our [Introduction to Dependency Mechanism](../introduction/introduction-to-dependency-mechanism.html).
-
The `dependencies` section of the pom.xml lists all of the external dependencies that our project needs in order to build (whether it needs that dependency at compile time, test time, run time, or whatever). Right now, our project is depending on JUnit only (I took out all of the resource filtering stuff for clarity):
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -873,15 +737,11 @@ mvn process-resources "-Dcommand.line.prop=hello again"
For each external dependency, you'll need to define at least 4 things: groupId, artifactId, version, and scope. The groupId, artifactId, and version are the same as those given in the `pom.xml` for the project that built that dependency. The scope element indicates how your project uses that dependency, and can be values like `compile`, `test`, and `runtime`. For more information on everything you can specify for a dependency, see the [Project Descriptor Reference](/ref/current/maven-mo [...]
-
<!-- DJ: Does this link work? I can't find the document. -->
For more information about the dependency mechanism as a whole, see [Introduction to Dependency Mechanism](../introduction/introduction-to-dependency-mechanism.html).
-
With this information about a dependency, Maven will be able to reference the dependency when it builds the project. Where does Maven reference the dependency from? Maven looks in your local repository (`${user.home}/.m2/repository` is the default location) to find all dependencies. In a [previous section](#how-do-i-create-a-jar-and-install-it-in-my-local-repository), we installed the artifact from our project (my-app-1.0-SNAPSHOT.jar) into the local repository. Once it's installed ther [...]
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -902,11 +762,8 @@ mvn process-resources "-Dcommand.line.prop=hello again"
What about dependencies built somewhere else? How do they get into my local repository? Whenever a project references a dependency that isn't available in the local repository, Maven will download the dependency from a remote repository into the local repository. You probably noticed Maven downloading a lot of things when you built your very first project (these downloads were dependencies for the various plugins used to build the project). By default, the remote repository Maven uses c [...]
-
Let's add another dependency to our project. Let's say we've added some logging to the code and need to add log4j as a dependency. First, we need to know what the groupId, artifactId, and version are for log4j. The appropriate directory on Maven Central is called [/maven2/log4j/log4j](https://repo.maven.apache.org/maven2/log4j/log4j/). In that directory is a file called maven-metadata.xml. Here's what the maven-metadata.xml for log4j looks like:
-
-
```
<metadata>
<groupId>log4j</groupId>
@@ -930,11 +787,8 @@ mvn process-resources "-Dcommand.line.prop=hello again"
From this file, we can see that the groupId we want is "log4j" and the artifactId is "log4j". We see lots of different version values to choose from; for now, we'll just use the latest version, 1.2.12 (some maven-metadata.xml files may also specify which version is the current release version: see [repository metadata reference](/ref/current/maven-repository-metadata/repository-metadata.html)). Alongside the maven-metadata.xml file, we can see a directory corresponding to each version o [...]
-
Now that we know the information we need, we can add the dependency to our pom.xml:
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -967,19 +821,14 @@ mvn process-resources "-Dcommand.line.prop=hello again"
Now, when we compile the project (`mvn compile`), we'll see Maven download the log4j dependency for us.
-
<!-- DJ: Current -->
### How do I deploy my jar in my remote repository?
-
For deploying jars to an external repository, you have to configure the repository url in the pom.xml and the authentication information for connecting to the repository in the settings.xml.
-
Here is an example using scp and username/password authentication:
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -1033,7 +882,6 @@ mvn process-resources "-Dcommand.line.prop=hello again"
</project>
```
-
```
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
@@ -1053,18 +901,12 @@ mvn process-resources "-Dcommand.line.prop=hello again"
Note that if you are connecting to an openssh ssh server which has the parameter "PasswordAuthentication" set to "no" in the sshd_confing, you will have to type your password each time for username/password authentication (although you can log in using another ssh client by typing in the username and password). You might want to switch to public key authentication in this case.
-
- Care should be taken if using passwords in `settings.xml`. For more information, see [ Password Encryption](../mini/guide-encryption.html).
-
-
+ Care should be taken if using passwords in `settings.xml`. For more information, see [Password Encryption](../mini/guide-encryption.html).
### How do I create documentation?
-
To get you jump started with Maven's documentation system you can use the archetype mechanism to generate a site for your existing project using the following command:
-
-
```
mvn archetype:generate \
-DarchetypeGroupId=org.apache.maven.archetypes \
@@ -1075,15 +917,10 @@ mvn archetype:generate \
Now head on over to the [Guide to creating a site](../mini/guide-site.html) to learn how to create the documentation for your project.
-
-
### How do I build other types of projects?
-
Note that the lifecycle applies to any project type. For example, back in the base directory we can create a simple web application:
-
-
```
mvn archetype:generate \
-DarchetypeGroupId=org.apache.maven.archetypes \
@@ -1094,8 +931,6 @@ mvn archetype:generate \
Note that these must all be on a single line. This will create a directory called `my-webapp` containing the following project descriptor:
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -1123,26 +958,18 @@ mvn archetype:generate \
Note the `<packaging>` element - this tells Maven to build as a WAR. Change into the webapp project's directory and try:
-
-
```
mvn package
```
You'll see `target/my-webapp.war` is built, and that all the normal steps were executed.
-
-
### How do I build more than one project at once?
-
The concept of dealing with multiple modules is built in to Maven. In this section, we will show how to build the WAR above, and include the previous JAR as well in one step.
-
Firstly, we need to add a parent `pom.xml` file in the directory above the other two, so it should look like this:
-
-
```
+- pom.xml
+- my-app
@@ -1159,8 +986,6 @@ mvn package
The POM file you'll create should contain the following:
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -1180,8 +1005,6 @@ mvn package
We'll need a dependency on the JAR from the webapp, so add this to `my-webapp/pom.xml`:
-
-
```
...
<dependencies>
@@ -1196,8 +1019,6 @@ mvn package
Finally, add the following `<parent>` element to both of the other `pom.xml` files in the subdirectories:
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -1211,16 +1032,12 @@ mvn package
Now, try it... from the top level directory, run:
-
-
```
mvn verify
```
The WAR has now been created in `my-webapp/target/my-webapp.war`, and the JAR is included:
-
-
```
$ jar tvf my-webapp/target/my-webapp-1.0-SNAPSHOT.war
0 Fri Jun 24 10:59:56 EST 2005 META-INF/
@@ -1239,14 +1056,8 @@ $ jar tvf my-webapp/target/my-webapp-1.0-SNAPSHOT.war
How does this work? Firstly, the parent POM created (called `app`), has a packaging of `pom` and a list of modules defined. This tells Maven to run all operations over the set of projects instead of just the current one (to override this behaviour, you can use the `--non-recursive` command line option).
-
Next, we tell the WAR that it requires the `my-app` JAR. This does a few things: it makes it available on the classpath to any code in the WAR (none in this case), it makes sure the JAR is always built before the WAR, and it indicates to the WAR plugin to include the JAR in its library directory.
-
You may have noticed that `junit-4.11.jar` was a dependency, but didn't end up in the WAR. The reason for this is the `<scope>test</scope>` element - it is only required for testing, and so is not included in the web application as the compile time dependency `my-app` is.
-
The final step was to include a parent definition. This ensures that the POM can always be located even if the project is distributed separately from its parent by looking it up in the repository.
-
-
-
diff --git a/content/markdown/guides/getting-started/maven-in-five-minutes.md b/content/markdown/guides/getting-started/maven-in-five-minutes.md
index 4413fd76..2e2bc8ce 100644
--- a/content/markdown/guides/getting-started/maven-in-five-minutes.md
+++ b/content/markdown/guides/getting-started/maven-in-five-minutes.md
@@ -22,32 +22,22 @@ under the License.
-->
## Maven in 5 Minutes
-
### Prerequisites
-
You must understand how to install software on your computer. If you do not know how to do this, please ask someone at your office, school, etc. or pay someone to explain this to you. The Maven mailing lists are not the best place to ask for this advice.
-
-
### Installation
-
_Maven is a Java tool, so you must have [Java](https://www.oracle.com/technetwork/java/javase/downloads/index.html) installed in order to proceed._
-
First, [download Maven](../../download.html) and follow the [installation instructions](../../install.html). After that, type the following in a terminal or in a command prompt:
-
-
```
mvn --version
```
It should print out your installed version of Maven, for example:
-
-
```
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: D:\apache-maven-3.6.3\apache-maven\bin\..
@@ -58,37 +48,26 @@ OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Depending upon your network setup, you may require extra configuration. Check out the [Guide to Configuring Maven](../mini/guide-configuring-maven.html) if necessary.
-
**If you are using Windows, you should look at** [Windows Prerequisites](./windows-prerequisites.html) **to ensure that you are prepared to use Maven on Windows.**
-
-
### Creating a Project
-
You need somewhere for your project to reside. Create a directory somewhere and start a shell in that directory. On your command line, execute the following Maven goal:
-
-
```
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false
```
_If you have just installed Maven, it may take a while on the first run. This is because Maven is downloading the most recent artifacts (plugin jars and other files) into your local repository. You may also need to execute the command a couple of times before it succeeds. This is because the remote server may time out before your downloads are complete. Don't worry, there are ways to fix that._
-
You will notice that the _generate_ goal created a directory with the same name given as the artifactId. Change into that directory.
-
-
```
cd my-app
```
Under this directory you will notice the following [standard project structure](../introduction/introduction-to-the-standard-directory-layout.html).
-
-
```
my-app
|-- pom.xml
@@ -109,14 +88,10 @@ my-app
The `src/main/java` directory contains the project source code, the `src/test/java` directory contains the test source, and the `pom.xml` file is the project's Project Object Model, or POM.
-
#### The POM
-
The `pom.xml` file is the core of a project's configuration in Maven. It is a single configuration file that contains the majority of information required to build a project in just the way you want. The POM is huge and can be daunting in its complexity, but it is not necessary to understand all of the intricacies just yet to use it effectively. This project's POM is:
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -142,26 +117,18 @@ my-app
</project>
```
-
#### What did I just do?
-
You executed the Maven goal _archetype:generate_, and passed in various parameters to that goal. The prefix _archetype_ is the [plugin](../../plugins/index.html) that provides the goal. If you are familiar with [Ant](http://ant.apache.org), you may conceive of this as similar to a task. This _archetype:generate_ goal created a simple project based upon a [maven-archetype-quickstart](/archetypes/maven-archetype-quickstart/) archetype. Suffice it to say for now that a _plugin_ is a collec [...]
-
-
#### Build the Project
-
-
```
mvn package
```
The command line will print out various actions, and end with the following:
-
-
```
...
[INFO] ------------------------------------------------------------------------
@@ -174,8 +141,6 @@ mvn package
Unlike the first command executed (_archetype:generate_), the second is simply a single word - _package_. Rather than a _goal_, this is a _phase_. A phase is a step in the [build lifecycle](../introduction/introduction-to-the-lifecycle.html), which is an ordered sequence of phases. When a phase is given, Maven executes every phase in the sequence up to and including the one defined. For example, if you execute the _compile_ phase, the phases that actually get executed are:
-
-
1 validate
1 generate-sources
@@ -188,35 +153,24 @@ mvn package
1 compile
-
You may test the newly compiled and packaged JAR with the following command:
-
-
```
java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App
```
Which will print the quintessential:
-
-
```
Hello World!
```
-
-
### Java 9 or later
-
By default your version of Maven might use an old version of the `maven-compiler-plugin` that is not compatible with Java 9 or later versions. To target Java 9 or later, you should at least use version 3.6.0 of the `maven-compiler-plugin` and set the `maven.compiler.release` property to the Java release you are targetting (e.g. 9, 10, 11, 12, etc.).
-
In the following example, we have configured our Maven project to use version 3.8.1 of `maven-compiler-plugin` and target Java 11:
-
-
```
<properties>
<maven.compiler.release>11</maven.compiler.release>
@@ -237,78 +191,52 @@ Hello World!
To learn more about `javac`'s `--release` option, see [JEP 247](https://openjdk.java.net/jeps/247).
-
-
### Running Maven Tools
-
#### Maven Phases
-
Although hardly a comprehensive list, these are the most common _default_ lifecycle phases executed.
+- **validate**: validate the project is correct and all necessary information is available
+- **compile**: compile the source code of the project
- - **validate**: validate the project is correct and all necessary information is available
+- **test**: test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
- - **compile**: compile the source code of the project
+- **package**: take the compiled code and package it in its distributable format, such as a JAR.
- - **test**: test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
+- **integration-test**: process and deploy the package if necessary into an environment where integration tests can be run
- - **package**: take the compiled code and package it in its distributable format, such as a JAR.
+- **verify**: run any checks to verify the package is valid and meets quality criteria
- - **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.
+- **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
-
- - **clean**: cleans up artifacts created by prior builds
-
-
-
- - **site**: generates site documentation for this project
-
+- **site**: generates site documentation for this project
Phases are actually mapped to underlying goals. The specific goals executed per phase is dependant upon the packaging type of the project. For example, _package_ executes _jar:jar_ if the project type is a JAR, and _war:war_ if the project type is - you guessed it - a WAR.
-
An interesting thing to note is that phases and goals may be executed in sequence.
-
-
```
mvn clean dependency:copy-dependencies package
```
This command will clean the project, copy dependencies, and package the project (executing all phases up to _package_, of course).
-
-
#### Generating the Site
-
-
```
mvn site
```
This phase generates a site based upon information on the project's pom. You can look at the documentation generated under `target/site`.
-
-
-
### Conclusion
-
We hope this quick overview has piqued your interest in the versatility of Maven. Note that this is a very truncated quick-start guide. Now you are ready for more comprehensive details concerning the actions you have just performed. Check out the [Maven Getting Started Guide](./index.html).
-
-
-
diff --git a/content/markdown/guides/getting-started/windows-prerequisites.md b/content/markdown/guides/getting-started/windows-prerequisites.md
index 2f970aea..1394d25d 100644
--- a/content/markdown/guides/getting-started/windows-prerequisites.md
+++ b/content/markdown/guides/getting-started/windows-prerequisites.md
@@ -22,46 +22,28 @@ under the License.
-->
## Maven on Windows
-
Maven is a command-line tool for building Java (and other) programs. The Maven project provides a simple ZIP file containing a precompiled version of Maven for your convenience. There is no installer. It's up to you to set up your prerequisites and environment to run Maven on Windows.
-
### Prerequisites
-
Maven is written in Java (and primarily used to build Java programs). Thus, the major prerequisite is the Java SDK. You need to install the Java SDK (e.g. from [Oracle's download site](https://www.oracle.com/technetwork/java/javase/downloads/index.html)).
-
Once Java is installed, you must ensure that the commands from the Java SDK are in your PATH environment variable. Running, for example,
-
-
```
java -version
```
must show the right version number.
-
-
### Maven Unpacked
-
You need to unpack the Maven distribution. Don't unpack it in the middle of your source code; pick some location and unpack it there. Let's assume that the path is `${maven.home}`.
-
-
### Maven in PATH
-
You run Maven by invoking a command-line tool: `mvn.cmd` from the `bin` directory of the Maven. To do this conveniently, `${maven.home}/bin` must be in your PATH, just like the Java SDK commands. You can add directories to your `PATH` in the control panel; the details vary by Windows version.
-
-
### Firewalls and Anti-virus
-
Firewall and Anti-virus sometimes prevent Java from running properly, or Windows Firewall (and various other Firewalls) actively prevent Java.exe from reaching out to the Internet to "download stuff" which is a key part of Maven. You may need to configure the Firewall or Anti-virus to add exceptions to allow such actions.
-
-
-
diff --git a/content/markdown/guides/introduction/introduction-to-archetypes.md b/content/markdown/guides/introduction/introduction-to-archetypes.md
index 876c9db5..b048e671 100644
--- a/content/markdown/guides/introduction/introduction-to-archetypes.md
+++ b/content/markdown/guides/introduction/introduction-to-archetypes.md
@@ -22,41 +22,28 @@ under the License.
-->
## Introduction to Archetypes
-
-
## What is Archetype?
-
In short, Archetype is a Maven project templating toolkit. An archetype is defined as _an original pattern or model from which all other things of the same kind are made_. The name fits as we are trying to provide a system that provides a consistent means of generating Maven projects. Archetype will help authors create Maven project templates for users, and provides users with the means to generate parameterized versions of those project templates.
-
Using archetypes provides a great way to enable developers quickly in a way consistent with best practices employed by your project or organization. Within the Maven project, we use archetypes to try and get our users up and running as quickly as possible by providing a sample project that demonstrates many of the features of Maven, while introducing new users to the best practices employed by Maven. In a matter of seconds, a new user can have a working Maven project to use as a jumping [...]
-
You may want to standardize J2EE development within your organization, so you may want to provide archetypes for EJBs, or WARs, or for your web services. Once these archetypes are created and deployed in your organization's repository, they are available for use by all developers within your organization.
-
### Using an Archetype
-
To create a new project based on an Archetype, you need to call `mvn archetype:generate` goal, like the following:
-
-
```
mvn archetype:generate
```
Please refer to [Archetype Plugin page](/archetype/maven-archetype-plugin/usage.html).
-
-
### Provided Archetypes
-
Maven provides several Archetype artifacts:
-
|Archetype ArtifactIds|Description|
|---|---|
|maven-archetype-archetype|An archetype to generate a sample archetype project.|
@@ -73,12 +60,6 @@ mvn archetype:generate
For more information on these archetypes, please refer to the [Maven Archetype Bundles page](/archetypes/index.html).
-
-
### What makes up an Archetype?
-
Archetypes are packaged up in a JAR and they consist of the archetype metadata which describes the contents of archetype, and a set of [Velocity](http://velocity.apache.org/) templates which make up the prototype project. If you would like to know how to make your own archetypes, please refer to our [Guide to creating archetypes](../mini/guide-creating-archetypes.html).
-
-
-
diff --git a/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md b/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
index ff43f3ab..8d79efe5 100644
--- a/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
+++ b/content/markdown/guides/introduction/introduction-to-dependency-mechanism.md
@@ -22,52 +22,37 @@ under the License.
-->
## Introduction to the Dependency Mechanism
-
Dependency management is a core feature of Maven. Managing dependencies for a single project is easy. Managing dependencies for multi-module projects and applications that consist of hundreds of modules is possible. Maven helps a great deal in defining, creating, and maintaining reproducible builds with well-defined classpaths and library versions.
-
Learn more about:
+- [Transitive Dependencies](#transitive-dependencies)
+- Excluded/Optional Dependencies
- - [Transitive Dependencies](#transitive-dependencies)
-
- - Excluded/Optional Dependencies
-
-
-
- - [Dependency Scope](#dependency-scope)
+- [Dependency Scope](#dependency-scope)
- - [Dependency Management](#dependency-management)
+- [Dependency Management](#dependency-management)
- - [Importing Dependencies](#importing-dependencies)
+- [Importing Dependencies](#importing-dependencies)
- - [Bill of Materials (BOM) POMs](#bill-of-materials-bom-poms)
-
-
-
- - [System Dependencies](#system-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.
-
- - _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:
+- "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
@@ -78,11 +63,8 @@ under the License.
└── D 1.0
```
-
In text, dependencies for A, B, and C are defined as A -\> B -\> C -\> D 2.0 and A -\> E -\> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0, as shown here:
-
-
```
A
├── B
@@ -94,63 +76,48 @@ under the License.
└── D 2.0
```
+- _Dependency management_ - this allows project authors to directly specify the versions of artifacts to be used when they are encountered in transitive dependencies or in dependencies where no version has been specified. In the example in the preceding section a dependency was directly added to A even though it is not directly used by A. Instead, A can include D as a dependency in its dependencyManagement section and directly control which version of D is used when, or if, it is ever re [...]
+- _Dependency scope_ - this allows you to only include dependencies appropriate for the current stage of the build. This is described in more detail below.
+- _Excluded dependencies_ - If project X depends on project Y, and project Y depends on project Z, the owner of project X can explicitly exclude project Z as a dependency, using the "exclusion" element.
- - _Dependency management_ - this allows project authors to directly specify the versions of artifacts to be used when they are encountered in transitive dependencies or in dependencies where no version has been specified. In the example in the preceding section a dependency was directly added to A even though it is not directly used by A. Instead, A can include D as a dependency in its dependencyManagement section and directly control which version of D is used when, or if, it is ever r [...]
-
- - _Dependency scope_ - this allows you to only include dependencies appropriate for the current stage of the build. This is described in more detail below.
-
- - _Excluded dependencies_ - If project X depends on project Y, and project Y depends on project Z, the owner of project X can explicitly exclude project Z as a dependency, using the "exclusion" element.
-
- - _Optional dependencies_ - If project Y depends on project Z, the owner of project Y can mark project Z as an optional dependency, using the "optional" element. When project X depends on project Y, X will depend only on Y and not on Y's optional dependency Z. The owner of project X may then explicitly add a dependency on Z, at her option. (It may be helpful to think of optional dependencies as "excluded by default.")
-
+- _Optional dependencies_ - If project Y depends on project Z, the owner of project Y can mark project Z as an optional dependency, using the "optional" element. When project X depends on project Y, X will depend only on Y and not on Y's optional dependency Z. The owner of project X may then explicitly add a dependency on Z, at her option. (It may be helpful to think of optional dependencies as "excluded by default.")
Although transitive dependencies can implicitly include desired dependencies, it is a good practice to explicitly specify the dependencies your source code uses directly. This best practice proves its value especially when the dependencies of your project change their dependencies.
-
For example, assume that your project A specifies a dependency on another project B, and project B specifies a dependency on project C. If you are directly using components in project C, and you don't specify project C in your project A, it may cause build failure when project B suddenly updates/removes its dependency on project C.
-
Another reason to directly specify dependencies is that it provides better documentation for your project: one can learn more information by just reading the POM file in your project, or by executing **mvn dependency:tree**.
-
Maven also provides [dependency:analyze](/plugins/maven-dependency-plugin/analyze-mojo.html) plugin goal for analyzing the dependencies: it helps making this best practice more achievable.
-
-
### Dependency Scope
-
Dependency scope is used to limit the transitivity of a dependency and to determine when a dependency is included in a classpath.
-
There are 6 scopes:
-
-
- - **compile**\
+- **compile**\
This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
- - **provided**\
+- **provided**\
This is much like `compile`, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope `provided` because the web container provides those classes. A dependency with this scope is added to the classpath used for compilation and test, but not the runtime classpath. It is not transitive.
- - **runtime**\
+- **runtime**\
This scope indicates that the dependency is not required for compilation, but is for execution. Maven includes a dependency with this scope in the runtime and test classpaths, but not the compile classpath.
- - **test**\
+- **test**\
This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases. This scope is not transitive. Typically this scope is used for test libraries such as JUnit and Mockito. It is also used for non-test libraries such as Apache Commons IO if those libraries are used in unit tests (src/test/java) but not in the model code (src/main/java).
- - **system**\
+- **system**\
This scope is similar to `provided` except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
- - **import**\
+- **import**\
This scope is only supported on a dependency of type `pom` in the `<dependencyManagement>` section. It indicates the dependency is to be replaced with the effective list of dependencies in the specified POM's `<dependencyManagement>` section. Since they are replaced, dependencies with a scope of `import` do not actually participate in limiting the transitivity of a dependency.
-
Each of the scopes (except for `import`) affects transitive dependencies in different ways, as is demonstrated in the table below. If a dependency is set to the scope in the left column, a transitive dependency of that dependency with the scope across the top row results in a dependency in the main project with the scope listed at the intersection. If no scope is listed, it means the dependency is omitted.
-
||compile|provided|runtime|test|
|---|---|---|---|---|
|compile|compile(*)|-|runtime|-|
@@ -160,18 +127,12 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
**(\*) Note:** it is intended that this should be runtime scope instead, so that all compile dependencies must be explicitly listed. However, if a library you depend on extends a class from another library, both must be available at compile time. For this reason, compile time dependencies remain as compile scope even when they are transitive.
-
-
### Dependency Management
-
The dependency management section is a mechanism for centralizing dependency information. When you have a set of projects that inherit from a common parent, it's possible to put all information about the dependency in the common POM and have simpler references to the artifacts in the child POMs. The mechanism is best illustrated through some examples. Given these two POMs which extend the same parent:
-
Project A:
-
-
```
<project>
@@ -202,8 +163,6 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project B:
-
-
```
<project>
@@ -230,8 +189,6 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
These two example POMs share a common dependency and each has one non-trivial dependency. This information can be put in the parent POM like this:
-
-
```
<project>
@@ -275,8 +232,6 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Then the two child POMs become much simpler:
-
-
```
<project>
@@ -298,7 +253,6 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
```
-
```
<project>
@@ -324,14 +278,10 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
**NOTE:** In two of these dependency references, we had to specify the `<type>` element. This is because the minimal set of information for matching a dependency reference against a dependencyManagement section is actually **{groupId, artifactId, type, classifier}**. In many cases, these dependencies will refer to jar artifacts with no classifier. This allows us to shorthand the identity set to **{groupId, artifactId}**, since the default for the type field is `jar`, and the default cla [...]
-
A second, and very important use of the dependency management section is to control the versions of artifacts used in transitive dependencies. As an example consider these projects:
-
Project A:
-
-
```
<project>
@@ -373,8 +323,6 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project B:
-
-
```
<project>
@@ -419,28 +367,20 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
When maven is run on project B, version 1.0 of artifacts a, b, c, and d will be used regardless of the version specified in their POM.
+- a and c both are declared as dependencies of the project so version 1.0 is used due to dependency mediation. Both also have runtime scope since it is directly specified.
+- b is defined in B's parent's dependency management section and since dependency management takes precedence over dependency mediation for transitive dependencies, version 1.0 will be selected should it be referenced in a or c's POM. b will also have compile scope.
- - 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.
-
+- Finally, since d is specified in B's dependency management section, should d be a dependency (or transitive dependency) of a or c, version 1.0 will be chosen - again because dependency management takes precedence over dependency mediation and also because the current POM's declaration takes precedence over its parent's declaration.
The reference information about the dependency management tags is available from the [project descriptor reference](../../ref/current/maven-model/maven.html#class_DependencyManagement).
-
#### Importing Dependencies
-
The examples in the previous section describe how to specify managed dependencies through inheritance. However, in larger projects it may be impossible to accomplish this since a project can only inherit from a single parent. To accommodate this, projects can import managed dependencies from other projects. This is accomplished by declaring a POM artifact as a dependency with a scope of "import".
-
Project B:
-
-
```
<project>
@@ -487,11 +427,8 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Assuming A is the POM defined in the preceding example, the end result would be the same. All of A's managed dependencies would be incorporated into B except for d since it is defined in this POM.
-
Project X:
-
-
```
<project>
@@ -523,8 +460,6 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project Y:
-
-
```
<project>
@@ -556,8 +491,6 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Project Z:
-
-
```
<project>
@@ -592,21 +525,14 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
In the example above Z imports the managed dependencies from both X and Y. However, both X and Y contain dependency a. Here, version 1.1 of a would be used since X is declared first and a is not declared in Z's dependencyManagement.
-
This process is recursive. For example, if X imports another POM, Q, when Z is processed it will simply appear that all of Q's managed dependencies are defined in X.
-
-
#### Bill of Materials (BOM) POMs
-
Imports are most effective when used for defining a "library" of related artifacts that are generally part of a multiproject build. It is fairly common for one project to use one or more artifacts from these libraries. However, it has sometimes been difficult to keep the versions in the project using the artifacts in synch with the versions distributed in the library. The pattern below illustrates how a "bill of materials" (BOM) can be created for use by other projects.
-
The root of the project is the BOM POM. It defines the versions of all the artifacts that will be created in the library. Other projects that wish to use the library should import this POM into the dependencyManagement section of their POM.
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -645,8 +571,6 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
The parent subproject has the BOM POM as its parent. It is a normal multiproject pom.
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -687,8 +611,6 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Next are the actual project POMs.
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -737,8 +659,6 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
The project that follows shows how the library can now be used in another project without having to specify the dependent project's versions.
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
@@ -775,30 +695,20 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
Finally, when creating projects that import dependencies, beware of the following:
+- Do not attempt to import a POM that is defined in a submodule of the current POM. Attempting to do that will result in the build failing since it won't be able to locate the POM.
+- Never declare the POM importing a POM as the parent (or grandparent, etc) of the target POM. There is no way to resolve the circularity and an exception will be thrown.
- - 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).
-
-
-
+- 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>
@@ -819,8 +729,6 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
If your artifact is provided by the JDK's `tools.jar`, the system path would be defined as follows:
-
-
```
<project>
...
@@ -836,5 +744,3 @@ This scope is only supported on a dependency of type `pom` in the `<dependencyMa
...
</project>
```
-
-
diff --git a/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md b/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md
index 88e29c2f..862c6aac 100644
--- a/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md
+++ b/content/markdown/guides/introduction/introduction-to-optional-and-excludes-dependencies.md
@@ -22,33 +22,22 @@ under the License.
-->
## Introduction
-
This section discusses optional dependencies and dependency exclusions. This will help users to understand what they are and when and how to use them. It also explains why exclusions are made on a per dependency basis instead of at the POM level.
-
### Optional Dependencies
-
- Optional dependencies are used when it's not possible (for whatever reason) to split a project into sub-modules. The idea is that some of the dependencies are only used for certain features in the project and will not be needed if that feature isn't used. Ideally, such a feature would be split into a sub-module that depends on the core functionality project. This new subproject would have only non-optional dependencies, since you'd need them all if you decided to use the subproject's fu [...]
-
+ Optional dependencies are used when it's not possible (for whatever reason) to split a project into sub-modules. The idea is that some of the dependencies are only used for certain features in the project and will not be needed if that feature isn't used. Ideally, such a feature would be split into a sub-module that depends on the core functionality project. This new subproject would have only non-optional dependencies, since you'd need them all if you decided to use the subproject's fu [...]
However, since the project cannot be split up (again, for whatever reason), these dependencies are declared optional. If a user wants to use functionality related to an optional dependency, they have to redeclare that optional dependency in their own project. This is not the clearest way to handle this situation, but both optional dependencies and dependency exclusions are stop-gap solutions.
-
#### Why use optional dependencies?
-
- Optional dependencies save space and memory. They prevent problematic jars that violate a license agreement or cause classpath issues from being bundled into a WAR, EAR, fat jar, or the like.
-
-
+ Optional dependencies save space and memory. They prevent problematic jars that violate a license agreement or cause classpath issues from being bundled into a WAR, EAR, fat jar, or the like.
#### How do I use the optional tag?
-
A dependency is declared optional by setting the `<optional>` element to true in its dependency declaration:
-
-
```
<project>
@@ -67,11 +56,8 @@ under the License.
```
-
#### How do optional dependencies work?
-
-
```
Project-A -> Project-B
@@ -80,8 +66,6 @@ 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
@@ -90,29 +74,18 @@ Project-X -> Project-A
When another project (Project-X) declares Project-A as a dependency in its POM, the optional nature of the dependency takes effect. Project-B is not included in the classpath of Project-X. You need to declare it directly in the POM of Project X for B to be included in X's classpath.
-
-
#### Example
-
Suppose there is a project named _X2_ that has similar functionality to _Hibernate_. It supports many databases such as MySQL, PostgreSQL, and several versions of Oracle. Each supported database requires an additional dependency on a driver jar. All of these dependencies are needed at compile time to build X2. However your project only uses one specific database and doesn't need drivers for the others. X2 can declare these dependencies as optional, so that when your project declares X2 [...]
-
-
-
### Dependency Exclusions
-
Since Maven resolves dependencies transitively, it is possible for unwanted dependencies to be included in your project's classpath. For example, a certain older jar may have security issues or be incompatible with the Java version you're using. To address this, Maven allows you to exclude specific dependencies. Exclusions are set on a specific dependency in your POM, and are targeted at a specific groupId and artifactId. When you build your project, that artifact will not be added to y [...]
-
#### How to use dependency exclusions
-
Add an `<exclusions>` element in the `<dependency>` element by which the problematic jar is included.
-
-
```
<project>
@@ -135,11 +108,8 @@ Project-X -> Project-A
```
-
#### How dependency exclusion works and when to use it **( as a last resort! )**
-
-
```
Project-A
@@ -153,16 +123,12 @@ Project-A
The diagram shows that Project-A depends on both Project-B and C. Project-B depends on Project-D. Project-D depends on both Project-E and F. By default, Project A's classpath will include:
-
-
```
B, C, D, E, F
```
Suppose you don't want project D and its dependencies to be added to Project A's classpath because some of Project-D's dependencies are missing from the repository, and you don't need the functionality in Project-B that depends on Project-D anyway. Project-B's developers could have marked the dependency on Project-D `<optional>true</optional>`:
-
-
```
<dependency>
<groupId>sample.ProjectD</groupId>
@@ -174,8 +140,6 @@ B, C, D, E, F
Unfortunately, they didn't. As a last resort, you can exclude it on your own POM for Project-A like this:
-
-
```
<project>
@@ -204,21 +168,16 @@ B, C, D, E, F
If you deploy Project-A to a repository, and Project-X declares a normal dependency on Project-A, will Project-D still be excluded from the classpath?
-
-
```
Project-X -> Project-A
```
- The answer is **Yes**. Project-A has declared that it doesn't need Project-D to run, so it won't be brought in as a transitive dependency of Project-A.
-
+ The answer is **Yes**. Project-A has declared that it doesn't need Project-D to run, so it won't be brought in as a transitive dependency of Project-A.
Now, consider that Project-X depends on Project-Y, as in the diagram below:
-
-
```
Project-X -> Project-Y
@@ -228,13 +187,10 @@ Project-X -> Project-Y
```
- Project-Y also has a dependency on Project-B, and it does need the features supported by Project-D. Therefore, it will NOT place an exclusion on Project-D in its dependency list. It may also supply an additional repository, from which it can resolve Project-E. In this case, it's important that Project-D **is not** excluded globally, since it is a legitimate dependency of Project-Y.
-
+ Project-Y also has a dependency on Project-B, and it does need the features supported by Project-D. Therefore, it will NOT place an exclusion on Project-D in its dependency list. It may also supply an additional repository, from which it can resolve Project-E. In this case, it's important that Project-D **is not** excluded globally, since it is a legitimate dependency of Project-Y.
As another scenario, suppose the dependency you don't want is Project-E instead of Project-D. How do you exclude it? See the diagram below:
-
-
```
Project-A
@@ -246,9 +202,7 @@ Project-A
```
- Exclusions work on the entire dependency graph below the point where they are declared. If you want to exclude Project-E instead of Project-D, simply change the exclusion to point at Project-E, but you don't move the exclusion down to Project-D. You cannot change Project-D's POM. If you could, you would use optional dependencies instead of exclusions, or split Project-D up into multiple subprojects, each with nothing but normal dependencies.
-
-
+ 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.
```
@@ -276,15 +230,8 @@ Project-A
```
-
#### Why exclusions are made on a per-dependency basis, rather than at the POM level
-
This is mainly to be sure the dependency graph is predictable, and to keep inheritance effects from excluding a dependency that should not be excluded. If you get to the method of last resort and have to put in an exclusion, you should be absolutely certain which of your dependencies is bringing in that unwanted transitive dependency.
-
- If you truly want to ensure that a particular dependency appears nowhere in your classpath, regardless of path, the [banned dependencies rule](/enforcer/enforcer-rules/bannedDependencies.html) can be configured to fail the build if a problematic dependency is found. When the build fails, you'll need to add specific exclusions on each path the enforcer finds.
-
-
-
-
+ If you truly want to ensure that a particular dependency appears nowhere in your classpath, regardless of path, the [banned dependencies rule](/enforcer/enforcer-rules/bannedDependencies.html) can be configured to fail the build if a problematic dependency is found. When the build fails, you'll need to add specific exclusions on each path the enforcer finds.
diff --git a/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md b/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
index 9f144e42..41e21074 100644
--- a/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
+++ b/content/markdown/guides/introduction/introduction-to-plugin-prefix-mapping.md
@@ -22,32 +22,22 @@ under the License.
-->
## Introduction to Plugin Prefix Resolution
-
When you execute Maven using a standard lifecycle phase, resolving the plugins that participate in that lifecycle is a relatively simple process. However, when you directly invoke a mojo from the command line, as in the case of **clean**, Maven must have some way of reliably resolving the **clean** plugin prefix to the **maven-clean-plugin**. This provides brevity for command-line invocations, while preserving the descriptiveness of the plugin's real artifactId.
-
To complicate matters even more, not all plugins should be forced to have the same groupId in the repository. Since groupIds are presumed to be controlled by one project, and multiple projects may release plugins for Maven, it follows that plugin-prefix mappings must also accommodate multiple plugin groupIds.
-
To address these concerns, Maven provides a new piece of repository-level metadata (not associated with any single artifact) for plugin groups, along with a plugin mapping manager to organize multiple plugin groups and provide search functionality.
-
### Specifying a Plugin's Prefix
-
In order to give users a convenient prefix with which to reference your plugin a prefix must be associated with your plugin when it is built. By default, Maven will make a guess at the plugin-prefix to be used, by removing any instances of "maven" or "plugin" surrounded by hyphens in the plugin's artifact ID. The conventional artifact ID formats to use are:
+- `maven-${prefix}-plugin` - for official plugins maintained by the Apache Maven team itself (you **must not** use this naming pattern for your plugin, see [this note for more informations](../plugin/guide-java-plugin-development.html#plugin-naming-convention-and-apache-maven-trademark))
-
- - `maven-${prefix}-plugin` - for official plugins maintained by the Apache Maven team itself (you **must not** use this naming pattern for your plugin, see [this note for more informations](../plugin/guide-java-plugin-development.html#plugin-naming-convention-and-apache-maven-trademark))
-
- - `${prefix}-maven-plugin` - for plugins from other sources
-
+- `${prefix}-maven-plugin` - for plugins from other sources
If your plugin's artifactId fits this pattern, Maven will automatically map your plugin to the correct prefix in the metadata stored within your plugin's groupId path on the repository. However, if you want to customize the prefix used to reference your plugin, you can specify the prefix directly through a configuration parameter on the `maven-plugin-plugin` in your plugin's POM:
-
-
```
<project>
...
@@ -70,41 +60,28 @@ under the License.
The above configuration will allow users to refer to your plugin by the prefix **somePrefix**, as in the following example:
-
-
```
mvn somePrefix:goal
```
-
### Mapping Prefixes to Plugins
-
For each groupId configured for searching, Maven will:
-
-
1 Download `maven-metadata.xml` from each remote repository into the local repository, and name it `maven-metadata-${repoId}.xml` within the path of `${groupId}`.
1 Load these metadata files, along with `maven-metadata-local.xml` (if it exists), within the path of `${groupId}`. Merge them.
1 Lookup the plugin prefix in the merged metadata. If it's mapped, it should refer to a concrete groupId-artifactId pair. Otherwise, go on to #1 for the next groupId in the user's plugin-groups.
-
These metadata files consist of the **groupId** it represents (for clarity when the file is opened outside the context of the directory), and a group of **plugin** elements. Each **plugin** in this list contains a **prefix** element denoting the plugin's command-line prefix, and an **artifactId** element, which provides the other side of the prefix mapping and provides enough information to lookup and use the plugin. When a plugin is installed or deployed, the appropriate metadata file [...]
-
-
### Configuring Maven to Search for Plugins
-
By default, Maven will search the groupId **org.apache.maven.plugins** for prefix-to-artifactId mappings for the plugins it needs to perform a given build. However, as previously mentioned, the user may have a need for third-party plugins. Since the Maven project is assumed to have control over the default plugin groupId, this means configuring Maven to search other groupId locations for plugin-prefix mappings.
-
As it turns out, this is simple. In the Maven settings file (per-user: `${user.home}/.m2/settings.xml`; global: `${maven.home}/conf/settings.xml`), you can provide a custom **pluginGroups** section, listing the plugin groupIds you want to search (each groupId goes in its own **pluginGroup** sub-element). For example, if my project uses a Modello model file, I might have the following in my settings:
-
-
```
<pluginGroups>
<pluginGroup>org.codehaus.modello</pluginGroup>
@@ -113,32 +90,20 @@ mvn somePrefix:goal
This allows me to execute the following, which will generate Java classes from the model:
-
-
```
mvn -Dversion=4.0.0 -Dmodel=maven.mdo modello:java
```
Maven will always search the following groupId's **after** searching any plugin groups specified in the user's settings:
+- org.apache.maven.plugins
-
- - org.apache.maven.plugins
-
- - org.codehaus.mojo
-
+- org.codehaus.mojo
**NOTE:** When specifying plugin groups to be used in searching for a prefix mapping, order is critical! By specifying a pluginGroup of `com.myco.plugins` with a prefix of `clean`, I can override the usage of the `maven-clean-plugin` when `clean:clean` is invoked.
-
**NOTE2:** For more information on `settings.xml`, see \[[1](a1)\].
-
-
### Resources
-
1 [Guide to Configuring Maven](../mini/guide-configuring-maven.html)
-
-
-
diff --git a/content/markdown/guides/introduction/introduction-to-plugins.md b/content/markdown/guides/introduction/introduction-to-plugins.md
index 2b3ef553..29c1e5f8 100644
--- a/content/markdown/guides/introduction/introduction-to-plugins.md
+++ b/content/markdown/guides/introduction/introduction-to-plugins.md
@@ -23,47 +23,28 @@ under the License.
## Introduction to Maven Plugin Development
-
Maven consists of a core engine which provides basic project-processing capabilities and build-process management, and a host of plugins which are used to execute the actual build tasks.
-
### What is a Plugin?
-
"Maven" is really just a core framework for a collection of Maven Plugins. In other words, plugins are where much of the real action is performed, plugins are used to: create jar files, create war files, compile code, unit test code, create project documentation, and on and on. Almost any action that you can think of performing on a project is implemented as a Maven plugin.
-
Plugins are the central feature of Maven that allow for the reuse of common build logic across multiple projects. They do this by executing an "action" (i.e. creating a WAR file or compiling unit tests) in the context of a project's description - the Project Object Model (POM). Plugin behavior can be customized through a set of unique parameters which are exposed by a description of each plugin goal (or Mojo).
-
One of the simplest plugins in Maven is the Clean Plugin. The [Maven Clean plugin](../../plugins/maven-clean-plugin/) (maven-clean-plugin) is responsible for removing the target directory of a Maven project. When you run "mvn clean", Maven executes the "clean" goal as defined in the Clean plug-in, and the target directory is removed. The Clean plugin [defines a parameter](../../plugins/maven-clean-plugin/clean-mojo.html) which can be used to customize plugin behavior, this parameter is [...]
-
-
### What is a Mojo (_And Why the H--- is it Named 'Mojo'_)?
-
A Mojo is really just a **goal** in Maven, and plug-ins consist of any number of goals (Mojos). Mojos can be defined as annotated Java classes or Beanshell script. A Mojo specifies metadata about a goal: a goal name, which phase of the lifecycle it fits into, and the parameters it is expecting.
-
MOJO is a play on POJO (Plain-old-Java-object), substituting "Maven" for "Plain". Mojo is also an interesting word (see [definition](http://www.answers.com/mojo&r=67)). From [Wikipedia](http://www.wikipedia.org), a "mojo" is defined as: "...a small bag worn by a person under the clothes (also known as a mojo hand). Such bags were thought to have supernatural powers, such as protecting from evil, bringing good luck, etc."
-
-
### What is the Build Lifecycle? (Overview)
-
The build lifecycle is a series of common **stage**s through which all project builds naturally progress. Plugin goals are bound to specific stages in the lifecycle.
-
-
-
## Resources
-
-
1 [Plugin Development Center](/plugin-developers/index.html)
1 [Configuring plugins](../mini/guide-configuring-plugins.html)
-
-
diff --git a/content/markdown/guides/introduction/introduction-to-profiles.md b/content/markdown/guides/introduction/introduction-to-profiles.md
index 9b7caf2d..7b0e9d94 100644
--- a/content/markdown/guides/introduction/introduction-to-profiles.md
+++ b/content/markdown/guides/introduction/introduction-to-profiles.md
@@ -23,17 +23,15 @@ under the License.
## Introduction to Build Profiles
+- [What are the different types of profile? Where is each defined?](#what-are-the-different-types-of-profile-where-is-each-defined)
+- [How can a profile be triggered? How does this vary according to the type of profile being used?](#how-can-a-profile-be-triggered-how-does-this-vary-according-to-the-type-of-profile-being-used)
- - [What are the different types of profile? Where is each defined?](#what-are-the-different-types-of-profile-where-is-each-defined)
+- [Details on profile activation](#details-on-profile-activation)
- - [How can a profile be triggered? How does this vary according to the type of profile being used?](#how-can-a-profile-be-triggered-how-does-this-vary-according-to-the-type-of-profile-being-used)
+- [Explicit profile activation](#explicit-profile-activation)
- - [Details on profile activation](#details-on-profile-activation)
-
- - [Explicit profile activation](#explicit-profile-activation)
-
- - [Implicit profile activation](#implici-profile-activation)
+- [Implicit profile activation](#implici-profile-activation)
- [JDK](#jdk)
@@ -43,120 +41,82 @@ under the License.
- [Files](#files)
+- [Deactivating a profile](#deactivating-a-profile)
+- [Which areas of a POM can be customized by each type of profile? Why?](#which-areas-of-a-pom-can-be-customized-by-each-type-of-profile-why)
+- [Profiles in external files](#profiles-in-external-files)
+- [Profiles in POMs](#profiles-in-poms)
- - [Deactivating a profile](#deactivating-a-profile)
-
-
-
- - [Which areas of a POM can be customized by each type of profile? Why?](#which-areas-of-a-pom-can-be-customized-by-each-type-of-profile-why)
-
- - [Profiles in external files](#profiles-in-external-files)
-
- - [Profiles in POMs](#profiles-in-poms)
-
- - [POM elements outside `<profiles>`](#pom-elements-outside-profiles)
-
-
-
- - [Profile Order](#profile-order)
+- [POM elements outside `<profiles>`](#pom-elements-outside-profiles)
- - [Profile Pitfalls](#profile-pitfalls)
+- [Profile Order](#profile-order)
- - [External Properties](#external-properties)
+- [Profile Pitfalls](#profile-pitfalls)
- - [Incomplete Specification of a Natural Profile Set](#incomplete-specification-of-a-natural-profile-set)
+- [External Properties](#external-properties)
+- [Incomplete Specification of a Natural Profile Set](#incomplete-specification-of-a-natural-profile-set)
+- [How can I tell which profiles are in effect during a build?](#how-can-i-tell-which-profiles-are-in-effect-during-a-build)
- - [How can I tell which profiles are in effect during a build?](#how-can-i-tell-which-profiles-are-in-effect-during-a-build)
-
- - [Naming Conventions](#naming-conventions)
-
+- [Naming Conventions](#naming-conventions)
Apache Maven goes to great lengths to ensure that builds are portable. Among other things, this means allowing build configuration inside the POM, avoiding **all** filesystem references (in inheritance, dependencies, and other places), and leaning much more heavily on the local repository to store the metadata needed to make this possible.
-
However, sometimes portability is not entirely possible. Under certain conditions, plugins may need to be configured with local filesystem paths. Under other circumstances, a slightly different dependency set will be required, and the project's artifact name may need to be adjusted slightly. And at still other times, you may even need to include a whole plugin in the build lifecycle depending on the detected build environment.
-
To address these circumstances, Maven supports build profiles. Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing, and production environments). [...]
-
### What are the different types of profile? Where is each defined?
+- Per Project
+ - Defined in the POM itself `(pom.xml)`.
- - Per Project
-
- - Defined in the POM itself `(pom.xml)`.
-
-
-
- - Per User
-
- - Defined in the [ Maven-settings](/ref/current/maven-settings/settings.html) `(%USER_HOME%/.m2/settings.xml)`.
-
+- Per User
+ - Defined in the [Maven-settings](/ref/current/maven-settings/settings.html) `(%USER_HOME%/.m2/settings.xml)`.
- - Global
-
- - Defined in the [ global Maven-settings](/ref/current/maven-settings/settings.html) `(${maven.home}/conf/settings.xml)`.
-
-
-
- - Profile descriptor
-
- - a descriptor located in [project basedir `(profiles.xml)`](/ref/2.2.1/maven-profile/profiles.html) (no longer supported in Maven 3.0 and above; see [ Maven 3 compatibility notes](https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-profiles.xml))
-
+- Global
+ - Defined in the [global Maven-settings](/ref/current/maven-settings/settings.html) `(${maven.home}/conf/settings.xml)`.
+- Profile descriptor
+ - a descriptor located in [project basedir `(profiles.xml)`](/ref/2.2.1/maven-profile/profiles.html) (no longer supported in Maven 3.0 and above; see [Maven 3 compatibility notes](https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-profiles.xml))
### 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
- - Explicitly
-
- - Implicitly
-
- - Based on OS
+- Based on OS
- - Based on system properties
-
- - Based on presence of files
+- 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>
...
@@ -169,21 +129,14 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
Profiles listed in the `<activeProfiles>` tag would be activated by default every time a project use it.
-
-
##### Implicit profile activation
-
Profiles can be automatically triggered based on the detected state of the build environment. These triggers are specified via an `<activation>` section in the profile itself. Currently, this detection is limited to JDK version matching, operating system matching or the presence/the value of a system property. Here are some examples.
-
###### JDK
-
The following configuration will trigger the profile when the JDK's version _starts with_ "1.4" (eg. "1.4.0_08", "1.4.2_07", "1.4"), in particular it _won't be active_ for **newer** versions like "1.8" or "11":
-
-
```
<profiles>
<profile>
@@ -195,9 +148,7 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
</profiles>
```
- Ranges can also be used as of Maven 2.1 (refer to the [ Enforcer Version Range Syntax](/enforcer/enforcer-rules/versionRanges.html) for more information). Range values must start with either `\[` or `(` otherwise the value is interpreted as prefix. The following honours versions 1.3, 1.4 and 1.5.
-
-
+ Ranges can also be used as of Maven 2.1 (refer to the [Enforcer Version Range Syntax](/enforcer/enforcer-rules/versionRanges.html) for more information). Range values must start with either `\[` or `(` otherwise the value is interpreted as prefix. The following honours versions 1.3, 1.4 and 1.5.
```
<profiles>
@@ -212,15 +163,10 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
_Note:_ an upper bound such as `,1.5\]` is likely not to include most releases of 1.5, since they will have an additional "patch" release such as `_05` that is not taken into consideration in the above range.
-
-
###### OS
-
This next one will activate based on the detected operating system. See the [Maven Enforcer Plugin](/enforcer/enforcer-rules/requireOS.html) for more details about OS values.
-
-
```
<profiles>
<profile>
@@ -237,14 +183,10 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
</profiles>
```
-
###### Property
-
The profile below will be activated when the system property "debug" is specified with any value:
-
-
```
<profiles>
<profile>
@@ -260,8 +202,6 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
The following profile will be activated when the system property "debug" is not defined at all:
-
-
```
<profiles>
<profile>
@@ -277,8 +217,6 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
The following profile will be activated when the system property "debug" is not defined, or is defined with a value which is not "true".
-
-
```
<profiles>
<profile>
@@ -295,8 +233,6 @@ mvn groupId:artifactId:goal -P profile-1,profile-2,?profile-3
To activate this you would type one of those on the command line:
-
-
```
mvn groupId:artifactId:goal
mvn groupId:artifactId:goal -Ddebug=false
@@ -304,8 +240,6 @@ 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>
@@ -322,22 +256,16 @@ mvn groupId:artifactId:goal -Ddebug=false
To activate this you would type this on the command line:
-
-
```
mvn groupId:artifactId:goal -Denvironment=test
```
As of Maven 3.0, profiles in the POM can also be activated based on properties from active profiles from the `settings.xml`.
-
**Note**: Environment variables like `FOO` are available as properties of the form `env.FOO`. Further note that environment variable names are normalized to all upper-case on Windows.
-
Since Maven 3.9.0 one can also evaluate the POM's packaging value by referencing property `packaging`. This is only useful where the profile activation is defined in a common parent POM which is reused among multiple Maven projects. The next example will trigger the profile when a project with packaging `war` is built:
-
-
```
<profiles>
<profile>
@@ -352,14 +280,10 @@ mvn groupId:artifactId:goal -Denvironment=test
</profiles>
```
-
###### Files
-
This example will trigger the profile when the generated file `target/generated-sources/axistools/wsdl2java/org/apache/maven` is missing.
-
-
```
<profiles>
<profile>
@@ -375,11 +299,8 @@ mvn groupId:artifactId:goal -Denvironment=test
As of Maven 2.0.9, the tags `<exists>` and `<missing>` could be interpolated. Supported variables are system properties like `${user.home}` and environment variables like `${env.HOME}`. Please note that properties and values defined in the POM itself are not available for interpolation here, e.g. the above example activator cannot use `${project.build.directory}` but needs to hard-code the path `target`.
-
Profiles can also be active by default using a configuration like the following:
-
-
```
<profiles>
<profile>
@@ -394,126 +315,90 @@ mvn groupId:artifactId:goal -Denvironment=test
This profile will automatically be active for all builds unless another profile in the same POM is activated using one of the previously described methods. All profiles that are active by default are automatically deactivated when a profile in the POM is activated on the command line or through its activation config.
-
-
-
-
#### Deactivating a profile
-
Starting with Maven 2.0.10, one or more profiles can be deactivated using the command line by prefixing their identifier with either the character '!' or '-' as shown below:
-
-
```
mvn groupId:artifactId:goal -P !profile-1,!profile-2,!?profile-3
```
or
-
-
```
mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
```
This can be used to deactivate profiles marked as activeByDefault or profiles that would otherwise be activated through their activation config.
-
-
-
### Which areas of a POM can be customized by each type of profile? Why?
-
Now that we've talked about where to specify profiles, and how to activate them, it will be useful to talk about _what_ you can specify in a profile. As with the other aspects of profile configuration, this answer is not straightforward.
-
Depending on where you choose to configure your profile, you will have access to varying POM configuration options.
-
#### Profiles in external files
-
Profiles specified in external files (i.e in `settings.xml` or `profiles.xml`) are not portable in the strictest sense. Anything that seems to stand a high chance of changing the result of the build is restricted to the inline profiles in the POM. Things like repository lists could simply be a proprietary repository of approved artifacts, and won't change the outcome of the build. Therefore, you will only be able to modify the `<repositories>` and `<pluginRepositories>` sections, plus a [...]
-
The `<properties>` section allows you to specify free-form key-value pairs which will be included in the interpolation process for the POM. This allows you to specify a plugin configuration in the form of `${profile.provided.path}`.
-
-
#### Profiles in POMs
-
On the other hand, if your profiles can be reasonably specified _inside_ the POM, you have many more options. The trade-off, of course, is that you can only modify _that_ project and its sub-modules. Since these profiles are specified inline, and therefore have a better chance of preserving portability, it's reasonable to say you can add more information to them without the risk of that information being unavailable to other users.
-
Profiles specified in the POM can modify [the following POM elements](/ref/current/maven-model/maven.html):
+- `<repositories>`
+- `<pluginRepositories>`
- - `<repositories>`
-
- - `<pluginRepositories>`
-
- - `<dependencies>`
-
- - `<plugins>`
-
- - `<properties>` (not actually available in the main POM, but used behind the scenes)
+- `<dependencies>`
- - `<modules>`
+- `<plugins>`
- - `<reports>`
+- `<properties>` (not actually available in the main POM, but used behind the scenes)
- - `<reporting>`
+- `<modules>`
- - `<dependencyManagement>`
+- `<reports>`
- - `<distributionManagement>`
+- `<reporting>`
- - a subset of the `<build>` element, which consists of:
+- `<dependencyManagement>`
- - `<defaultGoal>`
+- `<distributionManagement>`
- - `<resources>`
+- a subset of the `<build>` element, which consists of:
- - `<testResources>`
+- `<defaultGoal>`
- - `<directory>`
+- `<resources>`
- - `<finalName>`
+- `<testResources>`
- - `<filters>`
-
- - `<pluginManagement>`
-
- - `<plugins>`
+- `<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 probabl [...]
-
-
-
### Profile Order
-
All profile elements in a POM from active profiles overwrite the global elements with the same name of the POM or extend those in case of collections. In case multiple profiles are active in the same POM or external file, the ones which are defined **later** take precedence over the ones defined **earlier** (independent of their profile id and activation order).
-
Example:
-
-
```
<project>
...
@@ -557,24 +442,16 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
This leads to the repository list: `profile-2-repo, profile-1-repo, global-repo`.
-
-
### Profile Pitfalls
-
We've already mentioned the fact that adding profiles to your build has the potential to break portability for your project. We've even gone so far as to highlight circumstances where profiles are likely to break project portability. However, it's worth reiterating those points as part of a more coherent discussion about some pitfalls to avoid when using profiles.
-
There are two main problem areas to keep in mind when using profiles. First are external properties, usually used in plugin configurations. These pose the risk of breaking portability in your project. The other, more subtle area is the incomplete specification of a natural set of profiles.
-
#### External Properties
-
External property definition concerns any property value defined outside the `pom.xml` but not defined in a corresponding profile inside it. The most obvious usage of properties in the POM is in plugin configuration. While it is certainly possible to break project portability without properties, these critters can have subtle effects that cause builds to fail. For example, specifying appserver paths in a profile that is specified in the `settings.xml` may cause your integration test plu [...]
-
-
```
<project>
...
@@ -597,8 +474,6 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
Now, in your local `${user.home}/.m2/settings.xml`, you have:
-
-
```
<settings>
...
@@ -620,24 +495,16 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
When you build the **integration-test** lifecycle phase, your integration tests pass, since the path you've provided allows the test plugin to install and test this web application.
-
_However_, when your colleague attempts to build to **integration-test**, his build fails spectacularly, complaining that it cannot resolve the plugin configuration parameter `<appserverHome>`, or worse, that the value of that parameter - literally `${appserver.home}` - is invalid (if it warns you at all).
-
Congratulations, your project is now non-portable. Inlining this profile in your `pom.xml` can help alleviate this, with the obvious drawback that each project hierarchy (allowing for the effects of inheritance) now have to specify this information. Since Maven provides good support for project inheritance, it's possible to stick this sort of configuration in the `<pluginManagement>` section of a team-level POM or similar, and simply inherit the paths.
-
Another, less attractive answer might be standardization of development environments. However, this will tend to compromise the productivity gain that Maven is capable of providing.
-
-
#### Incomplete Specification of a Natural Profile Set
-
In addition to the above portability-breaker, it's easy to fail to cover all cases with your profiles. When you do this, you're usually leaving one of your target environments high and dry. Let's take the example `pom.xml` snippet from above one more time:
-
-
```
<project>
...
@@ -660,8 +527,6 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
Now, consider the following profile, which would be specified inline in the `pom.xml`:
-
-
```
<project>
...
@@ -698,62 +563,44 @@ mvn groupId:artifactId:goal -P -profile-1,-profile-2,-?profile-3
This profile looks quite similar to the one from the last example, with a few important exceptions: it's plainly geared toward a development environment, a new profile named `appserverConfig-dev-2` is added and it has an activation section that will trigger its inclusion when the system properties contain "env=dev" for a profile named `appserverConfig-dev` and "env=dev-2" for a profile named `appserverConfig-dev-2`. So, executing:
-
-
```
mvn -Denv=dev-2 integration-test
```
will result in a successful build, applying the properties given by profile named `appserverConfig-dev-2`. And when we execute
-
-
```
mvn -Denv=dev integration-test
```
it will result in a successful build applying the properties given by the profile named `appserverConfig-dev`. However, executing:
-
-
```
mvn -Denv=production integration-test
```
will not do a successful build. Why? Because, the resulting non-interpolated literal value of `${appserver.home}` will not be a valid path for deploying and testing your web application. We haven't considered the case for the production environment when writing our profiles. The "production" environment (env=production), along with "test" and possibly even "local" constitute a natural set of target environments for which we may want to build the integration-test lifecycle phase. The inc [...]
-
As a quick aside, it's possible for user-specific profiles to act in a similar way. This means that profiles for handling different environments which are keyed to the user can act up when the team adds a new developer. While I suppose this _could_ act as useful training for the newbie, it just wouldn't be nice to throw them to the wolves in this way. Again, be sure to think of the _whole_ set of profiles.
-
-
-
### How can I tell which profiles are in effect during a build?
-
Determining active profiles will help the user to know what particular profiles has been executed during a build. We can use the [Maven Help Plugin](/plugins/maven-help-plugin/) to tell what profiles are in effect during a build.
-
-
```
mvn help:active-profiles
```
Let us have some small samples that will help us to understand more on the _active-profiles_ goal of that plugin.
-
From the last example of profiles in the `pom.xml`, you'll notice that there are two profiles named `appserverConfig-dev` and `appserverConfig-dev-2` which has been given different values for properties. If we go ahead and execute:
-
-
```
mvn help:active-profiles -Denv=dev
```
The result will be a bulleted list of the id of the profile with an activation property of "env=dev" together with the source where it was declared. See sample below.
-
-
```
The following profiles are active:
@@ -762,16 +609,12 @@ The following profiles are active:
Now if we have a profile declared in `settings.xml` (refer to the sample of profile in `settings.xml`) and that have been set to be an active profile and execute:
-
-
```
mvn help:active-profiles
```
The result should be something like this
-
-
```
The following profiles are active:
@@ -780,19 +623,14 @@ The following profiles are active:
Even though we don't have an activation property, a profile has been listed as active. Why? Like we mentioned before, a profile that has been set as an active profile in the `settings.xml` is automatically activated.
-
Now if we have something like a profile in the `settings.xml` that has been set as an active profile and also triggered a profile in the POM. Which profile do you think will have an effect on the build?
-
-
```
mvn help:active-profiles -P appserverConfig-dev
```
This will list the activated profiles:
-
-
```
The following profiles are active:
@@ -802,34 +640,22 @@ The following profiles are active:
Even though it listed the two active profiles, we are not sure which one of them has been applied. To see the effect on the build execute:
-
-
```
mvn help:effective-pom -P appserverConfig-dev
```
This will print the effective POM for this build configuration out to the console. Take note that profiles in the `settings.xml` takes higher priority than profiles in the POM. So the profile that has been applied here is `appserverConfig` not `appserverConfig-dev`.
-
If you want to redirect the output from the plugin to a file called `effective-pom.xml`, use the command-line option `-Doutput=effective-pom.xml`.
-
-
### Naming Conventions
-
By now you've noticed that profiles are a natural way of addressing the problem of different build configuration requirements for different target environments. Above, we discussed the concept of a "natural set" of profiles to address this situation, and the importance of considering the whole set of profiles that will be required.
-
However, the question of how to organize and manage the evolution of that set is non-trivial as well. Just as a good developer strives to write self-documenting code, it's important that your profile id's give a hint to their intended use. One good way to do this is to use the common system property trigger as part of the name for the profile. This might result in names like **env-dev**, **env-test**, and **env-prod** for profiles that are triggered by the system property **env**. Such [...]
-
-
```
mvn -Denv=test <phase>
```
The right command-line option can be had by simply substituting "=" for "-" in the profile id.
-
-
-
diff --git a/content/markdown/guides/introduction/introduction-to-repositories.md b/content/markdown/guides/introduction/introduction-to-repositories.md
index fb11b2a1..1451569a 100644
--- a/content/markdown/guides/introduction/introduction-to-repositories.md
+++ b/content/markdown/guides/introduction/introduction-to-repositories.md
@@ -23,120 +23,76 @@ under the License.
## Introduction to Repositories
-
### Artifact Repositories
-
A repository in Maven holds build artifacts and dependencies of varying types.
-
There are exactly two types of repositories: **local** and **remote**:
-
-
1 the **local** repository is a directory on the computer where Maven runs. It caches remote downloads and contains temporary build artifacts that you have not yet released.
1 **remote** repositories refer to any other type of repository, accessed by a variety of protocols such as `file://` and `https://`. These repositories might be a truly remote repository set up by a third party to provide their artifacts for downloading (for example, [repo.maven.apache.org](https://repo.maven.apache.org/maven2/)). Other "remote" repositories may be internal repositories set up on a file or HTTP server within your company, used to share private artifacts between develop [...]
-
Local and remote repositories are structured the same way so that scripts can run on either side, or they can be synced for offline use. The layout of the repositories is completely transparent to the Maven user, however.
-
-
### Using Repositories
-
In general, you should not need to do anything with the local repository on a regular basis, except clean it out if you are short on disk space (or erase it completely if you are willing to download everything again).
-
For the remote repositories, they are used for both downloading and uploading (if you have the permission to do so).
-
#### Downloading from a Remote Repository
-
Downloading in Maven is triggered by a project declaring a dependency that is not present in the local repository (or for a `SNAPSHOT`, when the remote repository contains one that is newer). By default, Maven will download from the [central](https://repo.maven.apache.org/maven2/) repository.
-
To override this, you need to specify a `mirror` as shown in [Using Mirrors for Repositories](../mini/guide-mirror-settings.html).
-
You can set this in your `settings.xml` file to globally use a certain mirror. However, it is common for a project to [customise the repository in its `pom.xml`](../mini/guide-multiple-repositories.html) and that your setting will take precedence. If dependencies are not being found, check that you have not overridden the remote repository.
-
For more information on dependencies, see [Dependency Mechanism](./introduction-to-dependency-mechanism.html).
-
-
#### Using Mirrors for the Central Repository
-
There are [several official Central repositories](/repository/) geographically distributed. You can make changes to your `settings.xml` file to use one or more mirrors. Instructions for this can be found in the guide [Using Mirrors for Repositories](../mini/guide-mirror-settings.html).
-
-
-
### Building Offline
-
If you are temporarily disconnected from the internet and you need to build your projects offline, you can use the offline switch on the CLI:
-
-
```
mvn -o package
```
Many plugins honor the offline setting and do not perform any operations that connect to the internet. Some examples are resolving Javadoc links and link checking the site.
-
-
### Uploading to a Remote Repository
-
While this is possible for any type of remote repository, you must have the permission to do so. To have someone upload to the Central Maven repository, see [Repository Center](../../repository/index.html).
-
-
### Internal Repositories
-
When using Maven, particularly in a corporate environment, connecting to the internet to download dependencies is not acceptable for security, speed or bandwidth reasons. For that reason, it is desirable to set up an internal repository to house a copy of artifacts, and to publish private artifacts to.
-
Such an internal repository can be downloaded using HTTP or the file system (with a `file://` URL), and uploaded to using SCP, FTP, or a file copy.
-
As far as Maven is concerned, there is nothing special about this repository: it is another **remote repository** that contains artifacts to download to a user's local cache, and is a publish destination for artifact releases.
-
Additionally, you may want to share the repository server with your generated project sites. For more information on creating and deploying sites, see [Creating a Site](../mini/guide-site.html).
-
-
### Setting up the Internal Repository
-
To set up an internal repository just requires that you have a place to put it, and then copy required artifacts there using the same layout as in a remote repository such as [repo.maven.apache.org](https://repo.maven.apache.org/maven2/).
-
It is _not_ recommended that you scrape or `rsync://` a full copy of central as there is a large amount of data there and doing so will get you banned. You can use a program such as those described on the [Repository Management](../../repository-management.html) page to run your internal repository's server, download from the internet as required, and then hold the artifacts in your internal repository for faster downloading later.
-
The other options available are to manually download and vet releases, then copy them to the internal repository, or to have Maven download them for a user, and manually upload the vetted artifacts to the internal repository which is used for releases. This step is the only one available for artifacts where the license forbids their distribution automatically, such as several J2EE JARs provided by Sun. Refer to the [Guide to coping with SUN JARs](../mini/guide-coping-with-sun-jars.html) [...]
-
It should be noted that Maven intends to include enhanced support for such features in the future, including click through licenses on downloading, and verification of signatures.
-
-
### Using the Internal Repository
-
Using the internal repository is quite simple. Simply make a change to add a `repositories` element:
-
-
```
<project>
@@ -154,17 +110,11 @@ under the License.
If your internal repository requires authentication, the `id` element can be used in your [settings](../../settings.html#Servers) file to specify login information.
-
-
### Deploying to the Internal Repository
-
One of the most important reasons to have one or more internal repositories is to be able to publish your own private releases.
-
To publish to the repository, you will need to have access via one of SCP, SFTP, FTP, WebDAV, or the filesystem. Connectivity is accomplished with the various [wagons](/wagon/wagon-providers/index.html). Some wagons may need to be added as [extension](/ref/current/maven-model/maven.html#class_extension) to your build.
-
<!-- For example, to set up an SCP transfer. -->
<!-- show the scp example. -->
-
diff --git a/content/markdown/guides/introduction/introduction-to-the-lifecycle.md b/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
index 8d2dbbf7..7c3fdbdd 100644
--- a/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
+++ b/content/markdown/guides/introduction/introduction-to-the-lifecycle.md
@@ -23,166 +23,117 @@ under the License.
## Introduction to the Build Lifecycle
-
### Table Of Contents
+- [Build Lifecycle Basics](#build-lifecycle-basics)
+- [Setting Up Your Project to Use the Build Lifecycle](#setting-up-your-project-to-use-the-build-lifecycle)
- - [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)
+ - [Packaging](#packaging)
- - [Built-in Lifecycle Bindings](#built-in-lifecycle-bindings)
+ - [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 [POM](./introduction-to-the-pom.html) will ensure they get the results they desired.
-
There are three built-in build lifecycles: default, clean and site. The `default` lifecycle handles your project deployment, the `clean` lifecycle handles project cleaning, while the `site` lifecycle handles the creation of your project's web site.
-
#### A Build Lifecycle is Made Up of Phases
-
Each of these build lifecycles is defined by a different list of build phases, wherein a build phase represents a stage in the lifecycle.
-
For example, the default lifecycle comprises of the following phases (for a complete list of the lifecycle phases, refer to the [Lifecycle Reference](Lifecycle_Reference)):
+- `validate` - validate the project is correct and all necessary information is available
+- `compile` - compile the source code of the project
- - `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.
+- `test` - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
- - `verify` - run any checks on results of integration tests to ensure quality criteria are met
+- `package` - take the compiled code and package it in its distributable format, such as a JAR.
- - `install` - install the package into the local repository, for use as a dependency in other projects locally
+- `verify` - run any checks on results of integration tests to ensure quality criteria are met
- - `deploy` - done in the build environment, copies the final package to the remote repository for sharing with other developers and projects.
+- `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, the [...]
-
_[\[top\]](./introduction-to-the-lifecycle.html)._
-
-
#### Usual Command Line Calls
-
You should select the phase that matches your outcome. If you want your jar, run `package`. If you want to run the unit tests, run `test`.
-
If you are uncertain what you want, the preferred phase to call is
-
-
```
mvn verify
```
This command executes each default lifecycle phase in order (`validate`, `compile`, `package`, etc.), before executing `verify`. You only need to call the last build phase to be executed, in this case, `verify`. In most cases the effect is the same as `package`. However, in case there are integration-tests, these will be executed as well. And during the `verify` phase some additional checks can be done, e.g. if your code written according to the predefined checkstyle rules.
-
In a build environment, use the following call to cleanly build and deploy artifacts into the shared repository.
-
-
```
mvn clean deploy
```
The same command can be used in a multi-module scenario (i.e. a project with one or more subprojects). Maven traverses into every subproject and executes `clean`, then executes `deploy` (including all of the prior build phase steps).
-
_[\[top\]](./introduction-to-the-lifecycle.html)._
-
-
#### A Build Phase is Made Up of Plugin Goals
-
However, even though a build phase is responsible for a specific step in the build lifecycle, the manner in which it carries out those responsibilities may vary. And this is done by declaring the plugin goals bound to those build phases.
-
A plugin goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation. The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked. For example, consider the command below. The `clean` and `package` arguments are build phases, while the `de [...]
-
-
```
mvn clean dependency:copy-dependencies package
```
If this were to be executed, the `clean` phase will be executed first (meaning it will run all preceding phases of the clean lifecycle, plus the `clean` phase itself), and then the `dependency:copy-dependencies` goal, before finally executing the `package` phase (and all its preceding build phases of the default lifecycle).
-
Moreover, if a goal is bound to one or more build phases, that goal will be called in all those phases.
-
Furthermore, a build phase can also have zero or more goals bound to it. If a build phase has no goals bound to it, that build phase will not execute. But if it has one or more goals bound to it, it will execute all those goals.
-
<!-- ~ -->
<!-- ~ Check if the following is true for Maven 3... -->
(_Note: In Maven 2.0.5 and above, multiple goals bound to a phase are executed in the same order as they are declared in the POM, however multiple instances of the same plugin are not supported. Multiple instances of the same plugin are grouped to execute together and ordered in Maven 2.0.11 and above_).
-
<!-- ~ -->
_[\[top\]](./introduction-to-the-lifecycle.html)._
-
-
#### Some Phases Are Not Usually Called From the Command Line
-
The phases named with hyphenated-words (`pre-\*`, `post-\*`, or `process-\*`) are not usually directly called from the command line. These phases sequence the build, producing intermediate results that are not useful outside the build. In the case of invoking `integration-test`, the environment may be left in a hanging state.
-
Code coverage tools such as Jacoco and execution container plugins such as Tomcat, Cargo, and Docker bind goals to the `pre-integration-test` phase to prepare the integration test container environment. These plugins also bind goals to the `post-integration-test` phase to collect coverage statistics or decommission the integration test container.
-
Failsafe and code coverage plugins bind goals to `integration-test` and `verify` phases. The net result is test and coverage reports are available after the `verify` phase. If `integration-test` were to be called from the command line, no reports are generated. Worse is that the integration test container environment is left in a hanging state; the Tomcat webserver or Docker instance is left running, and Maven may not even terminate by itself.
-
_[\[top\]](./introduction-to-the-lifecycle.html)._
-
-
-
### Setting Up Your Project to Use the Build Lifecycle
-
The build lifecycle is simple enough to use, but when you are constructing a Maven build for a project, how do you go about assigning tasks to each of those build phases?
-
#### Packaging
-
The first, and most common way, is to set the packaging for your project via the equally named POM element `<packaging>`. Some of the valid packaging values are `jar`, `war`, `ear` and `pom`. If no packaging value has been specified, it will default to `jar`.
-
Each packaging contains a list of goals to bind to a particular phase. For example, the `jar` packaging will bind the following goals to build phases of the default lifecycle.
-
|Phase|plugin:goal|
|---|---|
|`process-resources`|`resources:resources`|
@@ -196,30 +147,20 @@ mvn clean dependency:copy-dependencies package
This is an almost [standard set of bindings](/ref/current/maven-core/default-bindings.html); however, some packagings handle them differently. For example, a project that is purely metadata (packaging value is `pom`) only binds goals to the `install` and `deploy` phases (for a complete list of goal-to-build-phase bindings of some of the packaging types, refer to the [Lifecycle Reference](Lifecycle_Reference)).
-
Note that for some packaging types to be available, you may also need to include a particular plugin in the `<build>` section of your POM and specify `<extensions>true</extensions>` for that plugin. One example of a plugin that requires this is the Plexus plugin, which provides a `plexus-application` and `plexus-service` packaging.
-
_[\[top\]](./introduction-to-the-lifecycle.html)._
-
-
#### Plugins
-
The second way to add goals to phases is to configure plugins in your project. Plugins are artifacts that provide goals to Maven. Furthermore, a plugin may have one or more goals wherein each goal represents a capability of that plugin. For example, the Compiler plugin has two goals: `compile` and `testCompile`. The former compiles the source code of your main code, while the latter compiles the source code of your test code.
-
As you will see in the later sections, plugins can contain information that indicates which lifecycle phase to bind a goal to. Note that adding the plugin on its own is not enough information - you must also specify the goals you want to run as part of your build.
-
The goals that are configured will be added to the goals already bound to the lifecycle from the packaging selected. If more than one goal is bound to a particular phase, the order used is that those from the packaging are executed first, followed by those configured in the POM. Note that you can use the `<executions>` element to gain more control over the order of particular goals.
-
For example, the Modello plugin binds by default its goal `modello:java` to the `generate-sources` phase (Note: The `modello:java` goal generates Java source codes). So to use the Modello plugin and have it generate sources from a model and incorporate that into the build, you would add the following to your POM in the `<plugins>` section of `<build>`:
-
-
```
<plugin>
<groupId>org.codehaus.modello</groupId>
@@ -243,14 +184,10 @@ mvn clean dependency:copy-dependencies package
You might be wondering why that `<executions>` element is there. That is so that you can run the same goal multiple times with different configuration if needed. Separate executions can also be given an ID so that during inheritance or the application of profiles you can control whether goal configuration is merged or turned into an additional execution.
-
When multiple executions are given that match a particular phase, they are executed in the order specified in the POM, with inherited executions running first.
-
Now, in the case of `modello:java`, it only makes sense in the `generate-sources` phase. But some goals can be used in more than one phase, and there may not be a sensible default. For those, you can specify the phase yourself. For example, let's say you have a goal `display:time` that echos the current time to the commandline, and you want it to run in the `process-test-resources` phase to indicate when the tests were started. This would be configured like so:
-
-
```
<plugin>
<groupId>com.mycompany.example</groupId>
@@ -269,28 +206,20 @@ mvn clean dependency:copy-dependencies package
_[\[top\]](./introduction-to-the-lifecycle.html)._
-
-
-
### Lifecycle Reference
-
The following lists all build phases of the `default`, `clean` and `site` lifecycles, which are executed in the order given up to the point of the one specified.
-
#### Clean Lifecycle
-
|Phase|Description|
|---|---|
|`pre-clean`|execute processes needed prior to the actual project cleaning|
|`clean`|remove all files generated by the previous build|
|`post-clean`|execute processes needed to finalize the project cleaning|
-
#### Default Lifecycle
-
|Phase|Description|
|---|---|
|`validate`|validate the project is correct and all necessary information is available.|
@@ -317,10 +246,8 @@ mvn clean dependency:copy-dependencies package
|`install`|install the package into the local repository, for use as a dependency in other projects locally.|
|`deploy`|done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.|
-
#### Site Lifecycle
-
|Phase|Description|
|---|---|
|`pre-site`|execute processes needed prior to the actual project site generation|
@@ -330,26 +257,18 @@ mvn clean dependency:copy-dependencies package
_[\[top\]](./introduction-to-the-lifecycle.html)._
-
-
-
### Built-in Lifecycle Bindings
-
Some phases have goals bound to them by default. And for the default lifecycle, these bindings depend on the packaging value. Here are some of the goal-to-build-phase bindings.
-
#### Clean Lifecycle Bindings
-
|Phase|plugin:goal|
|---|---|
|`clean`|`clean:clean`|
-
#### Default Lifecycle Bindings - Packaging `ejb` / `ejb3` / `jar` / `par` / `rar` / `war`
-
|Phase|plugin:goal|
|---|---|
|`process-resources`|`resources:resources`|
@@ -361,10 +280,8 @@ mvn clean dependency:copy-dependencies package
|`install`|`install:install`|
|`deploy`|`deploy:deploy`|
-
#### Default Lifecycle Bindings - Packaging `ear`
-
|Phase|plugin:goal|
|---|---|
|`generate-resources`|`ear:generate-application-xml`|
@@ -373,10 +290,8 @@ mvn clean dependency:copy-dependencies package
|`install`|`install:install`|
|`deploy`|`deploy:deploy`|
-
#### Default Lifecycle Bindings - Packaging `maven-plugin`
-
|Phase|plugin:goal|
|---|---|
|`generate-resources`|`plugin:descriptor`|
@@ -389,40 +304,27 @@ mvn clean dependency:copy-dependencies package
|`install`|`install:install`|
|`deploy`|`deploy:deploy`|
-
#### Default Lifecycle Bindings - Packaging `pom`
-
|Phase|plugin:goal|
|---|---|
|`package`||
|`install`|`install:install`|
|`deploy`|`deploy:deploy`|
-
#### Site Lifecycle Bindings
-
|Phase|plugin:goal|
|---|---|
|`site`|`site:site`|
|`site-deploy`|`site:deploy`|
-
#### References
-
The full Maven lifecycle is defined by the `components.xml` file in the `maven-core` module, with [associated documentation](/ref/current/maven-core/lifecycles.html) for reference.
-
Default lifecycle bindings are defined in a separate `[default-bindings.xml](https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml)` descriptor.
-
See [Lifecycles Reference](/ref/current/maven-core/lifecycles.html) and [Plugin Bindings for default Lifecycle Reference](/ref/current/maven-core/default-bindings.html) for latest documentation taken directly from source code.
-
_[\[top\]](./introduction-to-the-lifecycle.html)._
-
-
-
-
diff --git a/content/markdown/guides/introduction/introduction-to-the-pom.md b/content/markdown/guides/introduction/introduction-to-the-pom.md
index 9f6b3909..1d930325 100644
--- a/content/markdown/guides/introduction/introduction-to-the-pom.md
+++ b/content/markdown/guides/introduction/introduction-to-the-pom.md
@@ -25,91 +25,64 @@ under the License.
## Introduction to the POM
+- [What is a POM](./introduction-to-the-pom.html#what-is-a-pom)?
+- [Super POM](./introduction-to-the-pom.html#super-pom)
- - [What is a POM](./introduction-to-the-pom.html#what-is-a-pom)?
+- [Minimal POM](./introduction-to-the-pom.html#minimal-pom)
- - [Super POM](./introduction-to-the-pom.html#super-pom)
+- [Project Inheritance](./introduction-to-the-pom.html#project-inheritance)
- - [Minimal POM](./introduction-to-the-pom.html#minimal-pom)
+- [Example 1](./introduction-to-the-pom.html#example-1)
- - [Project Inheritance](./introduction-to-the-pom.html#project-inheritance)
+- [Example 2](./introduction-to-the-pom.html#example-2)
- - [Example 1](./introduction-to-the-pom.html#example-1)
+- [Project Aggregation](./introduction-to-the-pom.html#project-aggregation)
- - [Example 2](./introduction-to-the-pom.html#example-2)
+- [Example 3](./introduction-to-the-pom.html#example-3)
+- [Example 4](./introduction-to-the-pom.html#example-4)
+- [Project Inheritance vs Project Aggregation](./introduction-to-the-pom.html#project-inheritance-vs-project-aggregation)
- - [Project Aggregation](./introduction-to-the-pom.html#project-aggregation)
-
- - [Example 3](./introduction-to-the-pom.html#example-3)
-
- - [Example 4](./introduction-to-the-pom.html#example-4)
-
-
-
- - [Project Inheritance vs Project Aggregation](./introduction-to-the-pom.html#project-inheritance-vs-project-aggregation)
-
- - [Example 5](./introduction-to-the-pom.html#example-5)
-
-
-
- - [Project Interpolation and Variables](./introduction-to-the-pom.html#project-nterpolation)
-
- - [Available Variables](./introduction-to-the-pom.html#available-variables)
-
+- [Example 5](./introduction-to-the-pom.html#example-5)
+- [Project Interpolation and Variables](./introduction-to-the-pom.html#project-nterpolation)
+- [Available Variables](./introduction-to-the-pom.html#available-variables)
### What is a POM?
-
A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects. Examples for this is the build directory, which is `target`; the source directory, which is `src/main/java`; the test source directory, which is `src/test/java`; and so on. When executing a task or goal, Maven looks for the POM in the current direct [...]
-
Some of the configuration that can be specified in the POM are the project dependencies, the plugins or goals that can be executed, the build profiles, and so on. Other information such as the project version, description, developers, mailing lists and such can also be specified.
-
[\[top\]](./introduction-to-the-pom.html)
-
-
### Super POM
-
The Super POM is Maven's default POM. All POMs extend the Super POM unless explicitly set, meaning the configuration specified in the Super POM is inherited by the POMs you created for your projects.
-
You can see the [Super POM for Maven 3.6.3](/ref/3.6.3/maven-model-builder/super-pom.html) in Maven Core reference documentation.
-
[\[top\]](./introduction-to-the-pom.html)
-
-
### Minimal POM
-
The minimum requirement for a POM are the following:
+- `project` root
+- `modelVersion` - should be set to 4.0.0
- - `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)
+- `groupId` - the id of the project's group.
- - `version` - the version of the artifact under the specified group
+- `artifactId` - the id of the artifact (project)
+- `version` - the version of the artifact under the specified group
Here's an example:
-
-
```
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
@@ -122,50 +95,36 @@ under the License.
A POM requires that its groupId, artifactId, and version be configured. These three values form the project's fully qualified artifact name. This is in the form of `<groupId>:<artifactId>:<version>`. As for the example above, its fully qualified artifact name is "com.mycompany.app:my-app:1".
-
Also, as mentioned in the [first section](#hat-is-a-pom), if the configuration details are not specified, Maven will use their defaults. One of these default values is the packaging type. Every Maven project has a packaging type. If it is not specified in the POM, then the default value "jar" would be used.
-
Furthermore, you can see that in the minimal POM the _repositories_ were not specified. If you build your project using the minimal POM, it would inherit the _repositories_ configuration in the Super POM. Therefore when Maven sees the dependencies in the minimal POM, it would know that these dependencies will be downloaded from `https://repo.maven.apache.org/maven2` which was specified in the Super POM.
-
[\[top\]](./introduction-to-the-pom.html)
-
-
### Project Inheritance
-
Elements in the POM that are merged are the following:
+- dependencies
+- developers and contributors
- - dependencies
-
- - developers and contributors
... 8027 lines suppressed ...