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 <rwhee...@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 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 <packaging>. 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 >> the<build><pluginManagement/></build>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 that >> 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·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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org >
