maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: Project Description Contest
Date Fri, 10 Jan 2014 15:50:46 GMT
On 10/01/2014 10:05 AM, Stephen Connolly wrote:
> On 10 January 2014 14:01, Ron Wheeler <>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?

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 
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.

> 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
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message