You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2014/01/03 15:35:46 UTC
New site content
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
Re: New site content
Posted by Adam Retter <ad...@googlemail.com>.
It might be clearer to annotate the diagram, rather than have a
separate key table.
On 3 January 2014 14:41, Stephen Connolly
<st...@gmail.com> wrote:
> Just in case it wasn't clear... I'm looking for comments and feedback
>
>
> On 3 January 2014 14:35, Stephen Connolly
> <st...@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
>>
--
Adam Retter
skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: New site content
Posted by Ron Wheeler <rw...@artifact-software.com>.
"The *reactor* of modules that will be built when building your project"
From Wikipedia, the free encyclopedia
*Reactor* can mean:
In science
* Bioreactor <http://en.wikipedia.org/wiki/Bioreactor>, any device or
system that supports a biologically active environment.
* Chemical reactor <http://en.wikipedia.org/wiki/Chemical_reactor>, a
device for containing and controlling a chemical reaction
* Fusion reactor <http://en.wikipedia.org/wiki/Fusion_power>, a device
for containing and controlling a fusion power reaction
* An inductor <http://en.wikipedia.org/wiki/Inductor> (possessing
reactance <http://en.wikipedia.org/wiki/Electrical_reactance>) in an
electrical power grid
o A line reactor <http://en.wikipedia.org/wiki/Line_reactor> is
used to limit starting current of motors and to protect variable
frequency drives
* Nuclear reactor <http://en.wikipedia.org/wiki/Nuclear_reactor>, a
device for containing and controlling a nuclear reaction
* Reactor (Havok) <http://en.wikipedia.org/wiki/Reactor_%28Havok%29>,
a physics simulation engine
* The reactor pattern <http://en.wikipedia.org/wiki/Reactor_pattern>,
a design pattern used in concurrent programming
Probably needs a more detailed definition since "reactor" has many
meanings to people.
Not clear why this word was chosen or what is means in this context.
I guess that I have been building "reactors of modules" without knowing
what I am doing.
It might be helpful to mention the word "artifact".
The idea of a build producing a single artifact seems to be concept that
people miss when starting out.
You might want to label the arrows to explain the nature of the links
between the joined items.
Ron
On 03/01/2014 9:41 AM, Stephen Connolly wrote:
> Just in case it wasn't clear... I'm looking for comments and feedback
>
>
> On 3 January 2014 14:35, Stephen Connolly
> <st...@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
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: New site content
Posted by Stephen Connolly <st...@gmail.com>.
On 3 January 2014 16:09, Robert Scholte <rf...@apache.org> wrote:
> Op Fri, 03 Jan 2014 16:46:33 +0100 schreef Stephen Connolly <
> stephen.alan.connolly@gmail.com>:
>
>
> On 3 January 2014 15:17, Robert Scholte <rf...@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) ?
Well I have no issue with saying that each packaging has a template for how
when to use plugins during the lifecycle.
But the build plan is the plan of what will be done, and it is a well used
term in Maven.
The lifecycle is also a well used term in Maven.
This is the 20,000ft reference that lets people get to understand what
these terms are... I think it is OK for it to skim over the detail (we can
make the images be links to more detail as people need it), but I don't
believe we do anyone a service by avoiding introducing our core concepts...
especially if these core concepts and their poor understanding are part of
the root for the misuse and misunderstanding of maven by a large body of
people
>
>
>
>>> 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.connolly@gmail.com>:
>>>
>>>
>>> Just in case it wasn't clear... I'm looking for comments and feedback
>>>
>>>>
>>>>
>>>> On 3 January 2014 14:35, Stephen Connolly
>>>> <st...@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
>>>>>
>>>>>
Re: New site content
Posted by Mirko Friedenhagen <mf...@gmail.com>.
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
<rw...@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 <rwheeler@artifact-software.com
>> <ma...@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.connolly@gmail.com
>> <ma...@gmail.com>>:
>>
>>
>> On 3 January 2014 15:17, Robert Scholte
>> <rfscholte@apache.org <ma...@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.connolly@gmail.com
>> <ma...@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.connolly@gmail.com
>> <ma...@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-unsubscribe@maven.apache.org
>> <ma...@maven.apache.org>
>>
>> For additional commands, e-mail: users-help@maven.apache.org
>> <ma...@maven.apache.org>
>>
>>
>>
>>
>>
>> -- Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> <ma...@artifact-software.com>
>>
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> <ma...@maven.apache.org>
>>
>> For additional commands, e-mail: users-help@maven.apache.org
>> <ma...@maven.apache.org>
>>
>>
>
>
> --
> 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
Re: New site content
Posted by Ron Wheeler <rw...@artifact-software.com>.
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 <rwheeler@artifact-software.com
> <ma...@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.connolly@gmail.com
> <ma...@gmail.com>>:
>
> On 3 January 2014 15:17, Robert Scholte
> <rfscholte@apache.org <ma...@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.connolly@gmail.com
> <ma...@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.connolly@gmail.com
> <ma...@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-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
> <ma...@maven.apache.org>
>
>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> <ma...@artifact-software.com>
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
> <ma...@maven.apache.org>
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: New site content
Posted by Stephen Connolly <st...@gmail.com>.
Also, in case it is not clear, my preferred style is to tell you
information that is important later without distracting you by that
information
A case in point is the information that
> 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
I'd like a bit snappier text, so it might be that we say
> The list of modules in the reactor is sorted in order to ensure that
modules are built before they are referenced by other other modules in the
reactor
Or better yet, maybe just
> The list of modules in the reactor is sorted
Where "sorted" is a link to a page describing the sort order.
But the most important thing from my point of view is to empower people
with correct information so that if they have a maven command such as
$ mvn clean javadoc:javadoc javadoc:aggregate-jar deploy site-deploy -pl
foo -am
Once they understand Maven, they can come back to the 60 second page and
see that it has not lied to them and that it actually hinted at how you
might go about understanding exactly what will go on with that execution
i.e. there is a build plan for that execution... there are lifecycle phases
and plugin goals... the aggregator goal affects the build plan in the
reactor, etc
But *and this is the important bit* the page itself does not have to
explain such a complex use of maven.
*aside*
One of the most annoying things to me about learning chemistry is that it
is a constant case of being thought something and then at the next level
they pull the rug out from under you and say, oh but actually it's not like
that at all...
They start telling you about electron shells
Then they say, oh but it's Bohr shells
Then they say, oh but it's QM
Then you dig deeper and there are layers to QM
By the time I got my degree in Chemistry I had gone through about 6 layers
of analogies for how the hydrogen atom works:
1st year-3rd year school analogy
4th year-6th year school analogy
1st year Chemistry analogy
2nd year Chemistry analogy
3rd year Chemistry analogy
4th year Chemistry analogy
Worst of all is that each analogy showed the previous ones as being
hopelessly wrong in so many ways.
Now I am fine with explaining things simply until you need to know more,
but when that simply way is just plain wrong!
Newtonian mechanics is at least a very good approximation of relativity for
normal velocities, and if I remember correctly, when the velocities are
small with respect to the speed of light the newtonian solutions are
trivially shown to be a simplified approximation of the general
relativistic model.
But you cannot say the same of QM and the lies I was fed in school...
To bring this back home, I want our top level tutorial to be viewable as a
simplification of what goes on *without* lying to you, i.e. like newtonian
mechanics vs general relativity not like 1st year school chemistry vs 4th
year university chemistry
On 3 January 2014 16:33, Stephen Connolly
<st...@gmail.com>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 <rw...@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.connolly@gmail.com>:
>>>
>>> On 3 January 2014 15:17, Robert Scholte <rf...@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.connolly@gmail.com>:
>>>>>
>>>>>
>>>>> Just in case it wasn't clear... I'm looking for comments and feedback
>>>>>
>>>>>>
>>>>>>
>>>>>> On 3 January 2014 14:35, Stephen Connolly
>>>>>> <st...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>> --
>> 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
>>
>>
>
Re: New site content
Posted by Ron Wheeler <rw...@artifact-software.com>.
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 <rwheeler@artifact-software.com
> <ma...@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.connolly@gmail.com
> <ma...@gmail.com>>:
>
> On 3 January 2014 15:17, Robert Scholte
> <rfscholte@apache.org <ma...@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.connolly@gmail.com
> <ma...@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.connolly@gmail.com
> <ma...@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-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
> <ma...@maven.apache.org>
>
>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> <ma...@artifact-software.com>
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
> <ma...@maven.apache.org>
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: New site content
Posted by Stephen Connolly <st...@gmail.com>.
Also, in case it is not clear, my preferred style is to tell you
information that is important later without distracting you by that
information
A case in point is the information that
> 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
I'd like a bit snappier text, so it might be that we say
> The list of modules in the reactor is sorted in order to ensure that
modules are built before they are referenced by other other modules in the
reactor
Or better yet, maybe just
> The list of modules in the reactor is sorted
Where "sorted" is a link to a page describing the sort order.
But the most important thing from my point of view is to empower people
with correct information so that if they have a maven command such as
$ mvn clean javadoc:javadoc javadoc:aggregate-jar deploy site-deploy -pl
foo -am
Once they understand Maven, they can come back to the 60 second page and
see that it has not lied to them and that it actually hinted at how you
might go about understanding exactly what will go on with that execution
i.e. there is a build plan for that execution... there are lifecycle phases
and plugin goals... the aggregator goal affects the build plan in the
reactor, etc
But *and this is the important bit* the page itself does not have to
explain such a complex use of maven.
*aside*
One of the most annoying things to me about learning chemistry is that it
is a constant case of being thought something and then at the next level
they pull the rug out from under you and say, oh but actually it's not like
that at all...
They start telling you about electron shells
Then they say, oh but it's Bohr shells
Then they say, oh but it's QM
Then you dig deeper and there are layers to QM
By the time I got my degree in Chemistry I had gone through about 6 layers
of analogies for how the hydrogen atom works:
1st year-3rd year school analogy
4th year-6th year school analogy
1st year Chemistry analogy
2nd year Chemistry analogy
3rd year Chemistry analogy
4th year Chemistry analogy
Worst of all is that each analogy showed the previous ones as being
hopelessly wrong in so many ways.
Now I am fine with explaining things simply until you need to know more,
but when that simply way is just plain wrong!
Newtonian mechanics is at least a very good approximation of relativity for
normal velocities, and if I remember correctly, when the velocities are
small with respect to the speed of light the newtonian solutions are
trivially shown to be a simplified approximation of the general
relativistic model.
But you cannot say the same of QM and the lies I was fed in school...
To bring this back home, I want our top level tutorial to be viewable as a
simplification of what goes on *without* lying to you, i.e. like newtonian
mechanics vs general relativity not like 1st year school chemistry vs 4th
year university chemistry
On 3 January 2014 16:33, Stephen Connolly
<st...@gmail.com>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 <rw...@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.connolly@gmail.com>:
>>>
>>> On 3 January 2014 15:17, Robert Scholte <rf...@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.connolly@gmail.com>:
>>>>>
>>>>>
>>>>> Just in case it wasn't clear... I'm looking for comments and feedback
>>>>>
>>>>>>
>>>>>>
>>>>>> On 3 January 2014 14:35, Stephen Connolly
>>>>>> <st...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>> --
>> 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
>>
>>
>
Re: New site content
Posted by Stephen Connolly <st...@gmail.com>.
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 <rw...@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.connolly@gmail.com>:
>>
>> On 3 January 2014 15:17, Robert Scholte <rf...@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.connolly@gmail.com>:
>>>>
>>>>
>>>> Just in case it wasn't clear... I'm looking for comments and feedback
>>>>
>>>>>
>>>>>
>>>>> On 3 January 2014 14:35, Stephen Connolly
>>>>> <st...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> --
> 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
>
>
Re: New site content
Posted by Stephen Connolly <st...@gmail.com>.
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 <rw...@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.connolly@gmail.com>:
>>
>> On 3 January 2014 15:17, Robert Scholte <rf...@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.connolly@gmail.com>:
>>>>
>>>>
>>>> Just in case it wasn't clear... I'm looking for comments and feedback
>>>>
>>>>>
>>>>>
>>>>> On 3 January 2014 14:35, Stephen Connolly
>>>>> <st...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> --
> 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
>
>
Re: New site content
Posted by Ron Wheeler <rw...@artifact-software.com>.
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.
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
> <st...@gmail.com>:
>
>> On 3 January 2014 15:17, Robert Scholte <rf...@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.connolly@gmail.com>:
>>>
>>>
>>> Just in case it wasn't clear... I'm looking for comments and feedback
>>>>
>>>>
>>>> On 3 January 2014 14:35, Stephen Connolly
>>>> <st...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
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
Re: New site content
Posted by Stephen Connolly <st...@gmail.com>.
On 3 January 2014 16:09, Robert Scholte <rf...@apache.org> wrote:
> Op Fri, 03 Jan 2014 16:46:33 +0100 schreef Stephen Connolly <
> stephen.alan.connolly@gmail.com>:
>
>
> On 3 January 2014 15:17, Robert Scholte <rf...@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) ?
Well I have no issue with saying that each packaging has a template for how
when to use plugins during the lifecycle.
But the build plan is the plan of what will be done, and it is a well used
term in Maven.
The lifecycle is also a well used term in Maven.
This is the 20,000ft reference that lets people get to understand what
these terms are... I think it is OK for it to skim over the detail (we can
make the images be links to more detail as people need it), but I don't
believe we do anyone a service by avoiding introducing our core concepts...
especially if these core concepts and their poor understanding are part of
the root for the misuse and misunderstanding of maven by a large body of
people
>
>
>
>>> 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.connolly@gmail.com>:
>>>
>>>
>>> Just in case it wasn't clear... I'm looking for comments and feedback
>>>
>>>>
>>>>
>>>> On 3 January 2014 14:35, Stephen Connolly
>>>> <st...@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
>>>>>
>>>>>
Re: New site content
Posted by Robert Scholte <rf...@apache.org>.
Op Fri, 03 Jan 2014 16:46:33 +0100 schreef Stephen Connolly
<st...@gmail.com>:
> On 3 January 2014 15:17, Robert Scholte <rf...@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.connolly@gmail.com>:
>>
>>
>> Just in case it wasn't clear... I'm looking for comments and feedback
>>>
>>>
>>> On 3 January 2014 14:35, Stephen Connolly
>>> <st...@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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: New site content
Posted by Robert Scholte <rf...@apache.org>.
Op Fri, 03 Jan 2014 16:46:33 +0100 schreef Stephen Connolly
<st...@gmail.com>:
> On 3 January 2014 15:17, Robert Scholte <rf...@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.connolly@gmail.com>:
>>
>>
>> Just in case it wasn't clear... I'm looking for comments and feedback
>>>
>>>
>>> On 3 January 2014 14:35, Stephen Connolly
>>> <st...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: New site content
Posted by Stephen Connolly <st...@gmail.com>.
On 3 January 2014 15:17, Robert Scholte <rf...@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
> - ...
>
> 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
>
> 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.connolly@gmail.com>:
>
>
> Just in case it wasn't clear... I'm looking for comments and feedback
>>
>>
>> On 3 January 2014 14:35, Stephen Connolly
>> <st...@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
>>>
>>
Re: New site content
Posted by Stephen Connolly <st...@gmail.com>.
On 3 January 2014 15:17, Robert Scholte <rf...@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
> - ...
>
> 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
>
> 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.connolly@gmail.com>:
>
>
> Just in case it wasn't clear... I'm looking for comments and feedback
>>
>>
>> On 3 January 2014 14:35, Stephen Connolly
>> <st...@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
>>>
>>
Re: New site content
Posted by Robert Scholte <rf...@apache.org>.
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.
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] )
- ...
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?)
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.
my 2 cents,
Robert
[1] http://en.wikipedia.org/wiki/Droste_effect
Op Fri, 03 Jan 2014 15:41:15 +0100 schreef Stephen Connolly
<st...@gmail.com>:
> Just in case it wasn't clear... I'm looking for comments and feedback
>
>
> On 3 January 2014 14:35, Stephen Connolly
> <st...@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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: New site content
Posted by Robert Scholte <rf...@apache.org>.
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.
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] )
- ...
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?)
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.
my 2 cents,
Robert
[1] http://en.wikipedia.org/wiki/Droste_effect
Op Fri, 03 Jan 2014 15:41:15 +0100 schreef Stephen Connolly
<st...@gmail.com>:
> Just in case it wasn't clear... I'm looking for comments and feedback
>
>
> On 3 January 2014 14:35, Stephen Connolly
> <st...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: New site content
Posted by Adam Retter <ad...@googlemail.com>.
It might be clearer to annotate the diagram, rather than have a
separate key table.
On 3 January 2014 14:41, Stephen Connolly
<st...@gmail.com> wrote:
> Just in case it wasn't clear... I'm looking for comments and feedback
>
>
> On 3 January 2014 14:35, Stephen Connolly
> <st...@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
>>
--
Adam Retter
skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: New site content
Posted by Stephen Connolly <st...@gmail.com>.
Just in case it wasn't clear... I'm looking for comments and feedback
On 3 January 2014 14:35, Stephen Connolly
<st...@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
>
Re: New site content
Posted by Stephen Connolly <st...@gmail.com>.
Just in case it wasn't clear... I'm looking for comments and feedback
On 3 January 2014 14:35, Stephen Connolly
<st...@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
>