Author: svn-site-role
Date: Thu Dec 20 11:01:46 2018
New Revision: 1849369
Log:
Site checkin for project Apache Maven Site
Modified:
maven/website/content/background/history-of-maven.html
maven/website/content/ide.html
maven/website/content/maven-ci-friendly.html
maven/website/content/maven-conventions.html
maven/website/content/maven-jsr330.html
maven/website/content/maven-site-1.0-site.jar
maven/website/content/project-roles.html
maven/website/content/reference/maven-classloading.html
maven/website/content/run.html
maven/website/content/security-plexus-archiver.html
Modified: maven/website/content/background/history-of-maven.html
==============================================================================
--- maven/website/content/background/history-of-maven.html (original)
+++ maven/website/content/background/history-of-maven.html Thu Dec 20 11:01:46
2018
@@ -130,7 +130,7 @@
<p>Though Maven started in Alexandria the test bed for its use was the Turbine
project. Turbine was in the process of decoupling its persistence layer,
services layer and web layer into separate builds and I got very tired of
having to maintain several different builds which were essentially the same.
There was no way to easy template Ant builds in those days and every ant build
appeared to be different and I found this incredibly frustrating and futile. I
figured who really cares how the build works so long as it works and is easy to
use. The infrastructure of a project is incredibly important but the value of a
project lies in the application being developed. As such the build is generally
neglected and tends to fall apart when you need it to work most like when you
need to prepare a release or when more then a couple of people are working on
the project. In Jakarta land four years ago it was rare that a Ant build worked
out of the box. Mind you many Turbine developers suffered as
I tried to get Maven working which is something I regret, but I figure how do
new projects start and survive if someone doesn’t suffer. I figured it
was for their own good (I’ve been known to have an opinion or two) and
after much gnashing of teeth I think Maven has finally come of age. It reminds
me of one of my favourite quotes from Ralph Johnson and Don Roberts in Patterns
for Evolving Frameworks:</p>
<blockquote>
-<p>People develop abstractions by generalizing from concrete examples. Every
attempt to determine the correct abstraction on paper without actually
developing a running system is doomed to failure. No one is that smart. A
framework is a resuable design, so you develop it by looking at the things it
is supposed to be a design of. The more examples you look at, the more general
your framework will be.</p>
+<p>People develop abstractions by generalizing from concrete examples. Every
attempt to determine the correct abstraction on paper without actually
developing a running system is doomed to failure. No one is that smart. A
framework is a reusable design, so you develop it by looking at the things it
is supposed to be a design of. The more examples you look at, the more general
your framework will be.</p>
</blockquote>
<p>I didn’t really know what the final result would look like I just
knew there had to be a better way. But to start with I know I wanted:</p>
<ul>
@@ -139,7 +139,7 @@
<li>A standard directory structure so you didn’t have to go fishing
around for libraries, sources and documentation</li>
</ul>
<p>So started using a model with a simple XML representation and picked what I
thought were some decent standards for a directory structure and that’s
how it started. I was still using Ant under the covers but I had some standard
targets that could be used in each of the Turbine builds and that made me
happy.</p>
-<p>As noted above one of the projects in Alexandria at the time was Gump. Sam
Ruby tried to convince me that using the Gump model would be a good idea so I
took a look. After taking a look at the descriptors I noted that Gump pretty
much allowed any project to do whatever it wanted in terms of directory
structure, use of JARs in CVS, multiple artifacts per project, documentation
splayed everywhere, and several other things that made no sense to me as Gump
was not trying to standardize anything at the time but trying to continuously
integrate anything it could get its hands on. My goals were different and I
wanted to make an <a class="externalLink"
href="http://www.oreillynet.com/pub/a/network/2005/08/30/ruby-rails-david-heinemeier-hansson.html";>opinionated</a>
piece of software and I preferred the notion of convention over configuration.
I wanted a project’s infrastructure to look the same and work the same
so I continued to pursue my own model for a project and decided to di
sagree with Gump’s particular tact at project modelling which I thought
was too flexible. I wanted to save people time by being able to find things in
the same place. Again the value in a project is the final result: how it is
constructed and built predictable and easy. I fully admit some warts in Maven
1.x sometimes made things harder but that is par for the course with first
generation tools.</p>
+<p>As noted above one of the projects in Alexandria at the time was Gump. Sam
Ruby tried to convince me that using the Gump model would be a good idea so I
took a look. After taking a look at the descriptors I noted that Gump pretty
much allowed any project to do whatever it wanted in terms of directory
structure, use of JARs in CVS, multiple artifacts per project, documentation
splayed everywhere, and several other things that made no sense to me as Gump
was not trying to standardize anything at the time but trying to continuously
integrate anything it could get its hands on. My goals were different and I
wanted to make an <a class="externalLink"
href="http://www.oreillynet.com/pub/a/network/2005/08/30/ruby-rails-david-heinemeier-hansson.html";>opinionated</a>
piece of software and I preferred the notion of convention over configuration.
I wanted a project’s infrastructure to look the same and work the same
so I continued to pursue my own model for a project and decided to di
sagree with Gump’s particular tact at project modeling which I thought
was too flexible. I wanted to save people time by being able to find things in
the same place. Again the value in a project is the final result: how it is
constructed and built predictable and easy. I fully admit some warts in Maven
1.x sometimes made things harder but that is par for the course with first
generation tools.</p>
<p>The next thing I noticed were all the JARs that we were depending on were
stored in CVS. We had many copies of Xerces laying around which is a waste of
space, every time the version of Xerces changed I had to update the copies of
Xerces in each of the projects, but more importantly without some declarative
statement of your dependencies there is no way you could perform any analysis.
People tend to miss the point entirely regarding a declarative dependency use.
People say it’s so easy just to store their dependencies in an SCM but
try decomposing your big crappy build into components to encourage reuse and
ease of maintenance, or try to analyze what you might need at runtime between
all your different apps with commons dependencies in the graph and
you’re shit out of luck. The true power of declarative dependencies lies
not in the fact that you can save a few bytes of disk space, though it can
really add up if you’re not careful, but in the analysis that can
be performed. Once you have a decent graph all sorts of things are possible.
Back to history: so now that declarative dependencies existed it needed to be
easier …</p>
<p>This is when I decided to employ standard Java-like inheritance in the
model used and find a way to create a repository for things you need to build.
So I hacked in some inheritance goop and now it was time for the repository. I
asked around Apache to see if it would be possible to host a repository and
soon found out that it was not possible to host non-Apache-like artifacts. So
LGPL and GPL artifacts were out which didn’t really make for a useful
repository. After a little hunting I found <a class="externalLink"
href="http://www.ibiblio.org";>Ibiblio</a> which is a vast archive of all sorts
of neat stuff including tons of free software. One of the mandates of Ibiblio
is to aid in the dispersal of free software. Sounded perfect to me so I got in
contact with John Reuning at Ibiblio and the rest is history. Working with the
folks at Ibiblio has been a pleasure, the admins there are an amazingly helpful
and talented bunch. They let us store whatever free software we want, pr
ovide great stats, and will let us host any software we want. Ibiblio is very
cool.</p>
<p>Many people had some problems with Maven 1.x but it generally worked and
all tools in their first generation suffer from many short comings and the only
way to overcome that is to forge ahead and try to create something better the
next time around. With all the feed back the Maven developers have received
from 1.x users and during the betas of 2.0 we think we’ve finally got
something to build on. The first version of Maven was written by myself with
lots of help from Bob McWhirter</p></div>
Modified: maven/website/content/ide.html
==============================================================================
--- maven/website/content/ide.html (original)
+++ maven/website/content/ide.html Thu Dec 20 11:01:46 2018
@@ -146,7 +146,7 @@
<p>M2E dynamically integrates with your Maven projects with Eclipse while you
make changes in the IDE. As you change dependencies, or configurations of Maven
plugins in your POMs M2E, will synchronize the Eclipse workspace with those
changes.</p></div>
<div class="section">
<h2><a name="JetBrains_IntelliJ_IDEA"></a>JetBrains IntelliJ IDEA</h2>
-<p>Intelli IDEA has a <a class="externalLink"
href="https://www.jetbrains.com/idea/help/maven.html";>feature-rich integration
for Maven</a>.</p></div>
+<p>IntelliJ IDEA has a <a class="externalLink"
href="https://www.jetbrains.com/idea/help/maven.html";>feature-rich integration
for Maven</a>.</p></div>
<div class="section">
<h2><a name="Netbeans_IDE"></a>Netbeans IDE</h2>
<p>NetBeans includes full Maven support since 6.7, including Maven 3 support
in 7.0+. You can open any Maven project in the IDE and start coding
immediately.</p>
Modified: maven/website/content/maven-ci-friendly.html
==============================================================================
--- maven/website/content/maven-ci-friendly.html (original)
+++ maven/website/content/maven-ci-friendly.html Thu Dec 20 11:01:46 2018
@@ -156,7 +156,7 @@
<pre class="source">mvn -Drevision=1.0.0-SNAPSHOT clean package
</pre></div></div>
-<p>This wil become cumbersome over the time. So the other solution for this is
to simply use a property inside the pom file which looks like this:</p>
+<p>This will become cumbersome over the time. So the other solution for this
is to simply use a property inside the pom file which looks like this:</p>
<div>
<div>
@@ -186,7 +186,7 @@
<pre class="source">mvn -Drevision=2.0.0-SNAPSHOT clean package
</pre></div></div>
-<p>Of cource you can use the <tt>.mvn/maven.config</tt> file for this.</p>
+<p>Of course you can use the <tt>.mvn/maven.config</tt> file for this.</p>
<p>A note about the used properties. You can only use those named
<tt>${revision}</tt>, <tt>${sha1}</tt> and/or <tt>${changelist}</tt> and not
other named properties like this:</p>
<div>
@@ -209,7 +209,7 @@
</project>
</pre></div></div>
-<p>The above example will <i>not work as expeced</i>. If you like to have more
flexibility you can use a combination of the different properties like this:</p>
+<p>The above example will <i>not work as expected</i>. If you like to have
more flexibility you can use a combination of the different properties like
this:</p>
<div>
<div>
@@ -240,7 +240,7 @@
<pre class="source">mvn -Drevision=2.0.0 clean package
</pre></div></div>
-<p>Another usage example can be do make a release which can be done via
(version 1.3.1):</p>
+<p>Another usage example can be to make a release which can be done via
(version 1.3.1):</p>
<div>
<div>
@@ -257,7 +257,7 @@
<p>Please read until the end of this documentation!</p></div>
<div class="section">
<h2><a name="Multi_Module_Setup"></a>Multi Module Setup</h2>
-<p>So now let us take a look into a situation where we have a multi module
build. We have a parent pom and one or more childs. The parent pom will look
like this:</p>
+<p>So now let us take a look into a situation where we have a multi module
build. We have a parent pom and one or more children. The parent pom will look
like this:</p>
<div>
<div>
@@ -303,7 +303,7 @@
<p>A multi module build can of course build the same way as the single project
setup. You should define the version either via property in the parent or use
the <tt>.mvn/maven.config</tt> file.</p></div>
<div class="section">
<h2><a name="Install_.2F_Deploy"></a>Install / Deploy</h2>
-<p>If you like to install or deploy artifacts by using the above setup you
<b>have to use</b> the <a class="externalLink"
href="https://www.mojohaus.org/flatten-maven-plugin/";>flatten-maven-plugin</a>
otherwise you will install/deploy artifacts in your repository which will not
be cosumable by Maven anymore. Such kind of setup will look like this:</p>
+<p>If you like to install or deploy artifacts by using the above setup you
<b>have to use</b> the <a class="externalLink"
href="https://www.mojohaus.org/flatten-maven-plugin/";>flatten-maven-plugin</a>
otherwise you will install/deploy artifacts in your repository which will not
be consumable by Maven anymore. Such kind of setup will look like this:</p>
<div>
<div>
Modified: maven/website/content/maven-conventions.html
==============================================================================
--- maven/website/content/maven-conventions.html (original)
+++ maven/website/content/maven-conventions.html Thu Dec 20 11:01:46 2018
@@ -135,7 +135,7 @@
maven : wagon-api
</pre></div></div>
-<p>As previously mentioned, the artifact ID should be the basis of the
filename for the project, as by default Maven will use that and the version to
assemble the filename. Having the version as part of the filename is strongly
recommended to ensure that the version can be determined at a glance without
having to check a possibly non-existant manifest, or compare file sizes with
the official releases.</p>
+<p>As previously mentioned, the artifact ID should be the basis of the
filename for the project, as by default Maven will use that and the version to
assemble the filename. Having the version as part of the filename is strongly
recommended to ensure that the version can be determined at a glance without
having to check a possibly non-existent manifest, or compare file sizes with
the official releases.</p>
<p>Following these guidelines are particularly encouraged when distributing
via the Maven Repository, to ensure that it can easily fit alongside other
projects and reduce the risk of conflicts and confusion.</p></div>
<div class="section">
<h2><a name="Directory_Structure"></a>Directory Structure</h2>
Modified: maven/website/content/maven-jsr330.html
==============================================================================
--- maven/website/content/maven-jsr330.html (original)
+++ maven/website/content/maven-jsr330.html Thu Dec 20 11:01:46 2018
@@ -417,7 +417,7 @@ public class LifecycleProfiler extends A
</project>
</pre></div></div>
-<p>Now let's take a look at the plugin code. You'll notice that we're using
constructor injection which makes testing a lot easier. If you want to test
your <tt>Jsr330Component</tt>, you do not need the container to instantiate the
<tt>Mojo</tt>. In this simple case, you can actually test this plugin without
using the plugin testing harness because you can instantiate the
<tt>Jsr330Component</tt> and <tt>Jsr330Mojo</tt> directly and wire everything
up manually using the constructor. Constructor injection, which Plexus lacks,
greatly simplies testing.</p>
+<p>Now let's take a look at the plugin code. You'll notice that we're using
constructor injection which makes testing a lot easier. If you want to test
your <tt>Jsr330Component</tt>, you do not need the container to instantiate the
<tt>Mojo</tt>. In this simple case, you can actually test this plugin without
using the plugin testing harness because you can instantiate the
<tt>Jsr330Component</tt> and <tt>Jsr330Mojo</tt> directly and wire everything
up manually using the constructor. Constructor injection, which Plexus lacks,
greatly simplifies testing.</p>
<div>
<div>
Modified: maven/website/content/maven-site-1.0-site.jar
==============================================================================
Binary files - no diff available.
Modified: maven/website/content/project-roles.html
==============================================================================
--- maven/website/content/project-roles.html (original)
+++ maven/website/content/project-roles.html Thu Dec 20 11:01:46 2018
@@ -240,14 +240,14 @@ under the License.
</ul>
<p>It is self evident that the opportunity for review is much greater if the
code is committed to the project’s source control as early as possible.
Similarly small commits are easier to review than large commits.</p>
<p>There is nothing inherently wrong with maintaining a fork of the Maven
codebase outside of the Apache Foundation. Individual developers can have their
own style of working and may prefer to work in a fork so that they can throw
away failed experiments with less visibility (though it could be argued that
the visibility of such failed experiments can be valuable documentation for
others). As soon as changes in that fork are identified (by the people
maintaining the fork) which should be brought back to the project those changes
should be introduced into at least a branch hosted on the Apache Maven source
control in order to facilitate the easier review by the community. The PMC
should encourage by example the early committing of such changes from a fork
(that they are involved in maintaining) back to Apache Maven source
control.</p>
-<p>Similarly, if a fork is being hosted elsewhere in order to get
contributions from other talented individuals, the PMC members should endevour
to bring those individuals and their talent to the project as committers.</p>
-<p>Finally, where a fork is hosted outside of Apache hardware, there is less
traceability of the code provenance, for example Git commits can be squashed
and history re-written to mask or otherwise hide the source of contributions.
This does not mean that code coming from an external fork inherently has such
issues, instead it means that the requirements for review and verification of
provenance grow exponentially when dealing with large sets of changes
originating from a long running fork hosted outside of Apache foundation source
control. Anybody maintaining a long running fork should be aware of the risk
that review obligations may grow above the time capabilities of the PMC and
committers such that when they eventually decide to try and bring the changes
in their fork back to the Apache Maven project their contribution may end up
being rejected on the basis of the review of a large set of changes being too
difficult/timeconsuming.</p></div></div>
+<p>Similarly, if a fork is being hosted elsewhere in order to get
contributions from other talented individuals, the PMC members should endeavour
to bring those individuals and their talent to the project as committers.</p>
+<p>Finally, where a fork is hosted outside of Apache hardware, there is less
traceability of the code provenance, for example Git commits can be squashed
and history re-written to mask or otherwise hide the source of contributions.
This does not mean that code coming from an external fork inherently has such
issues, instead it means that the requirements for review and verification of
provenance grow exponentially when dealing with large sets of changes
originating from a long running fork hosted outside of Apache foundation source
control. Anybody maintaining a long running fork should be aware of the risk
that review obligations may grow above the time capabilities of the PMC and
committers such that when they eventually decide to try and bring the changes
in their fork back to the Apache Maven project their contribution may end up
being rejected on the basis of the review of a large set of changes being too
difficult/time-consuming.</p></div></div>
<div class="section">
<h3><a name="Project_Management_Chair"></a><a class="externalLink"
href="https://www.apache.org/foundation/how-it-works.html#pmc-chair";>Project
Management Chair</a></h3>
<p>For various legal reasons, there are certain things that the Apache
Software Foundation can only delegate to an officer of the foundation.</p>
<p>The Project Management Committee is responsible for nominating the lucky
victim who gets made an officer of the foundation (subject to the approval of
the board).</p>
<p>This person then becomes the interface between the board and the project
management committee. They do not have any other additional gravitas in the
project, it is the Project Management Committee as a whole that is responsible
for the direction of the project.</p>
-<p>If things break down and there is no consensus and there is no clear
ability to reach any conclusion <i>and</i> it is in the interest of the
foundation because damage is done and the board expects the chair to act as an
officier of the foundation and clean things up, then the chair can act as an
ultimate decision maker, however, by this point the board of the foundation
must already be well aware of the situation and should be actively monitoring
the chair.</p></div></div>
+<p>If things break down and there is no consensus and there is no clear
ability to reach any conclusion <i>and</i> it is in the interest of the
foundation because damage is done and the board expects the chair to act as an
officer of the foundation and clean things up, then the chair can act as an
ultimate decision maker, however, by this point the board of the foundation
must already be well aware of the situation and should be actively monitoring
the chair.</p></div></div>
</div>
</div>
</div>
Modified: maven/website/content/reference/maven-classloading.html
==============================================================================
--- maven/website/content/reference/maven-classloading.html (original)
+++ maven/website/content/reference/maven-classloading.html Thu Dec 20 11:01:46
2018
@@ -172,7 +172,7 @@
<h2><a name="Plugin_classloaders"></a>Plugin classloaders</h2>
<p>Plugin classloaders are wired differently for projects with and without
build extensions.</p>
<p>For projects without build extensions, single classloader is created for
each plugin identified by groupId:artifactId:version and the classloader
imports API packages from Maven API classloader. Maven will create one and only
one classloader for each unique plugin+dependency combination.</p>
-<p>For projects that use build extensions, plugin classloaders are wired to
project classloaders. This gives plugin code access to both Maven API packages
and packages exported by the project build extensions. Maven will create one
and only one classlaoder for each unique plugin+dependencies+buid-extensions
combination.</p>
+<p>For projects that use build extensions, plugin classloaders are wired to
project classloaders. This gives plugin code access to both Maven API packages
and packages exported by the project build extensions. Maven will create one
and only one classlaoder for each unique plugin+dependencies+build-extensions
combination.</p>
<p>All plugin classloaders use ClassWorlds bootstrap classloader as the
parent. This provides relatively clean and therefore consistent plugin
classpath, while still allowing plugins access to <tt>-javaagent</tt> classes
(see <a class="externalLink"
href="https://issues.apache.org/jira/browse/MNG-4747";>MNG-4747</a>).</p>
<p>Reporting plugins are wired differently still, but reporting plugins are a
special case and are outside of the scope of this document.</p></div>
<div class="section">
Modified: maven/website/content/run.html
==============================================================================
--- maven/website/content/run.html (original)
+++ maven/website/content/run.html Thu Dec 20 11:01:46 2018
@@ -193,7 +193,7 @@
<pre class="source">mvn checkstyle:check
</pre></div></div>
-<p>There are many different plugins avaiable and they all implement different
goals.</p>
+<p>There are many different plugins available and they all implement different
goals.</p>
<p>Further resources:</p>
<ul>
Modified: maven/website/content/security-plexus-archiver.html
==============================================================================
--- maven/website/content/security-plexus-archiver.html (original)
+++ maven/website/content/security-plexus-archiver.html Thu Dec 20 11:01:46 2018
@@ -153,7 +153,7 @@
<td><a class="externalLink"
href="https://issues.apache.org/jira/browse/MDEP-611";>MDEP-611</a></td>
-<td>unpack and unpack-dependencies goals (not used unless configured
explicitely)</td>
+<td>unpack and unpack-dependencies goals (not used unless configured
explicitly)</td>
</tr>
<tr class="a">
@@ -166,7 +166,7 @@
<td><a class="externalLink"
href="https://issues.apache.org/jira/browse/MEAR-268";>MEAR-268</a></td>
-<td>EAR <a href="/plugins/maven-ear-plugin/modules.html">modules</a> feature
(not used unless configured explicitely)</td>
+<td>EAR <a href="/plugins/maven-ear-plugin/modules.html">modules</a> feature
(not used unless configured explicitly)</td>
</tr>
<tr class="b">
@@ -179,7 +179,7 @@
<td><a class="externalLink"
href="https://issues.apache.org/jira/browse/MJAVADOC-520";>MJAVADOC-520</a></td>
-<td>resourcesArtifacts and includeDependencySources features (not used unless
configured explicitely)</td>
+<td>resourcesArtifacts and includeDependencySources features (not used unless
configured explicitly)</td>
</tr>
<tr class="a">
