Hello there,

I recently wrote in an internal blog article about failsafe vs. surefire:

"Maven defines lifecycles, each lifecycle is a sequence of well
defined phases[0].
Each phase executes bound goals, which are defined as so called Mojo
classes in Maven plugins. Lifecycles typically produce output:
* phase "clean" of lifecycle "clean" cleans your workspace of built
artifacts. Just call "mvn clean".
* phase "test" of lifecycle "default" compiles your sources and test
sources and runs your unit tests. Just call "mvn test".
* phase "deploy" of lifecycle "default" includes the phase "test" and
uploads your packaged artifacts to a binary repository. Just call "mvn
deploy".
* phase "site" of lifecycle "site" produces a standard documentation
site from your sources). Just call "mvn site".

The bound standard goals[1] of the the default lifecycle depend on the
type of your project. You may bind additional goals to each phase."

Probably this would mean a 120 seconds introduction :-).

[0] 
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference
[1] http://maven.apache.org/ref/3.1.1/maven-core/default-bindings.html
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Fri, Jan 3, 2014 at 6:19 PM, Ron Wheeler
<rwhee...@artifact-software.com> wrote:
> https://cwiki.apache.org/confluence/display/MAVEN/Tutorial%3A+Maven+in+60+seconds
> Still think that it is overly vague.
>
> It would be easier to understand if the passive voice was eliminated. Makes
> it clearer to understand what the developer has to do and what maven is
> going to do while processing the POM.
>
> The page should start with a statement saying that Maven builds artifacts
> based on information provided by the developer.
>
> You might want to talk about convention over configuration and how this
> compares to Make or Ant.
>
> "It all starts with a *project model"* ->"It all starts with a *project
> model* that you create to tell Maven how you want your project (artifact?)."
>
> /Note: reactor is just the name that Maven has given to the list of modules
> that are being built
> /Is module different than artifact? Are modules input or output?
> See below for confusion about whether a reactor is a list or a thing that
> does stuff./
> /
> The *packaging* of each module (artifact?) implies that modules are output -
> should provide example "such as jar, war, tar or zip" (90 percent of cases?)
>
> "The *dependencies* of each module" => "The dependencies that are required
> to build, test and run the resulting  project/module/artifact."
>
> "Any additional *plugins* that are needed to build each module" => "Any
> *plugins* that are needed to build each module."
>  What does additional mean to the new user?
> Perhaps a sentence about default plug-ins that Maven includes automatically
> might be useful but conceptually I don't think that the distinction is
> useful at this point
>
> "The lifecycle defines the default plugins that are used to build a specific
> packaging. "
> This is a bit startling to a new user even if it is correct.
> It might be better to describe the lifecycle in terms of steps rather than
> plug-ins.
> It might also be worth being explicit that lifecycles are defined in Maven
> not in the model.
>
> These next 2 sentences need to be rewritten in the active case saying that
> Maven does these things.
>
>
> "The list of modules in the reactor is sorted in order to ensure that any
> dependencies that will be created by the reactor will be built before they
> are needed by other modules in the reactor
> The *build plan* is then populated for each module using the lifecycle and
> the plugin information from the model"
>
> Build plan is not defined. Who creates it? What does it have in it before it
> is populated? How many build plan are there - one for each module?/ one for
> all?.
> Should say that a single build plan is created that builds the
> xxxx(components - no definition in the diagram of what the programmer has
> programmed) in the correct sequence.
>
> Maven then starts executing the build plan and building your project,
> downloading dependencies that are not produced by the reactor.
> A reactor was defined as a list of modules, now it is a thing that does
> produced dependencies.
>
> Final diagram is missing the output from the process.
> It seems to say that Maven builds "Build Plans"(square box).
> The developer wants an artifact out of this.
>
> I hope that this helps.
>
> Ron
>
>
>
>
> On 03/01/2014 11:33 AM, Stephen Connolly wrote:
>>
>> FYI here is my current plan for content:
>>
>> https://cwiki.apache.org/confluence/display/MAVEN/New+Main+Site
>>
>>
>> On 3 January 2014 16:27, Ron Wheeler <rwhee...@artifact-software.com
>> <mailto:rwhee...@artifact-software.com>> wrote:
>>
>>     I agree with Robert's comment.
>>     There is a danger that the page will become architecturally
>>     elegant and will correctly describe all of the possible uses of
>>     Maven but will be too obscure to be useful as a starting point for
>>     a new person.
>>
>>
>> I actually think that the page is near complete from my point of view...
>> the remaining content is actually to provide links to pages describing what
>> each individual concept is and a link to the next level of depth tutorial.
>>
>> I what to draw only the outline of what maven does... on the other hand,
>> if you can think of an alternative set of content I am only too happy to see
>> such suggestions. If you need write access to the wiki, shout out and I'll
>> make it so (assuming you are a regular user/dev list contributor)
>>
>>
>>     It is sufficiently difficult to understand the basic concepts in
>>     using Maven to create a simple jar with a single POM.
>>     You are introducing a lot of new concepts:
>>     -Lifecycle
>>     -Dependencies
>>     -Plug-ins
>>     - Project model
>>     that a person coming from make or Ant has to grasp.
>>
>>     Defining these and the relationships among them in a simple way is
>>     sufficiently challenging without trying to abstract a sufficiently
>>     general model to handle all of the edge cases.
>>
>>     The "Maven way" needs to be explained very simply rather than
>>     conceptually complete.
>>
>>     Ron
>>
>>
>>
>>     On 03/01/2014 11:09 AM, Robert Scholte wrote:
>>
>>         Op Fri, 03 Jan 2014 16:46:33 +0100 schreef Stephen Connolly
>>         <stephen.alan.conno...@gmail.com
>>         <mailto:stephen.alan.conno...@gmail.com>>:
>>
>>
>>             On 3 January 2014 15:17, Robert Scholte
>>             <rfscho...@apache.org <mailto:rfscho...@apache.org>> wrote:
>>
>>                 Hi,
>>
>>                 I like the idea of images, however I would avoid a
>>                 graph to make something
>>                 clear for new Maven users.
>>                 Instead I'd prefer a linear model.
>>
>>
>>             My first draft did not have the graph at the top...
>>             perhaps it would be
>>             better suited at the bottom ;-)
>>
>>
>>
>>                 I think you should split the current model into pieces:
>>
>>                 A project model contains:
>>                 - dependencies
>>                 - a build plan
>>                 - other project models ( you can call this the Droste
>>                 effect[1] )
>>
>>
>>             I like to think of the project model as not just the root
>>             pom.xml but all
>>             the pom.xml files, so there is only one project model,
>>             this should make
>>             understanding how -pl, -am and -amd switches have their
>>             effects
>>
>>
>>
>>         IMO these switches are way too detailed for a 60 sec tutorial.
>>         I even think that a large group of the average Maven users
>>         don't know these switches or use them.
>>
>>                 - ...
>>
>>                 There are several build-plans, namely: a build-plan
>>                 for jar, war, ear, etc.
>>                 Every build plan has a set of predefined plugins,
>>                  which you can adjust
>>                 (with switches?)
>>
>>
>>             No there is one and only one build plan. We would have to
>>             redefine build
>>             plan everywhere else to be able to use it like that. There
>>             is a lifecycle
>>             binding for each packaging
>>
>>
>>
>>         Then buildplan is too abstract. With a real world example: the
>>         buildplan for a house and a bike are completely different.
>>         Unless you say: you have a design, some goods, you mix those
>>         goods and you have your product.
>>         Not a useful plan IMO.
>>         At least keep the audience in mind: do they need to know the
>>         actual implementation or do they first need to understand the
>>         overall process. I think the latter is more important, even if
>>         this conflicts a bit with the idiom used by experienced Maven
>>         users.
>>         What if we call it "build instructions" (per packaging type) ?
>>
>>
>>                 Now, what does Maven do?
>>
>>                 Maven reads the build plan and executes it. Some steps
>>                 of the build plan
>>                 deliver products ( compiled classes, test results, a
>>                 package)
>>
>>                 I think the reactor might be confusing at this level.
>>
>>
>>             I want the 60sec tutorial to be the grand overview, the
>>             next tutorial is a
>>             5 minute one on how a .jar file gets built
>>
>>             Then you have a multi-module webapp tutorial at 10-15min
>>
>>             I want to reference all the core concepts from the 60
>>             second overview even
>>             if only briefly, that way people can come back to the
>>             short page and say
>>             "ahh yes that is where that fits in again"
>>
>>
>>
>>                 my 2 cents,
>>
>>                 Robert
>>
>>                 [1] http://en.wikipedia.org/wiki/Droste_effect
>>
>>
>>                 Op Fri, 03 Jan 2014 15:41:15 +0100 schreef Stephen
>>                 Connolly <
>>                 stephen.alan.conno...@gmail.com
>>                 <mailto:stephen.alan.conno...@gmail.com>>:
>>
>>
>>
>>                  Just in case it wasn't clear... I'm looking for
>>                 comments and feedback
>>
>>
>>
>>                     On 3 January 2014 14:35, Stephen Connolly
>>                     <stephen.alan.conno...@gmail.com
>>                     <mailto:stephen.alan.conno...@gmail.com>>wrote:
>>
>>
>>                      OK, so to start working on new content I created
>>                     some pages on the wiki:
>>
>>
>>                         The first page is a 60 seconds overview of
>>                         Maven's build process
>>
>>
>>                         https://cwiki.apache.org/confluence/display/MAVEN/
>>                         Tutorial:+Maven+in+60+seconds
>>
>>                         I am using icons because I want to have
>>                         subsequent pages give more detail
>>                         and use the iconography to enable people to
>>                         see what is being discussed
>>                         more easily
>>
>>
>>
>> ---------------------------------------------------------------------
>>         To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>         <mailto:users-unsubscr...@maven.apache.org>
>>
>>         For additional commands, e-mail: users-h...@maven.apache.org
>>         <mailto:users-h...@maven.apache.org>
>>
>>
>>
>>
>>
>>     --     Ron Wheeler
>>     President
>>     Artifact Software Inc
>>     email: rwhee...@artifact-software.com
>>     <mailto:rwhee...@artifact-software.com>
>>
>>     skype: ronaldmwheeler
>>     phone: 866-970-2435, ext 102
>>
>>
>>     ---------------------------------------------------------------------
>>     To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>     <mailto:users-unsubscr...@maven.apache.org>
>>
>>     For additional commands, e-mail: users-h...@maven.apache.org
>>     <mailto:users-h...@maven.apache.org>
>>
>>
>
>
> --
> 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

Reply via email to