Re: Little documentation issues

[James Green]

I've been wondering how to apply "explanations" to things. With ActiveMQ
and Camel I just edit the Confluence wiki. If I can issue a GitHub pull
request and see the change within a day or two that's fine.

On 9 December 2014 at 16:52, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
>
> Do you want to create some pull requests?
> https://github.com/apache/maven-site is the repo... we can take care of
> pulling those patches back to SVN, so no need to worry about that part ;-)
>
> On 9 December 2014 at 16:42, Ron Wheeler 
> wrote:
>
> > After using maven for 7+years, I decided that I finally knew enough about
> > 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 . Some of the valid
> packaging
> > 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 is
> > an example after the table of the Plexus. This discussion would be better
> > 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
> bind
> > 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
> known
> > concept in "A Build Phase is Made Up of Plugin Goals" which never defines
> > 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
> way
> > 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
> development
> > 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 recommended
> > the version of the each plugins used by the build is specified to
> guarantee
> > the reproducibility of the build.
> > A good practice is to specify them in
> theelements
> > for*each*build plugins (generally, you will define a 
> > element in a parent POM).  ->
> >  It is a good practice to specify the version in
> > theelement for*each*plugin. The
> >  element is generally specified in a parent POM so
> that
> > the same plugin version is use in all related projects.
> >
> > c) "Maven plugins (build and reporting) are configured by specifying
> > aelement where the child elements of
> > theelement 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·jo1
> > '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 on
> > the built-in plugins and plugins that are created for special tasks.
> >
> > Now that we have a new logo and persona, it is tim

Re: Little documentation issues

[Mirko Friedenhagen]

Barrie,

if I am not wrong you probably have it right ;-)

Regards
Mirko
-- 
Sent from my mobile
On Dec 17, 2014 3:46 AM, "Barrie Treloar"  wrote:

> On 17 December 2014 at 12:24, Ron Wheeler 
> wrote:
> >
> > One of the wonderful features about Maven is that no matter how long one
> > has been using it or how much one has studied Maven documentation , one
> > still feels the necessity of ending every assertion about how it works
> with
> > "(If I have that right.)" .
> >
> > I am so happy to not be alone!
>
>
> You are not the only one (If I have that right)
>

Re: Little documentation issues

[Barrie Treloar]

On 17 December 2014 at 12:24, Ron Wheeler 
wrote:
>
> One of the wonderful features about Maven is that no matter how long one
> has been using it or how much one has studied Maven documentation , one
> still feels the necessity of ending every assertion about how it works with
> "(If I have that right.)" .
>
> I am so happy to not be alone!


You are not the only one (If I have that right)

Re: Little documentation issues

[Ron Wheeler]

One of the wonderful features about Maven is that no matter how long one 
has been using it or how much one has studied Maven documentation , one 
still feels the necessity of ending every assertion about how it works 
with "(If I have that right.)" .


I am so happy to not be alone!

Ron

On 10/12/2014 10:48 AM, Mark H. Wood wrote:

Thinking about the developer's perspective a bit, I came up with some
suggestions but no actual language.

The developer is a person who wants to build units of software into
distributable products, so it's useful to talk briefly about
"lifecycle", "phase", "goal", "execution", and "artifact" in terms
familiar to such a person.  *Briefly* -- full details should be
linked.  This is simply to define terms which will then be used to map
the nature of "Maven plugin" to his experience.

A developer probably has a general notion of what a "plugin" is, so
what he needs is to know what a *Maven* plugin is: an assembly of Java
classes which provides additional concepts and behaviors that the
Maven framework can use in building your projects.  It can define
additional lifecycles and phases, and it provides goals that you may
bind to phases in order to perform additional work during the build.
There should be a link to how one creates a Maven plugin, elsewhere.

It may be well to mention at *this* point that much of Maven's
"built-in" behavior is actually provided by included plugins.  In this
way, one first learns what a Maven plugin is and then immediately sees
application of the concept through the lens of the knowledge one has
just gained.  Perhaps pick one common plugin as an example.

Someone noted that "goal" and "Mojo" are often used interchangeably,
but it may be good to mention here that "goal" is a named behavior and
"Mojo" is its implementation.  (If I have that right.)





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Little documentation issues

[Mark H. Wood]

Thinking about the developer's perspective a bit, I came up with some
suggestions but no actual language.

The developer is a person who wants to build units of software into
distributable products, so it's useful to talk briefly about
"lifecycle", "phase", "goal", "execution", and "artifact" in terms
familiar to such a person.  *Briefly* -- full details should be
linked.  This is simply to define terms which will then be used to map
the nature of "Maven plugin" to his experience.

A developer probably has a general notion of what a "plugin" is, so
what he needs is to know what a *Maven* plugin is: an assembly of Java
classes which provides additional concepts and behaviors that the
Maven framework can use in building your projects.  It can define
additional lifecycles and phases, and it provides goals that you may
bind to phases in order to perform additional work during the build.
There should be a link to how one creates a Maven plugin, elsewhere.

It may be well to mention at *this* point that much of Maven's
"built-in" behavior is actually provided by included plugins.  In this
way, one first learns what a Maven plugin is and then immediately sees
application of the concept through the lens of the knowledge one has
just gained.  Perhaps pick one common plugin as an example.

Someone noted that "goal" and "Mojo" are often used interchangeably,
but it may be good to mention here that "goal" is a named behavior and
"Mojo" is its implementation.  (If I have that right.)

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: Digital signature

Re: Little documentation issues

[Curtis Rueden]

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--plugin", where  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 "-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
.
Others need to be explicitly bound to the desired phase(s) as *executions*.
Some sophisticated plugins (such as the nar-maven-plugin
) even define new phases of
the lifecycle. Each plugin goal is implemented as a mojo
: 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 
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 about
>> 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 . Some of the valid packaging
>> 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 is
>> an example after the table of the Plexus. This discussion would be better
>> 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 bind
>> the following goals to build phases of the default lifecycle." a he

Re: Little documentation issues

[Ron Wheeler]

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 
about 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 . Some of the 
valid packaging 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 
is an example after the table of the Plexus. This discussion would be 
better 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 bind 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 known concept in "A Build Phase is Made Up of Plugin Goals" which 
never defines 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 
way 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 
development 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 
recommended  the version of the each plugins used by the build is 
specified to guarantee the reproducibility of the build.
A good practice is to specify them in 
theelements for*each*build plugins 
(generally, you will define a  element in a parent 
POM).  ->
 It is a good practice to specify the version in 
theelement for*each*plugin. The 
 element is generally specified in a parent POM so 
that the same plugin version is use in all related projects.


c) "Maven plugins (build and reporting) are configured by specifying 
aelement where the child elements of 
theelement 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·jo1
'mojo/
n

Re: Little documentation issues

[Stephen Connolly]

H that seems to have failed to sync since scratch that...


On 9 December 2014 at 16:52, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Do you want to create some pull requests?
> https://github.com/apache/maven-site is the repo... we can take care of
> pulling those patches back to SVN, so no need to worry about that part ;-)
>
> On 9 December 2014 at 16:42, Ron Wheeler 
> wrote:
>
>> After using maven for 7+years, I decided that I finally knew enough about
>> 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 . Some of the valid packaging
>> 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 is
>> an example after the table of the Plexus. This discussion would be better
>> 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 bind
>> 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 known
>> concept in "A Build Phase is Made Up of Plugin Goals" which never defines
>> 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 way
>> 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 development
>> 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 recommended
>> the version of the each plugins used by the build is specified to guarantee
>> the reproducibility of the build.
>> A good practice is to specify them in 
>> theelements
>> for*each*build plugins (generally, you will define a 
>> element in a parent POM).  ->
>>  It is a good practice to specify the version in
>> theelement for*each*plugin. The
>>  element is generally specified in a parent POM so that
>> the same plugin version is use in all related projects.
>>
>> c) "Maven plugins (build and reporting) are configured by specifying
>> aelement where the child elements of
>> theelement 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·jo1
>> '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 on
>> 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: rwhee...@artifact-software.com
>> skype: ronaldmwheel

Re: Little documentation issues

[Stephen Connolly]

Do you want to create some pull requests?
https://github.com/apache/maven-site is the repo... we can take care of
pulling those patches back to SVN, so no need to worry about that part ;-)

On 9 December 2014 at 16:42, Ron Wheeler 
wrote:

> After using maven for 7+years, I decided that I finally knew enough about
> 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 . Some of the valid packaging
> 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 is
> an example after the table of the Plexus. This discussion would be better
> 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 bind
> 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 known
> concept in "A Build Phase is Made Up of Plugin Goals" which never defines
> 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 way
> 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 development
> 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 recommended
> the version of the each plugins used by the build is specified to guarantee
> the reproducibility of the build.
> A good practice is to specify them in 
> theelements
> for*each*build plugins (generally, you will define a 
> element in a parent POM).  ->
>  It is a good practice to specify the version in
> theelement for*each*plugin. The
>  element is generally specified in a parent POM so that
> the same plugin version is use in all related projects.
>
> c) "Maven plugins (build and reporting) are configured by specifying
> aelement where the child elements of
> theelement 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·jo1
> '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 on
> 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: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>