maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Project Description Contest
Date Fri, 10 Jan 2014 16:23:54 GMT
On 10 January 2014 15:50, Ron Wheeler <rwheeler@artifact-software.com>wrote:

> On 10/01/2014 10:05 AM, Stephen Connolly wrote:
>
>> On 10 January 2014 14:01, Ron Wheeler <rwheeler@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.


I would link it from a FAQ page, not the front page... as understanding our
choice of metrics to compare on requires some understanding of Maven
first... otherwise a comparison that we think is fair to Maven will not be
well understood.


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

1. Don't preach to the reader... we should not tell them what to think

2. Don't speak ill of others

3. Don't assume that the reader cannot think for themselves.

I am not saying we put the onus on the reader to make the inference. This
could be the very first tool in this space that they have discovered.

We should state our philosophy... give links to explain what we mean in the
description, so that loaded terms can be understood by people who are
unfamiliar with them... and by all means lets give links to


> 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 am saying *no way* will we mention other build tools on the front page or
in the project description.


> I would save it for the comparison.


If we even need a comparison... but a comparison is not needed as much as a
rebrand of the initial RX (or reader experience)

Let's get the content needed to get a reader up and running and doing a few
builds quickly that they can develop a feel for the Maven way... again that
hits the theme of letting the reader find out - as quickly as we can let
them - whether they love maven or hate it.

The first level content should also hit things like the release plugin and
project documentation

The second level content should then be focused on more advanced things...

* deviating from the conventions

* writing simple plugins

* forging a new path for a new packaging type

The third level content, if we get that far, would be the more advanced
plugin writing stuff...

Only when we get that far should we start thinking about comparisons with
other tooling


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

Why would we want to put a flame war on our site?

I think in the FAQ we could have a "comparison to other tools" section with
things like

Q: "I just want to specify the exact steps that Maven should build, like I
can with Gradle. Why does Maven make this hard to do?"

Q: "I just want to keep my dependencies in source control like Ant lets me.
Why can't Maven use the dependencies that are in source control, forcing me
to run a repository manager just to host them?"

Such content sits best in a FAQ... but we should not knock these other
tools. They are just as valid at building software as Maven is... look at
the end result... the software is built.

>From our philosophy there is a big difference... there is a whole larger
layer of trade-offs that we see... and from our point of view once you see
the bigger picture that we see... well why would you use anything other
than Maven... *but* that does not make us _right_... it just makes us
self-consistent.




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

We don't know why somebody has landed on our front page... what we want to
do is get the people who don't want to be here to move on as fast as
possible so that they appreciate the fact that we have not wasted their
time.


> If they decide to use Ant, so be it.


Maven... you either love it or hate it... I am happy with that


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message