You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by el...@apache.org on 2020/03/17 22:22:48 UTC
[maven-site] branch master updated: remove many references to Maven
1.x and 2.x (#144)
This is an automated email from the ASF dual-hosted git repository.
elharo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
The following commit(s) were added to refs/heads/master by this push:
new 90cdb92 remove many references to Maven 1.x and 2.x (#144)
90cdb92 is described below
commit 90cdb92ce34247e4d00101a05c19260268c76992
Author: Elliotte Rusty Harold <el...@users.noreply.github.com>
AuthorDate: Tue Mar 17 18:22:39 2020 -0400
remove many references to Maven 1.x and 2.x (#144)
---
.../introduction/introduction-to-plugins.apt | 106 +--------------------
.../introduction/introduction-to-the-lifecycle.apt | 4 +-
.../guide-building-for-different-environments.apt | 8 +-
.../guides/mini/guide-default-execution-ids.apt | 14 +--
content/markdown/faq-unoffical.md | 36 -------
content/markdown/maven-2.x-eol.md | 3 +-
content/markdown/maven-logging.md | 2 +-
content/markdown/settings.md | 2 +-
content/pdf.xml | 2 -
content/resources/xsd/maven-4.0.0.xsd | 5 -
content/resources/xsd/maven-v3_0_0.xsd | 2 +-
11 files changed, 13 insertions(+), 171 deletions(-)
diff --git a/content/apt/guides/introduction/introduction-to-plugins.apt b/content/apt/guides/introduction/introduction-to-plugins.apt
index 623e3a7..6ac2401 100644
--- a/content/apt/guides/introduction/introduction-to-plugins.apt
+++ b/content/apt/guides/introduction/introduction-to-plugins.apt
@@ -66,11 +66,8 @@ Introduction to Maven Plugin Development
metadata about a goal: a goal name, which phase of the lifecycle it fits into,
and the parameters it is expecting.
- Mojo term was introduced in Maven 2 as a complete rework on how to write plugins
- (see below for more details on Maven 1.x plugins comparison).
-
MOJO is a play on POJO (Plain-old-Java-object), substituting "Maven" for
- "Plain". Mojo is also an iteresting word (see {{{http://www.answers.com/mojo&r=67}definition}}).
+ "Plain". Mojo is also an interesting word (see {{{http://www.answers.com/mojo&r=67}definition}}).
From {{{http://www.wikipedia.org}Wikipedia}}, a "mojo" is defined as:
"...a small bag worn by a person under the clothes (also known as a mojo hand).
Such bags were thought to have supernatural powers, such as protecting from evil,
@@ -88,104 +85,3 @@ Resources
[[2]] {{{../mini/guide-configuring-plugins.html}Configuring plugins}}
-Comparison to Maven 1.x Plugins
-
-* Similarities to Maven 1.x
-
- Maven 2.0 is similar to its predecessor in that it has two main
- functions. First, it organizes project data into a coherent whole,
- and exposes this data for use within the build process. Second, Maven
- marshals a set of plugins to do the heavy lifting and execute the
- actual steps of the build.
-
- Many things in Maven 2 will have at least superficial familiarity
- to users of Maven 1, and the plugin system is no exception. Maven 2
- plugins appear to behave much as their 1.x counterparts do. Like 1.x
- plugins, they use both project information and custom-defined
- configurations to perform their work. Also, Maven 2 plugins are
- organized and executed in a coherent way by the build engine itself -
- that is to say, the engine is still responsible for organizing and
- fulfilling a plugin's requirements before executing the plugin
- itself.
-
- Operationally, Maven 2.0 should feel very much like a more
- performant big brother of Maven 1.x. While the POM has definitely
- changed, it has the same basic layout and features (with notable
- additions). However, this is where the similarity ends. Maven 2.0 is
- a complete redesign and reimplementation of the Maven build concept.
- As such, it has a much different and more evolved architecture - at least to
- our minds. <<;-)>>
-
-* Differences from Maven 1.x
-
- However similar the architectures may seem, Maven 2 offers a much
- richer environment for its plugins than Maven 1 ever did. The new
- architecture offers a managed lifecycle, multiple implementation
- languages, reusability outside of the build system, and many more
- advantages. Arguably the biggest advantage is the ability to write
- Maven plugins entirely in Java, which allows developers to tap into a
- rich landscape of development and testing tools to aid in their
- efforts.
-
- Prior to Maven 2.0, the build system organized relevant plugins
- into a loosely defined lifecycle, which was determined based on goal
- prerequisites and decoration via preGoals and postGoals. That
- experience was critical for the Maven community. It taught us that
- even though there may be a million different build scenarios out
- there, most of the activities in those builds fit into just a few
- broad categories. Moreover, the category to which a goal fits serves
- as an accurate predictor for where in the build process the goal
- should execute. Drawing on this experience, Maven 2.0 defines a
- lifecycle within which plugins are managed according to their
- relative position within this lifecycle.
-
- Starting with Maven 2.0, plugins implemented in different
- programming or scripting languages can coexist within the same build
- process. This removes the requirement that plugin developers learn a
- particular scripting language in order to interact with Maven. It
- also reduced the risk associated with the stability or richness of
- any particular scripting language.
-
- Also starting with Maven 2.0 is an effort to integrate multiproject
- builds directly into the core architecture. In Maven 1.x, many large
- projects were fragmented into smaller builds to sidestep issues such
- as conditional compilation of a subset of classes; separation of
- client-server code; or cyclical dependencies between distinct
- application libraries. This in turn created extra complexity with
- running builds, since multiple builds had to be run in order to build
- the application as a whole - one or more per project. While the first
- version (1.x) did indeed address this new multiple projects issue, it
- did so as an afterthought. The Reactor was created to act as a sort
- of <apply-to-all-these> function, and the multiproject plugin
- was later added to provide Reactor settings for some common build
- types. However, this solution (it <is> really only one solution,
- plus some macros) really never integrated the idea of the
- multi-project build process into the maven core conceptual
- framework.
-
-* Why Change the Plugin Architecture?
-
- See the previous section for the long version, but the short version can
- be summed up by the following list of benefits.
-
- * A managed lifecycle
-
- * Multiple implementation languages
-
- * Reusability outside of the build system
-
- * The ability to write Maven plugins entirely in Java
-
- In Maven 1.0, a plugin was defined using Jelly, and while it was possibly to
- write a plugin in Java, you still had to wrap your plugin with some obligatory
- Jelly script. An XML-based scripting language which is interpreted at run-time
- isn't going to be the best choice for performance, and the development team
- thought it wise to adopt an approach which would allow plugin developers to
- choose from an array of plugin implementation choices. The first choice in
- Maven 2 should be Java plugins, but you may also use one of the supported
- scripting languages like Beanshell.
-
- To summarize, the development team saw some critical gaps in the API and
- architecture of Maven 1.0 plug-ins, and the team decided that addressing
- these deficiencies was critical to the future progress of Maven from a useful
- tool to something more robust.
diff --git a/content/apt/guides/introduction/introduction-to-the-lifecycle.apt b/content/apt/guides/introduction/introduction-to-the-lifecycle.apt
index 8987d86..e8a85be 100644
--- a/content/apt/guides/introduction/introduction-to-the-lifecycle.apt
+++ b/content/apt/guides/introduction/introduction-to-the-lifecycle.apt
@@ -337,11 +337,11 @@ mvn clean dependency:copy-dependencies package
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<test-compile>>> | compile the test source code into the test destination directory
*-------------------------------+--------------------------------------------------------------------------------------+
-| <<<process-test-classes>>> | post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.
+| <<<process-test-classes>>> | post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<test>>> | run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
*-------------------------------+--------------------------------------------------------------------------------------+
-| <<<prepare-package>>> | perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)
+| <<<prepare-package>>> | perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package.
*-------------------------------+--------------------------------------------------------------------------------------+
| <<<package>>> | take the compiled code and package it in its distributable format, such as a JAR.
*-------------------------------+--------------------------------------------------------------------------------------+
diff --git a/content/apt/guides/mini/guide-building-for-different-environments.apt b/content/apt/guides/mini/guide-building-for-different-environments.apt
index c58efe2..2fd757c 100644
--- a/content/apt/guides/mini/guide-building-for-different-environments.apt
+++ b/content/apt/guides/mini/guide-building-for-different-environments.apt
@@ -1,5 +1,5 @@
---
- Building For Different Environments with Maven 2
+ Building For Different Environments
---
Trygve Laugstøl
---
@@ -26,7 +26,7 @@
~~ NOTE: For help with the syntax of this file, see:
~~ http://maven.apache.org/doxia/references/apt-format.html
-Building For Different Environments with Maven 2
+Building For Different Environments
Building the same artifact for different environments has always been an annoyance. You have multiple environments,
for instance test and production servers or, maybe a set of servers that run the same application with different
@@ -36,7 +36,7 @@ Building For Different Environments with Maven 2
Note:
- * This guide assume that you have basic Maven 2 knowledge.
+ * This guide assume that you have basic Maven knowledge.
* It will show a way to configure Maven to solve simple configuration set-ups only. By simple configuration set-up I
mean cases where you only have a single file or a small set of files that vary for each environment. There are
@@ -137,7 +137,7 @@ src/
Caveats
- * Currently Maven 2 doesn't allow a project build to only produce attached artifacts. (i.e. it has to produce a
+ * Currently Maven doesn't allow a project build to only produce attached artifacts. (i.e. it has to produce a
"main" artifact as well) This results in two equal JARs being packaged and installed. The JAR plugin probably
should also get improved support for this use case to that two different output directories will be used as the
basis for building the JAR.
diff --git a/content/apt/guides/mini/guide-default-execution-ids.apt b/content/apt/guides/mini/guide-default-execution-ids.apt
index 1a3b6cb..b354b7f 100644
--- a/content/apt/guides/mini/guide-default-execution-ids.apt
+++ b/content/apt/guides/mini/guide-default-execution-ids.apt
@@ -50,10 +50,6 @@ Guide to Configuring Default Mojo Executions
[]
- Originally, the default value of the executionId - literally set to <<<default>>> in the POM model - was meant to provide some of this functionality.
- Unfortunately, this solution was never tested to make sure it worked with the use cases above; they fell through the cracks during testing. Now,
- with the release of Maven 2.2.0 (and later, Maven 3.0), these use cases can finally be addressed.
-
*Default <<<executionId>>>s for Implied Executions
When you consider the fact that the aforementioned configuration use cases are for mojos that are not explicitly mentioned in the POM, it's reasonable
@@ -115,7 +111,7 @@ Guide to Configuring Default Mojo Executions
section, and the other uses standard descriptors via the <<<descriptorRefs>>> section. These two sections cannot override one another, so it's
impossible to setup one section - say, <<<descriptorRefs>>> - in the plugin-level configuration block (to provide CLI access to it, as historical
versions of Maven would require), then have the <<<build-distros>>> invocation override it with the custom descriptors specified in the
- <<<descriptors>>> section. This configuration is not possible in versions of Maven before 2.2.0.
+ <<<descriptors>>> section.
**Example: Configuring <<<compile>>> to run twice
@@ -179,9 +175,6 @@ Guide to Configuring Default Mojo Executions
1.4-targeted binaries for the classes matching the <<<**/cli/*>>> path pattern.
[]
-
- Note that prior to Maven 2.2.0, it was much more difficult - if not impossible - to compile different subpaths within your project's
- codebase to target different Java versions.
**Example: Configuring <<<compile>>> and <<<testCompile>>> mojos separately
@@ -222,7 +215,4 @@ Guide to Configuring Default Mojo Executions
the only configuration that's really required is the <<<default-testCompile>>> execution. The <<<default-compile>>> execution respecifies plugin
defaults. The only time this might be useful is when a parent POM defines a plugin-level configuration for <<<source>>> and <<<target>>> that needs
to be changed for the purposes of these different compiler executions. This example is meant to be illustrative of the potential for separate configuration
- of default lifecycle mojos to be found in Maven 2.2.0.
-
- Again, the above configuration would not be possible in older versions of Maven. Starting with Maven 2.2.0, these advanced configurations have become
- a reality.
+ of default lifecycle mojos.
diff --git a/content/markdown/faq-unoffical.md b/content/markdown/faq-unoffical.md
index 15e07f2..48af0f7 100644
--- a/content/markdown/faq-unoffical.md
+++ b/content/markdown/faq-unoffical.md
@@ -1032,42 +1032,6 @@ 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?]
-### How do I convert my `<reports>` from Maven 1 to Maven 2?
-
-In m1, we declare reports in the pom like this:
-```
-<project>
- ...
- <reports>
- <report>maven-checkstyle-plugin</report>
- <report>maven-pmd-plugin</report>
- </reports>
-</project>
-```
-In m2, the `<reports>` tag is replaced with `<reporting>`
-```
-<project>
- ...
- <reporting>
- <plugins>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-checkstyle-plugin</artifactId>
- <configuration>
- <!-- put your config here -->
- </configuration>
- </plugin>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-pmd-plugin</artifactId>
- <configuration>
- <!-- put your config here -->
- </configuration>
- </plugin>
- </plugins>
- <reporting>
-</project>
-```
_Sites & Reporting, General_
### How do I create a command line parameter (i.e., \-Dname=value ) in my mojo?
diff --git a/content/markdown/maven-2.x-eol.md b/content/markdown/maven-2.x-eol.md
index 47cbc85..f19a8fa 100644
--- a/content/markdown/maven-2.x-eol.md
+++ b/content/markdown/maven-2.x-eol.md
@@ -17,8 +17,7 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
-The Apache Maven Project Team would like to inform you that the Apache
-Maven 2.x has reached its end of life and is no longer supported.
+Apache Maven 2.x has reached its end of life and is no longer supported.
Apache Maven 2.x had its last release - version 2.2.1 - in November 2009.
diff --git a/content/markdown/maven-logging.md b/content/markdown/maven-logging.md
index 5deb830..02ad9f5 100644
--- a/content/markdown/maven-logging.md
+++ b/content/markdown/maven-logging.md
@@ -17,7 +17,7 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
-Maven 2.x and 3.0.x use [Plexus logging API][6] with basic Maven implementation writing
+Maven uses [Plexus logging API][6] with basic Maven implementation writing
to stdout.
We have reached the decision that [SLF4J][1] is the best option for a logging API:
diff --git a/content/markdown/settings.md b/content/markdown/settings.md
index 2108545..be848e8 100644
--- a/content/markdown/settings.md
+++ b/content/markdown/settings.md
@@ -325,7 +325,7 @@ all are required at once.
- **jdk**: `activation` has a built in, Java-centric check in the
`jdk` element. This will activate if the test is run under a jdk
version number that matches the prefix given. In the above example,
- `1.5.0_06` will match. Ranges are also supported as of Maven 2.1.
+ `1.5.0_06` will match. Ranges are also supported.
See the
[maven-enforcer-plugin](https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html)
for more details about supported ranges.
diff --git a/content/pdf.xml b/content/pdf.xml
index b872db0..2723fae 100644
--- a/content/pdf.xml
+++ b/content/pdf.xml
@@ -87,8 +87,6 @@
<item name="What is an Archetype" ref="/guides/introduction/introduction-to-archetypes.html" />
<item name="Creating Archetypes" ref="/guides/mini/guide-creating-archetypes.html" />
- <item name="From Maven 1.x to Maven 2.x" ref="/guides/mini/guide-m1-m2.html" />
- <item name="Using Maven 1.x repositories with Maven 2.x" ref="/guides/mini/guide-using-m1-repos-with-m2.html" />
<item name="Relocation of Artifacts" ref="/guides/mini/guide-relocation.html" />
<item name="Installing 3rd party JARs to Local Repository" ref="/guides/mini/guide-3rd-party-jars-local.html" />
diff --git a/content/resources/xsd/maven-4.0.0.xsd b/content/resources/xsd/maven-4.0.0.xsd
index 30d56a7..5b330b7 100644
--- a/content/resources/xsd/maven-4.0.0.xsd
+++ b/content/resources/xsd/maven-4.0.0.xsd
@@ -2363,11 +2363,6 @@
<xs:documentation source="description">
For a plugin project (packaging is <code>maven-plugin</code>), the minimum version of
Maven required to use the resulting plugin.<br>
- In Maven 2, this was also specifying the minimum version of Maven required to build a
- project, but this usage is <b>deprecated</b> in Maven 3 and not checked any more: use
- the <a href="https://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html">Maven Enforcer Plugin's
- <code>requireMavenVersion</code> rule</a> instead.
-
</xs:documentation>
</xs:annotation>
</xs:element>
diff --git a/content/resources/xsd/maven-v3_0_0.xsd b/content/resources/xsd/maven-v3_0_0.xsd
index f7ca184..70629cf 100644
--- a/content/resources/xsd/maven-v3_0_0.xsd
+++ b/content/resources/xsd/maven-v3_0_0.xsd
@@ -562,7 +562,7 @@
<xs:annotation>
<xs:documentation source="version">3.0.0+</xs:documentation>
<xs:documentation source="description">
- The default goal (or phase in Maven 2) to execute when none is specified for the project.
+ The default goal to execute when none is specified for the project.
</xs:documentation>
</xs:annotation>
</xs:element>