On 10/01/2014 10:05 AM, Stephen Connolly wrote:
On 10 January 2014 14:01, Ron Wheeler <rwhee...@artifact-software.com>wrote:
If we are going to compare it to Ant or Gradle, it should be done in a way
that explains what Maven does not what it does not do.
Did you even read the sentence I had in bold?
Yes.
I think that I was agreeing with that sentiment.
*It is *not* our job to educate the reader about other build tools. Our
job is to educate the reader about Maven*.
The *reader* will be comparing Maven with Ant/Gradle/etc, so we need to
give them the *information* they need. We do not need to (and in my opinion
should not) mention Ant/Gradle/etc at all...
I still think that a product comparison page/chart is a useful way to
help a reader understand whether maven is a good choice in their
circumstance.
It should be on a separate page but could be linked from the front page.
To try and frame this better, consider a sentence like:
"Maven takes a philosophy that most builds can be categorised based on the
type of thing you are building and that there is a best way to build each
type of thing, so you tell Maven the type of thing that you want to build
rather than spelling out the exact build steps you want" (this specific is
not a sentence I am suggesting as it is too long winded... a snappier
version of this *could* be good though)
Good start on a second paragraph for the opening page.
It explains why Maven was built the way it was.
One has to read between the lines to understand the "what's in it for
me" but does hint at simplifying the build instructions through taking
advantage of common patterns based on the output to be created.
Perhaps if we focus on the benefits to this approach, we could add some
framing around what you wrote to come up with a solid second paragraph.
Allows a reader who is used to the spelling out exact build steps (e.g.
ANT/Make/etc) to identify one of the key differences in Maven's
philosophy...
Could be incorporated into the text above.
I am not sure that I would put the onus on the user to make the inference.
We should just state the benefits - simplification, standardization,
adherence to corporate/enterprise best practices - and how Maven/"Maven
way" achieves these (by taking advantage of commonality of build flow,
etc. as you stated above).
I am not sure that I would mention the other build tools specifically here.
I would save it for the comparison.
http://www.youtube.com/watch?v=hC_r-dC4PqA Marmite^H^H^H^H^Hven you either
love it or hate it!
We are not going to convince the people who hate Maven that they love it,
despite how ever much we provide a nice introduction or however much we
improve our documentation... (though the fence sitters are up for grabs ;-)
Just like no amount of waxing lyrical from the Marmite fans will convince
me that it tastes nice... as far as I am concerned it is vile... I would
rather starve to death than eat Marmite... but I can respect that some
people like it.
What we need to do is filter out the people who will hate Maven with as
little time of theirs wasted... that way they will say "Maven you either
love it or hate it" and move on, rather than spending hours ranting about
how Maven is wrong, they can instead recognise that Maven has picked a
different philosophy that is better for some people and worse for them.
I see this discussion as part of a flame war that can be buried deeper
in the site.
I think that we should assume that a person who is arriving on the front
page is coming looking for a solution not a range war.
If they decide to use Ant, so be it.
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
