On 3 January 2014 16:09, Robert Scholte <[email protected]> wrote:
> Op Fri, 03 Jan 2014 16:46:33 +0100 schreef Stephen Connolly < > [email protected]>: > > > On 3 January 2014 15:17, Robert Scholte <[email protected]> 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 < >>> [email protected]>: >>> >>> >>> Just in case it wasn't clear... I'm looking for comments and feedback >>> >>>> >>>> >>>> On 3 January 2014 14:35, Stephen Connolly >>>> <[email protected]>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 >>>>> >>>>>
