Re: Little documentation issues
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 rwhee...@artifact-software.com 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 thebuildpluginManagement//buildelements 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 thebuildpluginManagement//buildelement 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 aconfigurationelement where the child elements of theconfigurationelement 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
Re: Little documentation issues
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
On 17 December 2014 at 12:24, Ron Wheeler rwhee...@artifact-software.com 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, 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 baerr...@gmail.com wrote: On 17 December 2014 at 12:24, Ron Wheeler rwhee...@artifact-software.com 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
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
Little documentation issues
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 thebuildpluginManagement//buildelements 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 thebuildpluginManagement//buildelement 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 aconfigurationelement where the child elements of theconfigurationelement 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
Re: Little documentation issues
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 rwhee...@artifact-software.com 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 thebuildpluginManagement//buildelements 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 thebuildpluginManagement//buildelement 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 aconfigurationelement where the child elements of theconfigurationelement 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
Re: Little documentation issues
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 rwhee...@artifact-software.com 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 thebuildpluginManagement//buildelements 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 thebuildpluginManagement//buildelement 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 aconfigurationelement where the child elements of theconfigurationelement 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
Re: Little documentation issues
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 thebuildpluginManagement//buildelements 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 thebuildpluginManagement//buildelement 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 aconfigurationelement where the child elements of theconfigurationelement 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
Re: Little documentation issues
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
