Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of ctrueden.wisc@gmail.com
 designates 209.85.213.180 as permitted sender)
MIME-Version: 1.0
Sender: ctrueden.wisc@gmail.com
In-Reply-To: <5487545B.3010607@artifact-software.com>
References: <54872666.5090406@artifact-software.com>
 <5487545B.3010607@artifact-software.com>
From: Curtis Rueden <ctrueden@wisc.edu>
Date: Tue, 9 Dec 2014 15:52:21 -0600
Message-ID: 
 <CADN69ynhnAqKgeQzHPruVOjrrqXK2vWWjZEmKcjD4+qBZzz9zA@mail.gmail.com>
Subject: Re: Little documentation issues
To: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=001a11c316a29452ad0509cf902f

--001a11c316a29452ad0509cf902f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

> Can someone suggest a description of "plugin" and "Mojo" that is
> written from a developer's point of view but sufficiently close to the
> technical reality that it will not cause trouble when someone starts
> to read the Plugin Developer's sections.

Here's my first cut at it:

A *plugin* is an extension of Maven that provides additional behavior
during a build. Nearly every aspect of a Maven build is defined as plugins.
For example, the maven-compiler-plugin provides the logic needed to compile
Java classes from sources, and the maven-jar-plugin knows how to packages
those Java classes into JAR files.

Plugins that are part of the official Maven project are named according to
the pattern "maven-<foo>-plugin", where <foo> relates to the plugin's
purpose (e.g., "compiler" or "jar" as described above). Unofficial plugins,
such as those produced by the Codehaus project, are typically named
according to the pattern "<foo>-maven-plugin" to avoid any implication that
they are somehow official Maven(TM) products.

Every plugin consists of a collection of *goals*, each of which defines
specific behavior. Some goals automatically become part of the build when
the plugin is declared in your POM, injecting themselves at the appropriate
phase in the build's default lifecycle
<http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.=
html>.
Others need to be explicitly bound to the desired phase(s) as *executions*.
Some sophisticated plugins (such as the nar-maven-plugin
<https://github.com/maven-nar/nar-maven-plugin>) even define new phases of
the lifecycle. Each plugin goal is implemented as a mojo
<http://maven.apache.org/developers/mojo-api-specification.html>: a Java
class providing the code necessary to accomplish that specific goal. For
that reason, people sometimes use the terms "goal" and "mojo"
interchangeably.

The ecosystem of available plugins makes Maven an exceptionally versatile
and powerful tool for managing nearly every imaginable aspect of your
project's build process.

Regards,
Curtis

P.S. I disclaim all copyright interest in the above. Please use / steal /
edit / tear apart / throw away as you wish.


On Tue, Dec 9, 2014 at 1:58 PM, Ron Wheeler <rwheeler@artifact-software.com=
>
wrote:

> I have made some of the changes in the attached file.
>
> There is not much that can be done until the plugin definition is added.
> This definition will clarify a few things and may make it easier to fix
> some of the other things.
>
> There are sentences like this one:
> " The second way to add goals to phases is to configure plugins in your
> project. Plugins are artifacts that provide
>   goals to Maven."
> that is written from an odd point of view.
>
> If I am a Java developer, why would adding more goals be something that I
> want to do?
>
> Each entire sections should be written from a developers point of view.
> Rather than adding goals, I may want to perform some special processing
> during the build.
> This may require the configuration of additional plugins which in turn
> might get activated by invoking additional goals (or not).
> As a Java developer, I can not add goals unless the goals are part of the
> plugin and I would only add goals
> a) if the goals were not already in the standard maven build flow AND
> b) the goal is available in the plugin.
>
> I suspect that this is a common problem with the Introductory
> documentation that makes it hard for a Java developer to read.
>
> Can someone suggest a description of "plugin" and "Mojo" that is written
> from a developer's point of view but sufficiently close to the technical
> reality that it will not cause trouble when someone starts to read the
> Plugin Developer's sections.
>
> Ron
>
>
>
>
> On 09/12/2014 11:42 AM, Ron Wheeler wrote:
>
>> After using maven for 7+years, I decided that I finally knew enough abou=
t
>> it to read the docs.
>> I started here - http://maven.apache.org/guides/getting-started/index.
>> html - and this led to other pages.
>>
>> I have found some places where a little cleaning up might help new users=
.
>> There is one BIG issue and a few smaller ones.
>>
>> 1) http://maven.apache.org/guides/introduction/
>> introduction-to-the-lifecycle.html
>> 1a)
>>  "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 packagi=
ng
>> values are jar, war, ear and pom.
>> "
>> Could we have the full list here or a link to a page with the full list
>> of the "normal" ones?
>> Could we have a mention that plug-ins can provide new packaging. There i=
s
>> an example after the table of the Plexus. This discussion would be bette=
r
>> if held together rather than split up with a discussion of binding and a
>> table between the two parts of the story.
>>
>>
>> 1b) In the table following this line "Each packaging contains a list of
>> goals to bind to a particular phase. For example, thejarpackaging will b=
ind
>> the following goals to build phases of the default lifecycle." a heading
>> row would be nice.
>>
>> 1c)
>> Plugins are mentioned well before they are defined on the page. It would
>> be helpful to briefly describe what a plugin is before using it as a kno=
wn
>> concept in "A Build Phase is Made Up of Plugin Goals" which never define=
s
>> it before dropping "And this is done by declaring the plugin goals bound=
 to
>> those build phases."
>> 1d)
>> The definition of plug-in is obscure to say the least "Plugins are
>> artifacts that provide goals to Maven." Surely there must be a clearer w=
ay
>> to describe the concept of plugin.
>> This is one of the most important Maven concepts and this is a WTF
>> definition.
>>
>> 2) http://maven.apache.org/guides/getting-started/index.html
>>
>> 2a)How can Maven benefit my development process? -> How can Maven be of
>> benefit to my development process? -> How can Maven improve my developme=
nt
>> process?
>> More common  English usage although the current wording is not wrong
>> 2b) How do I use plug-ins? -> How do I use plugins?  no hyphen in
>> plug-in. Whoops plugin!
>>
>> 2c) How do I use plugins? has no description of what a plugin is.
>>
>> 3) http://maven.apache.org/guides/mini/guide-configuring-plugins.html
>>
>> 3a) No definition of what a plugin is; it just starts of with the
>> assertion that there are 2 types. I am not sure that that statement is
>> really true or if it is, it is not a very useful categorization.
>>
>> 3b) It is recommended to always defined each version of the plugins used
>> by the build to guarantee the build reproducibility. -> It is recommende=
d
>> the version of the each plugins used by the build is specified to guaran=
tee
>> the reproducibility of the build.
>> A good practice is to specify them in the<build><pluginManagement/></bui=
ld>elements
>> for*each*build plugins (generally, you will define a <pluginManagement/>
>> element in a parent POM).  ->
>>  It is a good practice to specify the version in
>> the<build><pluginManagement/></build>element for*each*plugin. The
>> <pluginManagement/> element is generally specified in a parent POM so th=
at
>> the same plugin version is use in all related projects.
>>
>> c) "Maven plugins (build and reporting) are configured by specifying
>> a<configuration>element where the child elements of
>> the<configuration>element are mapped to fields, or setters, inside your
>> Mojo (remember that a plug-in consists of one or more Mojos where a Mojo
>> maps to a goal). "
>> Remember!!!. This is the first time a Mojo has been mentioned. It has no
>> definition and if I look it up I get:
>>
>> "mo=C2=B7jo1
>> 'mojo/
>> nounUS
>> a magic charm, talisman, or spell.
>> "someone must have their mojo working over at the record company"
>> magic power.
>> synonyms:    magic, voodoo, hoodoo, wizardry, sorcery;
>> "
>>
>> No wonder my builds aren't working!
>>
>>
>>
>> Can these be fixed soon.
>>
>> Some of them are just little bugs but the lack of a clear definition and
>> discussion  of plugins at the beginning of the "Getting Started"
>> documentation is a really big oversight since so much of Maven depends o=
n
>> the built-in plugins and plugins that are created for special tasks.
>>
>> Now that we have a new logo and persona, it is time to fix the docs to
>> make them more accessible.
>>
>> Is there a chance that I may eventually understand Maven!
>>
>> Ron
>>
>>
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

--001a11c316a29452ad0509cf902f--