The Maven Way

[Wolf Geldmacher <wo...@abacus.ch>]

Hi list,

a simple question with (hopefully) a simple answer:

     Is there some coherent documentation of "the Maven way"?

I'm *not* looking for:
* documentation of the Maven syntax
* documentation of Maven plugins
* Maven reference documentation
* "Use the Source, Luke!" style of advice

What I'm looking for is:
* a collection of patterns / anti-patterns in the use of Maven,
* documentation on the "Do's and Dont's" when using Maven,
* documentation of the best practices implemented by Maven,
* documentation of basic assumptions in Maven.

I'm being bitten by gotcha's that spring up at inconvenient times
and *then* being told that I've strayed from "The Way"; I'd rather
follow some road signs upfront than find myself confronted with
scathing dogs in some lonely backyard that I happen to stumble into.

Something along the lines of Chapter 3.6 of "Maven: The Complete
Reference", which sets out to "... distill some of this knowledge to
help you adopt best practices from the start without having to wade
through years of discussions ..." but then, unfortunately, only covers
two (Dependency Grouping and Multi-module vs. Inheritance).
Similar to this, just much more complete and with some
background/rationale thrown in, if possible.

Pointers anyone?

Pretty please?

Regards,
Wolf


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Eric Kolotyluk <er...@gmail.com>]

On 2012-04-17 9:12 AM, Mark H. Wood wrote:
> On Tue, Apr 17, 2012 at 07:12:26AM -0700, Eric Kolotyluk wrote:
>> I also recommend taking the Sonatype training courses - especially if
>> you are a software architect.
>>
>> There is a lot to be said when you can ask question as the instructor is
>> going over the material.
>>
>> However, you are right, if someone were to write a book called the "The
>> Maven Way" in the style you suggest, I would certainly be interested in
>> buying a copy.
> You are not alone in that.  Especially since the most valuable single
> bit of advice one can give a new Maven user is:  "if you don't do
> things Maven's way, Maven will fight you and Maven will win."

THAT IS SOOOOO TRUE

>
> People extol the virtues of "convention over configuration", but where
> is the compact definitive specification of The Conventions?

I think it has something to do with Dawinism - if you can't adapt to 
Maven you die ;-)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

["Mark H. Wood" <mw...@IUPUI.Edu>]

On Thu, Apr 19, 2012 at 05:49:32PM +0200, martin.eisengardt wrote:
[snip]
> Please do think of the target audience before planning this type of
> documentation section. And do think of the way they are usually learning
> things. "The maven way" won't be a site full of plain explanations and
> documentations. It is focused on newbies and focused on teach them the
> right way. Some things are not mentioned and some things are not explained
> but linked to more detailed documents.
[good advice snipped]

Yes.  I would suggest that "the Maven Way" won't actually say much
about doing any specific thing with Maven, but will focus more on good
ways to think about and organize what you want to achieve, which map
well into Maven's capabilities and assumptions oops I mean
conventions.

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.

Re: The Maven Way

[Ron Wheeler <rw...@artifact-software.com>]

One of the things that I think would be helpful is a description of how 
to construct some common artifacts with Maven
- standalone java executable
- multi-module webapp for Tomcat and other containers
- webapp with CI integration

The handling of deployment  variables with JNDI or other means should be 
described in the context of deploying what you have tested.

Another big source of trouble is  people trying to use Maven without a repo.
There needs to be a discussion about the important role that repos play 
in building with Maven.
We used Maven for 2 for 2 years without a repo  and wasted a lot of time 
and energy.
I lot of the silliness that comes to the forum is from people that do 
not have a repo.

A brief discussion about the most common plug-ins would also be helpful.
I would not want to see all plug-ins treated as equal.
The common list should be restricted to 5 or less



These seem to be very common issues that newbees bring almost daily to 
the forum.
A lot of the discussion has to be about policy rather than Maven 
technical issues since most of the time the technical aspects of Maven 
are very easy to describe and are not the source of the problem.

Ron


On 19/04/2012 12:49 PM, Wolf Geldmacher wrote:
> Thank you all for the ideas & hints & the fruitful discussion and 
> special thanks to Eric for summing it up!
>
> I very much appreciate your time and efforts.
>
> Regards,
> Wolf
>
> Am 19.04.2012 17:15, schrieb Eric Kolotyluk:
>> After reading this thread and the embedded references I believe much 
>> of this information should be captured and added to 
>> http://maven.apache.org - in particular under "Learning About Maven" 
>> the very first topic should be "The Maven Way." As well, if you go to 
>> http://maven.apache.org/what-is-maven.html then one of the first 
>> things you should see is a link to "The Maven Way."
>>
>> Newbies in particular should be guided as soon as possible to this 
>> philosophical discussion about Maven, and how to best learn and 
>> master Maven, before anything else. People need to be clear about 
>> "Convention over Configuration" - they may not agree with the 
>> pattern, but it should be made clear to them that by embracing this 
>> pattern they will likely find Maven a much more satisfying experience.
>>
>> The surrounding text should catch the newbie's attention right away 
>> and guide them to this philosophical discussion with phrases like "If 
>> you are new to Maven please read 'The Maven Way' to get the most 
>> satisfying Maven experience." Maybe some humor is also appropriate "I 
>> fought Maven, and Maven won" - maybe we can revise the original Clash 
>> lyrics
>>
>> Pulling hair cause my build's not done
>> I fought Maven and Maven won [x2]
>> I need a break cause my build's not done
>> I fought Maven and Maven won [x2]
>>
>> I left my Ant and it feels so bad
>> Guess my build won't run
>> It's the best tool that I ever had
>> I fought Maven and Maven won
>> I fought Maven and
>>
>> Swear'n like a son of a gun
>> I fought Maven and Maven won [x2]
>> I miss my Ant and I miss my fun
>> I fought Maven and Maven won [x2]
>>
>> I left my Ant and it feels so bad
>> Guess my build won't run
>> It's the best tool that I ever had
>> I fought Maven and Maven won
>> I fought Maven and
>>
>> I fought Maven and Maven won [x7]
>> I fought Maven and
>>
>> Chad's article 
>> http://zeroinsertionforce.blogspot.ca/2012/04/maven-does-not-suck-but-maven-docs-do.html 
>> has some really valuable insight, especially about patterns. Too few 
>> people understand the importance of patterns - myself included - and 
>> we need to be reminded of this.
>>
>> Eric's insight 
>> http://www.catb.org/~esr/faqs/smart-questions.html#goal on how to ask 
>> questions is also valuable - to both the person trying to learn 
>> Maven, but more importantly to the people trying to document and 
>> explain Maven. In my own job we struggle with documenting our 
>> products because users often complain that our documentation is only 
>> a reference that is useful if you mostly know how to do something, 
>> but terrible at identifying common goals and the processes to achieve 
>> them.
>>
>> Many kudos to Barrie for taking the pragmatic step to open a JIRA 
>> issue on this.
>>
>> My own pet peeve with Maven is that when something goes wrong - the 
>> diagnostics you get can be exceedingly hard to fathom (especially for 
>> newbies) - and often very misleading to what the actual cause of the 
>> problem is. In many cases when I quoted the diagnostic messages on 
>> users@maven.apache.org I got back all kinds of bizarre answers and 
>> suggestions because other people also were mislead by the 
>> diagnostics. If someone is looking for an idea for a PhD or postdoc 
>> project - please build an "Intelligent System" to figure out why my 
>> Maven build is hosed and explain it to me with some meaningful 
>> diagnostics - even better - suggest possible fixes the way m2e does 
>> (but just better).
>>
>> This has been great discussion - thanks to all who participated :-)
>>
>> Special thanks to Wolf who got this discussion started.
>>
>> Cheers, Eric
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> 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

Re: The Maven Way

[Wolf Geldmacher <wo...@abacus.ch>]

Thank you all for the ideas & hints & the fruitful discussion and 
special thanks to Eric for summing it up!

I very much appreciate your time and efforts.

Regards,
Wolf

Am 19.04.2012 17:15, schrieb Eric Kolotyluk:
> After reading this thread and the embedded references I believe much 
> of this information should be captured and added to 
> http://maven.apache.org - in particular under "Learning About Maven" 
> the very first topic should be "The Maven Way." As well, if you go to 
> http://maven.apache.org/what-is-maven.html then one of the first 
> things you should see is a link to "The Maven Way."
>
> Newbies in particular should be guided as soon as possible to this 
> philosophical discussion about Maven, and how to best learn and master 
> Maven, before anything else. People need to be clear about "Convention 
> over Configuration" - they may not agree with the pattern, but it 
> should be made clear to them that by embracing this pattern they will 
> likely find Maven a much more satisfying experience.
>
> The surrounding text should catch the newbie's attention right away 
> and guide them to this philosophical discussion with phrases like "If 
> you are new to Maven please read 'The Maven Way' to get the most 
> satisfying Maven experience." Maybe some humor is also appropriate "I 
> fought Maven, and Maven won" - maybe we can revise the original Clash 
> lyrics
>
> Pulling hair cause my build's not done
> I fought Maven and Maven won [x2]
> I need a break cause my build's not done
> I fought Maven and Maven won [x2]
>
> I left my Ant and it feels so bad
> Guess my build won't run
> It's the best tool that I ever had
> I fought Maven and Maven won
> I fought Maven and
>
> Swear'n like a son of a gun
> I fought Maven and Maven won [x2]
> I miss my Ant and I miss my fun
> I fought Maven and Maven won [x2]
>
> I left my Ant and it feels so bad
> Guess my build won't run
> It's the best tool that I ever had
> I fought Maven and Maven won
> I fought Maven and
>
> I fought Maven and Maven won [x7]
> I fought Maven and
>
> Chad's article 
> http://zeroinsertionforce.blogspot.ca/2012/04/maven-does-not-suck-but-maven-docs-do.html 
> has some really valuable insight, especially about patterns. Too few 
> people understand the importance of patterns - myself included - and 
> we need to be reminded of this.
>
> Eric's insight http://www.catb.org/~esr/faqs/smart-questions.html#goal 
> on how to ask questions is also valuable - to both the person trying 
> to learn Maven, but more importantly to the people trying to document 
> and explain Maven. In my own job we struggle with documenting our 
> products because users often complain that our documentation is only a 
> reference that is useful if you mostly know how to do something, but 
> terrible at identifying common goals and the processes to achieve them.
>
> Many kudos to Barrie for taking the pragmatic step to open a JIRA 
> issue on this.
>
> My own pet peeve with Maven is that when something goes wrong - the 
> diagnostics you get can be exceedingly hard to fathom (especially for 
> newbies) - and often very misleading to what the actual cause of the 
> problem is. In many cases when I quoted the diagnostic messages on 
> users@maven.apache.org I got back all kinds of bizarre answers and 
> suggestions because other people also were mislead by the diagnostics. 
> If someone is looking for an idea for a PhD or postdoc project - 
> please build an "Intelligent System" to figure out why my Maven build 
> is hosed and explain it to me with some meaningful diagnostics - even 
> better - suggest possible fixes the way m2e does (but just better).
>
> This has been great discussion - thanks to all who participated :-)
>
> Special thanks to Wolf who got this discussion started.
>
> Cheers, Eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

["martin.eisengardt" <ma...@googlemail.com>]

Just my two cents.
I did not fully ready every post on this topic but the most of them. If
anyone mentioned it before please forgive me :)

Please do think of the target audience before planning this type of
documentation section. And do think of the way they are usually learning
things. "The maven way" won't be a site full of plain explanations and
documentations. It is focused on newbies and focused on teach them the
right way. Some things are not mentioned and some things are not explained
but linked to more detailed documents.

Let me tell some nice story. A friend of mine reviewed a project homepage.
What was the first thing he said? "Ugh - no screenshots". I told him that
there are not that many screenshots because I did not plan to simply
screenshot a windows CLI where maven prints "SUCCESS". I would not expect
it myself on a maven homepage. But after a while I began to think about it.
Why aren't there any screenshots in my documentation?

I do not think thousands of documentation variants are clever but pick up
two or three of them. A small example:
- "Video tutorial explaining the maven way"
- "Practical tutorial for maven java projects and the maven way"
- "Textual explanation of the maven way".
The first newbie likes videos, shares them at youtube and twitter. The
second newbie likes books (from sonatype). The third developer likes to
view at screenshots or "5-minute-cookbooks" without too many explanations
and tries to directly follow the tutorial instructions and play with maven
"live". etc.


Someone already said it (did not find the post, maybe I deleted it...) that
the maven homepages are mainly focused on plugin developers. The typical
newbie maybe a xxx developer (java or any other programming language we
have a plugin for). But the newbie is not the typical plugin developer. The
typical newbie does not need the detailed explanation of how to control the
Jvm parameters of JUnit invocations. He will indeed need it after some
weeks or as soon as running into trouble because of OutOfMemory.

Re: The Maven Way

[Eric Kolotyluk <er...@gmail.com>]

After reading this thread and the embedded references I believe much of 
this information should be captured and added to http://maven.apache.org 
- in particular under "Learning About Maven" the very first topic should 
be "The Maven Way." As well, if you go to 
http://maven.apache.org/what-is-maven.html then one of the first things 
you should see is a link to "The Maven Way."

Newbies in particular should be guided as soon as possible to this 
philosophical discussion about Maven, and how to best learn and master 
Maven, before anything else. People need to be clear about "Convention 
over Configuration" - they may not agree with the pattern, but it should 
be made clear to them that by embracing this pattern they will likely 
find Maven a much more satisfying experience.

The surrounding text should catch the newbie's attention right away and 
guide them to this philosophical discussion with phrases like "If you 
are new to Maven please read 'The Maven Way' to get the most satisfying 
Maven experience." Maybe some humor is also appropriate "I fought Maven, 
and Maven won" - maybe we can revise the original Clash lyrics

Pulling hair cause my build's not done
I fought Maven and Maven won [x2]
I need a break cause my build's not done
I fought Maven and Maven won [x2]

I left my Ant and it feels so bad
Guess my build won't run
It's the best tool that I ever had
I fought Maven and Maven won
I fought Maven and

Swear'n like a son of a gun
I fought Maven and Maven won [x2]
I miss my Ant and I miss my fun
I fought Maven and Maven won [x2]

I left my Ant and it feels so bad
Guess my build won't run
It's the best tool that I ever had
I fought Maven and Maven won
I fought Maven and

I fought Maven and Maven won [x7]
I fought Maven and

Chad's article 
http://zeroinsertionforce.blogspot.ca/2012/04/maven-does-not-suck-but-maven-docs-do.html 
has some really valuable insight, especially about patterns. Too few 
people understand the importance of patterns - myself included - and we 
need to be reminded of this.

Eric's insight http://www.catb.org/~esr/faqs/smart-questions.html#goal 
on how to ask questions is also valuable - to both the person trying to 
learn Maven, but more importantly to the people trying to document and 
explain Maven. In my own job we struggle with documenting our products 
because users often complain that our documentation is only a reference 
that is useful if you mostly know how to do something, but terrible at 
identifying common goals and the processes to achieve them.

Many kudos to Barrie for taking the pragmatic step to open a JIRA issue 
on this.

My own pet peeve with Maven is that when something goes wrong - the 
diagnostics you get can be exceedingly hard to fathom (especially for 
newbies) - and often very misleading to what the actual cause of the 
problem is. In many cases when I quoted the diagnostic messages on 
users@maven.apache.org I got back all kinds of bizarre answers and 
suggestions because other people also were mislead by the diagnostics. 
If someone is looking for an idea for a PhD or postdoc project - please 
build an "Intelligent System" to figure out why my Maven build is hosed 
and explain it to me with some meaningful diagnostics - even better - 
suggest possible fixes the way m2e does (but just better).

This has been great discussion - thanks to all who participated :-)

Special thanks to Wolf who got this discussion started.

Cheers, Eric

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Barrie Treloar <ba...@gmail.com>]

On Thu, Apr 19, 2012 at 9:02 AM, Barrie Treloar <ba...@gmail.com> wrote:
>> Part of the reason, I believe, is because those "conventions" are not carved in stone.  There often isn't a hard and fast convention that says when to make a profile or when to make a module or when to use a classifier to store a second artifact alongside the primary
>
> And over time these conventions (or philosophies) change as we gain
> more experience.

Added this into JIRA https://jira.codehaus.org/browse/MNG-5277

If you are tracking the dev list as well it should pop up in the
weekly [jira] Subscription: Design & Best Practices email.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Barrie Treloar <ba...@gmail.com>]

> Part of the reason, I believe, is because those "conventions" are not carved in stone.  There often isn't a hard and fast convention that says when to make a profile or when to make a module or when to use a classifier to store a second artifact alongside the primary

And over time these conventions (or philosophies) change as we gain
more experience.
There is stuff you can do in profiles that is considered exceptionally
bad practice.

There is some move at apache to get the web sites onto some CMS system.
I really don't know the details.  I think at the moment it can be backed by SVN.
This may make it easier for people to make changes without having to
checkout the website first, etc.  So the barrier to creating some of
this great advice may become lower.

I think another reason that the information isn't available is that
people don't recognise what is wrong with their mental model and when
they have that "aha" moment can no longer articulate how they went
from the wrong to correct mental model to explain to other people.
And there is less incentive to do so because they "know it now".

You only have to look at all the threads on the internet that have a
question, answers from other people, and either no response from the
original poster to say whether they worked or they reply with "thanks,
works now" with no bloody details!

I know that in six months time I will eventually be revisiting this
piece of knowledge so I try to ensure it gets put back on the internet
somewhere for google to find.  Because I can guarantee I will be
searching for it again at some later point.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: The Maven Way

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

> But yes, documentation about this could be much better. But as someone
> very correctly pointed out, there is very likely is a reason for the
> lack of this. It's all open source and contributions are gladly
> accepted. Even the Sonatype's book are open source (well, "Creative
> Commons Attribution, Non-Commercial, No Derivative Works 3.0 United
> States license"). If you have suggestions, additions, or whatever,
> file an enhancement ticket and it will be appreciated and most likely
> added. Some people do this, but there is always more that can be done
> and we can all participate.
> 
> /Anders

One of the reasons why I think no one has stepped up, or the community at large hasn't stepped up, to create good Maven documentation about its conventions is because it is a extremely daunting task.  And I have been thinking about why.

Part of the reason, I believe, is because those "conventions" are not carved in stone.  There often isn't a hard and fast convention that says when to make a profile or when to make a module or when to use a classifier to store a second artifact alongside the primary. When I see a question asked here on this list, often the reply to that question is "what are you trying to do?  Why are you asking this question you are asking?"

There are general motherhood statements you can make about Maven's conventions.  For example, a statement like "Maven is designed for build portability. Use caution when creating a profile as this can make your build non-portable." The best way to explain how, from here, is by example.  And you'll never be able to capture all scenarios which explain when to create a profile and how to go about doing it. It is too situational.

The fact that the conventions are not carved in stone, and is a daunting task to document, I think is GOOD. It has created an ecosystem which does not become stagnant, but instead thrives off the ideas of the community.  What can or cannot be done using Maven is constantly changing and the answer differs depending on who you ask.

I almost think a better mantra for maven is "philosophy over configuration" instead of "convention over configuration".

To be honest, I actually never did have trouble first getting into Maven. In fact, I found it quite refreshing. What got me in the right mind set was this:

http://maven.apache.org/what-is-maven.html

Then, what solidified it for me was understanding the lifecycle by digesting this here:

http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

So my recommendation to anyone trying maven for the first time is to read the "what is maven" link.  Then think about it, come back, and read it again.  You need to get out of the mind set of whatever build tool you were using because when you move to maven, you are getting much more than just a build tool.

In all honesty, I don't think we will ever have that one document which explains what all of Maven's convention's are. Now, don't get me wrong. This doesn't mean we shouldn't aim for having that, as there is a lot of room for improved documentation. But I also think we need to set our expectations about what is reasonable to achieve.

Todd

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Anders Hammar <an...@hammar.net>]

One thing I would like to add to this discussion is that, in my
experience, a lot of "Maven users" don't understand that Maven is not
only about building but also about producing something that can be
consumed from a repository. One part of what we often call "Maven" is
the build tool, but a much more important part is having consumable
artifacts in a repo. So, IMHO, I doesn't really matter if you can
build something if it can't be consumed by other people. Doing
"clever" solutions like producing multiple artifacts from one Maven
project most often makes them hard (or even impossible) do consume
from a repo in a correct way.

But yes, documentation about this could be much better. But as someone
very correctly pointed out, there is very likely is a reason for the
lack of this. It's all open source and contributions are gladly
accepted. Even the Sonatype's book are open source (well, "Creative
Commons Attribution, Non-Commercial, No Derivative Works 3.0 United
States license"). If you have suggestions, additions, or whatever,
file an enhancement ticket and it will be appreciated and most likely
added. Some people do this, but there is always more that can be done
and we can all participate.

/Anders

On Wed, Apr 18, 2012 at 02:00, Graham Leggett <mi...@sharp.fm> wrote:
> On 18 Apr 2012, at 1:44 AM, Eric Kolotyluk wrote:
>
>> Often the wrong foot is simply not knowing how much Maven does for your for free - because it is not obvious - especially when compared to tools like Ant. When the free stuff is not obvious, we naively start trying to solve problems we do not have to.
>
> The way I describe this is by getting people to ask the right question:
>
> Wrong question: "How do I do X?"
> Right question: "Does does maven do X?"
>
> Maven already knows how to do stuff. Find out how maven does it, and let maven get on with the job. As soon as you want maven to work your way, and not maven's way, expect to have loads of your time wasted, and the time of everyone after you too.
>
> The next thing is that maven isn't an alternative to ant, rather maven is an alternative to ant's build.xml file. Or to put it another way, maven does what build.xml does. build.xml gets written, rewritten and rewritten again for every single ant project, but there is only one maven. I have to care how your build.xml is different to my build.xml, I have to document how your build.xml is different to my build.xml, but if we both used maven, all this becomes unnecessary, because there is only one maven.
>
> Regards,
> Graham
> --
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Graham Leggett <mi...@sharp.fm>]

On 18 Apr 2012, at 1:44 AM, Eric Kolotyluk wrote:

> Often the wrong foot is simply not knowing how much Maven does for your for free - because it is not obvious - especially when compared to tools like Ant. When the free stuff is not obvious, we naively start trying to solve problems we do not have to.

The way I describe this is by getting people to ask the right question:

Wrong question: "How do I do X?"
Right question: "Does does maven do X?"

Maven already knows how to do stuff. Find out how maven does it, and let maven get on with the job. As soon as you want maven to work your way, and not maven's way, expect to have loads of your time wasted, and the time of everyone after you too.

The next thing is that maven isn't an alternative to ant, rather maven is an alternative to ant's build.xml file. Or to put it another way, maven does what build.xml does. build.xml gets written, rewritten and rewritten again for every single ant project, but there is only one maven. I have to care how your build.xml is different to my build.xml, I have to document how your build.xml is different to my build.xml, but if we both used maven, all this becomes unnecessary, because there is only one maven.

Regards,
Graham
--

Re: The Maven Way

[Eric Kolotyluk <er...@gmail.com>]

On 2012-04-17 11:53 AM, Ron Wheeler wrote:
> As the most frequent author of the 2 comments mentioned below, I will 
> agree and disagree with Curtis' observations.
>
> He is right that Maven is very powerful and flexible.
> It is possible to make it do all kinds of interesting and useful things.
>
> However, it is also very easy when starting with Maven, to get into 
> patterns based on experience with previous build tools, that make 
> simple tasks much more difficult.

That last sentence should be in bold face.

>
> It frequently appears from the person's statement that they "are just 
> starting with Maven" and from the brief description of their problem 
> that they are building a fairly common type of application that can be 
> built very easily by Maven with a relatively simple POM and project 
> structure.
>
> However, they have gotten off on the "wrong" foot and are trying to 
> bend Maven to their will or as Curtis might say "exploit the full 
> power and flexibility of Maven".

Often the wrong foot is simply not knowing how much Maven does for your 
for free - because it is not obvious - especially when compared to tools 
like Ant. When the free stuff is not obvious, we naively start trying to 
solve problems we do not have to.

>
> I usually quote the offending phrases around "fighting Maven" and 
> "profiles are evil" in an attempt to get them to reexamine their 
> strategy and see if their project does follow one of the more common 
> patterns (webapp, standalone executable, etc.) that Maven can handle 
> very simply.
>
> I will admit that I am not often the source of detailed technical 
> information in these cases since I do not usually know how to do what 
> they are doing and
> I am also pretty suspicious that the help that they want is not in 
> their best interest.
>
> One of the dangers in this forum is that there are bunch of guys here 
> who are very, very smart and very knowledgeable about Maven and can 
> patch up a really bad Maven approach into something that will work.
> If you ask the wrong question, you may get the right answer which will 
> help you get further out of your depth.
>
> One of the problems with documentation is that it often describes 
> everything that you can do without pointing out that some of these 
> things should only be used in rare circumstances and should only be 
> considered after you have exhausted the normal features and patterns.
> Sometimes the examples demonstrate the power of the feature rather 
> than the most common use which is considered to be too simple to be 
> worth showing and does not show the full elegnce of the feature.
>
> Another problem that new users face is the reluctance to make big 
> changes in their project structures or development methodology until 
> they are sure that Maven is the way to go.
> This is understandable and my goal is to get them to understand that a 
> little up front investment in conforming to convention may generate a 
> short-term return when compared to trying to get a build process in 
> place that follows their existing practice.
> I hope that my comments also give a sense of optimism that what they 
> want to do is possible with Maven and that the forum is here to help 
> them.
>
> Ron
>
>
> On 17/04/2012 12:48 PM, Curtis Rueden wrote:
>> Hi everyone,
>>
>>
>> Especially since the most valuable single
>>> bit of advice one can give a new Maven user is: "if you don't do
>>> things Maven's way, Maven will fight you and Maven will win."
>>>
>> I disagree that it is the "most valuable single bit of advice." It is
>> repeated far too frequently, often in cases where there *is* a 
>> reasonable
>> technical answer to the question being asked.
>>
>> Maven is much more flexible than many give it credit for. You can write
>> your own plugins to do nearly anything, or invoke Ant with AntRun if you
>> have existing Ant-based builds. Even conventions like "one project = one
>> JAR" are not universally true—the assembly plugin lets you do all 
>> kinds of
>> nifty stuff including building multiple artifacts as part of the same
>> project. People complain about the nested "src/main/java" directory
>> structure but you don't even need that; it is actually really easy to
>> override the source and resource directories in the great majority of
>> cases. People complain about profiles being "evil" but they are an
>> extremely powerful tool, and like any powerful tool are only as 
>> "good" or
>> "evil" as their use.
>>
>> I think it is great to caution people against anti-patterns, etc., 
>> pointing
>> out how they could make their lives easier by structuring things
>> differently. But if we are not careful, such advice can degenerate into
>> nonconstructive criticism, as illustrated by the unfortunate saying: 
>> "Don't
>> fight against Maven, you'll loose [sic]." This attitude causes real
>> problems within the developer community: at least one of the teams with
>> which I collaborate dislikes Maven due to its "our way or the highway"
>> attitude.
>>
>> Maven is an extremely powerful set of building blocks, and I think we
>> should be focusing on promoting that power and flexibility, rather than
>> criticizing anyone who tries to use Maven in an unconventional way. 
>> After
>> all, the beauty of "convention over configuration" is that you *can*
>> configure and override behavior as needed.
>>
>>
>> People extol the virtues of "convention over configuration", but where
>>> is the compact definitive specification of The Conventions?
>>>
>> I think one major difficulty is that as Maven develops, there is an
>> evolving vision and understanding of what works well and what 
>> doesn't. And
>> that is OK, and will continue to be the case. That said, someone could
>> probably make some good money writing a book about the current vision 
>> and
>> understanding, as well as updating it with new editions over time. :-)
>>
>> Regards,
>> Curtis
>>
>>
>> On Tue, Apr 17, 2012 at 11:12 AM, Mark H. Wood<mw...@iupui.edu> wrote:
>>
>>> On Tue, Apr 17, 2012 at 07:12:26AM -0700, Eric Kolotyluk wrote:
>>>> I also recommend taking the Sonatype training courses - especially if
>>>> you are a software architect.
>>>>
>>>> There is a lot to be said when you can ask question as the 
>>>> instructor is
>>>> going over the material.
>>>>
>>>> However, you are right, if someone were to write a book called the 
>>>> "The
>>>> Maven Way" in the style you suggest, I would certainly be 
>>>> interested in
>>>> buying a copy.
>>> You are not alone in that. Especially since the most valuable single
>>> bit of advice one can give a new Maven user is: "if you don't do
>>> things Maven's way, Maven will fight you and Maven will win."
>>>
>>> People extol the virtues of "convention over configuration", but where
>>> is the compact definitive specification of The Conventions?
>>>
>>> -- 
>>> Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
>>> What is obvious to A may be not so obvious to B and downright
>>> ridiculous to C. -- Asimov
>>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Ron Wheeler <rw...@artifact-software.com>]

As the most frequent author of the 2 comments mentioned below, I will 
agree and disagree with Curtis' observations.

He is right that Maven is very powerful and flexible.
It is possible to make it do all kinds of interesting and useful things.

However, it is also very easy when starting with Maven, to get into 
patterns based on experience with previous build tools, that make simple 
tasks much more difficult.

It frequently appears from the person's statement that they "are just 
starting with Maven" and from the brief description of their problem 
that they are building a fairly common type of application that can be 
built very easily by Maven with a relatively simple POM and project 
structure.

However, they have gotten off on the "wrong" foot and are trying to bend 
Maven to their will or as Curtis might say "exploit the full power and 
flexibility of Maven".

I usually quote the offending phrases around "fighting Maven" and 
"profiles are evil" in an attempt to get them to reexamine their 
strategy and see if their project does follow one of the more common 
patterns (webapp, standalone executable, etc.) that Maven can handle 
very simply.

I will admit that I am not often the source of detailed technical 
information in these cases since I do not usually know how to do what 
they are doing and
I am also pretty suspicious that the help that they want is not in their 
best interest.

One of the dangers in this forum is that there are bunch of guys here 
who are very, very smart and very knowledgeable about Maven and can 
patch up a really bad Maven approach into something that will work.
If you ask the wrong question, you may get the right answer which will 
help you get further out of your depth.

One of the problems with documentation is that it often describes 
everything that you can do without pointing out that some of these 
things should only be used in rare circumstances and should only be 
considered after you have exhausted the normal features and patterns.
Sometimes the examples demonstrate the power of the feature rather than 
the most common use which is considered to be too simple to be worth 
showing and does not show the full elegnce of the feature.

Another problem that new users face is the reluctance to make big 
changes in their project structures or development methodology until 
they are sure that Maven is the way to go.
This is understandable and my goal is to get them to understand that a 
little up front investment in conforming to convention may generate a 
short-term return when compared to trying to get a build process in 
place that follows their existing practice.
I hope that my comments also give a sense of optimism that what they 
want to do is possible with Maven and that the forum is here to help them.

Ron


On 17/04/2012 12:48 PM, Curtis Rueden wrote:
> Hi everyone,
>
>
> Especially since the most valuable single
>> bit of advice one can give a new Maven user is:  "if you don't do
>> things Maven's way, Maven will fight you and Maven will win."
>>
> I disagree that it is the "most valuable single bit of advice." It is
> repeated far too frequently, often in cases where there *is* a reasonable
> technical answer to the question being asked.
>
> Maven is much more flexible than many give it credit for. You can write
> your own plugins to do nearly anything, or invoke Ant with AntRun if you
> have existing Ant-based builds. Even conventions like "one project = one
> JAR" are not universally true—the assembly plugin lets you do all kinds of
> nifty stuff including building multiple artifacts as part of the same
> project. People complain about the nested "src/main/java" directory
> structure but you don't even need that; it is actually really easy to
> override the source and resource directories in the great majority of
> cases. People complain about profiles being "evil" but they are an
> extremely powerful tool, and like any powerful tool are only as "good" or
> "evil" as their use.
>
> I think it is great to caution people against anti-patterns, etc., pointing
> out how they could make their lives easier by structuring things
> differently. But if we are not careful, such advice can degenerate into
> nonconstructive criticism, as illustrated by the unfortunate saying: "Don't
> fight against Maven, you'll loose [sic]." This attitude causes real
> problems within the developer community: at least one of the teams with
> which I collaborate dislikes Maven due to its "our way or the highway"
> attitude.
>
> Maven is an extremely powerful set of building blocks, and I think we
> should be focusing on promoting that power and flexibility, rather than
> criticizing anyone who tries to use Maven in an unconventional way. After
> all, the beauty of "convention over configuration" is that you *can*
> configure and override behavior as needed.
>
>
> People extol the virtues of "convention over configuration", but where
>> is the compact definitive specification of The Conventions?
>>
> I think one major difficulty is that as Maven develops, there is an
> evolving vision and understanding of what works well and what doesn't. And
> that is OK, and will continue to be the case. That said, someone could
> probably make some good money writing a book about the current vision and
> understanding, as well as updating it with new editions over time. :-)
>
> Regards,
> Curtis
>
>
> On Tue, Apr 17, 2012 at 11:12 AM, Mark H. Wood<mw...@iupui.edu>  wrote:
>
>> On Tue, Apr 17, 2012 at 07:12:26AM -0700, Eric Kolotyluk wrote:
>>> I also recommend taking the Sonatype training courses - especially if
>>> you are a software architect.
>>>
>>> There is a lot to be said when you can ask question as the instructor is
>>> going over the material.
>>>
>>> However, you are right, if someone were to write a book called the "The
>>> Maven Way" in the style you suggest, I would certainly be interested in
>>> buying a copy.
>> You are not alone in that.  Especially since the most valuable single
>> bit of advice one can give a new Maven user is:  "if you don't do
>> things Maven's way, Maven will fight you and Maven will win."
>>
>> People extol the virtues of "convention over configuration", but where
>> is the compact definitive specification of The Conventions?
>>
>> --
>> Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
>> What is obvious to A may be not so obvious to B and downright
>> ridiculous to C. -- Asimov
>>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: The Maven Way

[Hilco Wijbenga <hi...@gmail.com>]

On 17 April 2012 09:48, Curtis Rueden <ct...@wisc.edu> wrote:
> Hi everyone,
>
> Especially since the most valuable single
>> bit of advice one can give a new Maven user is:  "if you don't do
>> things Maven's way, Maven will fight you and Maven will win."
>
> I disagree that it is the "most valuable single bit of advice." It is
> repeated far too frequently, often in cases where there *is* a reasonable
> technical answer to the question being asked.
>
> Maven is much more flexible than many give it credit for. You can write
> your own plugins to do nearly anything, or invoke Ant with AntRun if you
> have existing Ant-based builds. Even conventions like "one project = one
> JAR" are not universally true—the assembly plugin lets you do all kinds of
> nifty stuff including building multiple artifacts as part of the same
> project. People complain about the nested "src/main/java" directory
> structure but you don't even need that; it is actually really easy to
> override the source and resource directories in the great majority of
> cases. People complain about profiles being "evil" but they are an
> extremely powerful tool, and like any powerful tool are only as "good" or
> "evil" as their use.
>
> I think it is great to caution people against anti-patterns, etc., pointing
> out how they could make their lives easier by structuring things
> differently. But if we are not careful, such advice can degenerate into
> nonconstructive criticism, as illustrated by the unfortunate saying: "Don't
> fight against Maven, you'll loose [sic]." This attitude causes real
> problems within the developer community: at least one of the teams with
> which I collaborate dislikes Maven due to its "our way or the highway"
> attitude.
>
> Maven is an extremely powerful set of building blocks, and I think we
> should be focusing on promoting that power and flexibility, rather than
> criticizing anyone who tries to use Maven in an unconventional way. After
> all, the beauty of "convention over configuration" is that you *can*
> configure and override behavior as needed.

Hear, hear! Thank you Curtis, I've been meaning to respond to one of
those "Don't Fight Maven" statements for a long time. I completely
agree with you. The world isn't black-and-white, there's lots of grey
... and, *shudder*, even colour! ;-)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Ron Wheeler <rw...@artifact-software.com>]

I hope that my comments are not taken as being critical of the person 
asking for help.
Our team was in their position when we started and had to learn the 
"Maven way".

We received a lot of help and got a lot of benefit from the free 
resources provided by the community.
We also were working closely with the team from another Apache project 
that used Maven in their build process and in the build process of 
"customers" of their projects like ourselves so they brought us a lot of 
basic knowledge built into the artifacts that they built for us.

Very often my comment about fighting Maven is accompanied by a 
suggestion that the person try to rephrase their request at a higher level.
- what type of artifact are they trying to build?
- what is so peculiar about their project or environment that makes 
their build "impossible" or "extremely complex" with Maven.

The second question has two purposes
a) Get some facts into the discussion that might reach out to someone 
here who has experience in a similar situation
b) Get the person to understand that Maven is successfully used without  
custom plug-ins or profiles to build a lot of projects everyday so they 
will ultimately be successful and probably with a lot less pain than 
they think.

I will also confess to sometimes just asking a question in a thread that 
is not getting any attention because of the way the problem is posed, in 
order to get the question back in the expert's inboxes with a better or 
more amplified description of the problem so that the person gets some help.

Ron


On 17/04/2012 7:35 PM, Eric Kolotyluk wrote:
>
>
> On 2012-04-17 9:48 AM, Curtis Rueden wrote:
>> Hi everyone,
>>
>>
>> Especially since the most valuable single
>>> bit of advice one can give a new Maven user is:  "if you don't do
>>> things Maven's way, Maven will fight you and Maven will win."
>>>
>> I disagree that it is the "most valuable single bit of advice." It is
>> repeated far too frequently, often in cases where there *is* a 
>> reasonable
>> technical answer to the question being asked.
>
> I think the comment "if you don't do things Maven's way, Maven will 
> fight you and Maven will win." is humor - not fact. Keeping your sense 
> of humor is always good advice when working with Maven.
>
> IMHO - the most valuable single bit of advice one can give a new Maven 
> user is: don't try to master it on your own - ask for help - there are 
> thousands of people with great experience, knowledge and advice who 
> are willing to share it. The Sonatype training has enormous ROI.
>
>>
>> Maven is much more flexible than many give it credit for. You can write
>> your own plugins to do nearly anything, or invoke Ant with AntRun if you
>> have existing Ant-based builds. Even conventions like "one project = one
>> JAR" are not universally true—the assembly plugin lets you do all 
>> kinds of
>> nifty stuff including building multiple artifacts as part of the same
>> project. People complain about the nested "src/main/java" directory
>> structure but you don't even need that; it is actually really easy to
>> override the source and resource directories in the great majority of
>> cases. People complain about profiles being "evil" but they are an
>> extremely powerful tool, and like any powerful tool are only as 
>> "good" or
>> "evil" as their use.
>>
>> I think it is great to caution people against anti-patterns, etc., 
>> pointing
>> out how they could make their lives easier by structuring things
>> differently. But if we are not careful, such advice can degenerate into
>> nonconstructive criticism, as illustrated by the unfortunate saying: 
>> "Don't
>> fight against Maven, you'll loose [sic]." This attitude causes real
>> problems within the developer community: at least one of the teams with
>> which I collaborate dislikes Maven due to its "our way or the highway"
>> attitude.
>>
>> Maven is an extremely powerful set of building blocks, and I think we
>> should be focusing on promoting that power and flexibility, rather than
>> criticizing anyone who tries to use Maven in an unconventional way. 
>> After
>> all, the beauty of "convention over configuration" is that you *can*
>> configure and override behavior as needed.
>
> I do not see anyone criticizing someone who tries to use Maven in an 
> unconventional way - rather we are saying - if you are using Maven and 
> you don't want to hurt yourself...
>
> My many years of experience tells me that far too much technology is 
> too configurable with too many options and choices - and ultimately 
> that causes more trouble than it is worth. Maven is more than 
> adequately configurable, but collectively we still have a lot to learn 
> about respecting and utilizing "convention over configuration" and 
> adapting to the common vision that is Maven.
>
>>
>>
>> People extol the virtues of "convention over configuration", but where
>>> is the compact definitive specification of The Conventions?
>>>
>> I think one major difficulty is that as Maven develops, there is an
>> evolving vision and understanding of what works well and what 
>> doesn't. And
>> that is OK, and will continue to be the case. That said, someone could
>> probably make some good money writing a book about the current vision 
>> and
>> understanding, as well as updating it with new editions over time. :-)
>
> This is very true. Very much of Maven is tribal knowledge and a tribal 
> vision. Fortunately the tribe is strong and friendly :-)
>
>>
>> Regards,
>> Curtis
>>
>>
>> On Tue, Apr 17, 2012 at 11:12 AM, Mark H. Wood<mw...@iupui.edu>  wrote:
>>
>>> On Tue, Apr 17, 2012 at 07:12:26AM -0700, Eric Kolotyluk wrote:
>>>> I also recommend taking the Sonatype training courses - especially if
>>>> you are a software architect.
>>>>
>>>> There is a lot to be said when you can ask question as the 
>>>> instructor is
>>>> going over the material.
>>>>
>>>> However, you are right, if someone were to write a book called the 
>>>> "The
>>>> Maven Way" in the style you suggest, I would certainly be 
>>>> interested in
>>>> buying a copy.
>>> You are not alone in that.  Especially since the most valuable single
>>> bit of advice one can give a new Maven user is:  "if you don't do
>>> things Maven's way, Maven will fight you and Maven will win."
>>>
>>> People extol the virtues of "convention over configuration", but where
>>> is the compact definitive specification of The Conventions?
>>>
>>> -- 
>>> Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
>>> What is obvious to A may be not so obvious to B and downright
>>> ridiculous to C. -- Asimov
>>>
>
> ---------------------------------------------------------------------
> 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

Re: The Maven Way

[Eric Kolotyluk <er...@gmail.com>]

On 2012-04-17 9:48 AM, Curtis Rueden wrote:
> Hi everyone,
>
>
> Especially since the most valuable single
>> bit of advice one can give a new Maven user is:  "if you don't do
>> things Maven's way, Maven will fight you and Maven will win."
>>
> I disagree that it is the "most valuable single bit of advice." It is
> repeated far too frequently, often in cases where there *is* a reasonable
> technical answer to the question being asked.

I think the comment "if you don't do things Maven's way, Maven will 
fight you and Maven will win." is humor - not fact. Keeping your sense 
of humor is always good advice when working with Maven.

IMHO - the most valuable single bit of advice one can give a new Maven 
user is: don't try to master it on your own - ask for help - there are 
thousands of people with great experience, knowledge and advice who are 
willing to share it. The Sonatype training has enormous ROI.

>
> Maven is much more flexible than many give it credit for. You can write
> your own plugins to do nearly anything, or invoke Ant with AntRun if you
> have existing Ant-based builds. Even conventions like "one project = one
> JAR" are not universally true—the assembly plugin lets you do all kinds of
> nifty stuff including building multiple artifacts as part of the same
> project. People complain about the nested "src/main/java" directory
> structure but you don't even need that; it is actually really easy to
> override the source and resource directories in the great majority of
> cases. People complain about profiles being "evil" but they are an
> extremely powerful tool, and like any powerful tool are only as "good" or
> "evil" as their use.
>
> I think it is great to caution people against anti-patterns, etc., pointing
> out how they could make their lives easier by structuring things
> differently. But if we are not careful, such advice can degenerate into
> nonconstructive criticism, as illustrated by the unfortunate saying: "Don't
> fight against Maven, you'll loose [sic]." This attitude causes real
> problems within the developer community: at least one of the teams with
> which I collaborate dislikes Maven due to its "our way or the highway"
> attitude.
>
> Maven is an extremely powerful set of building blocks, and I think we
> should be focusing on promoting that power and flexibility, rather than
> criticizing anyone who tries to use Maven in an unconventional way. After
> all, the beauty of "convention over configuration" is that you *can*
> configure and override behavior as needed.

I do not see anyone criticizing someone who tries to use Maven in an 
unconventional way - rather we are saying - if you are using Maven and 
you don't want to hurt yourself...

My many years of experience tells me that far too much technology is too 
configurable with too many options and choices - and ultimately that 
causes more trouble than it is worth. Maven is more than adequately 
configurable, but collectively we still have a lot to learn about 
respecting and utilizing "convention over configuration" and adapting to 
the common vision that is Maven.

>
>
> People extol the virtues of "convention over configuration", but where
>> is the compact definitive specification of The Conventions?
>>
> I think one major difficulty is that as Maven develops, there is an
> evolving vision and understanding of what works well and what doesn't. And
> that is OK, and will continue to be the case. That said, someone could
> probably make some good money writing a book about the current vision and
> understanding, as well as updating it with new editions over time. :-)

This is very true. Very much of Maven is tribal knowledge and a tribal 
vision. Fortunately the tribe is strong and friendly :-)

>
> Regards,
> Curtis
>
>
> On Tue, Apr 17, 2012 at 11:12 AM, Mark H. Wood<mw...@iupui.edu>  wrote:
>
>> On Tue, Apr 17, 2012 at 07:12:26AM -0700, Eric Kolotyluk wrote:
>>> I also recommend taking the Sonatype training courses - especially if
>>> you are a software architect.
>>>
>>> There is a lot to be said when you can ask question as the instructor is
>>> going over the material.
>>>
>>> However, you are right, if someone were to write a book called the "The
>>> Maven Way" in the style you suggest, I would certainly be interested in
>>> buying a copy.
>> You are not alone in that.  Especially since the most valuable single
>> bit of advice one can give a new Maven user is:  "if you don't do
>> things Maven's way, Maven will fight you and Maven will win."
>>
>> People extol the virtues of "convention over configuration", but where
>> is the compact definitive specification of The Conventions?
>>
>> --
>> Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
>> What is obvious to A may be not so obvious to B and downright
>> ridiculous to C. -- Asimov
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Ron Wheeler <rw...@artifact-software.com>]

On 17/04/2012 2:37 PM, Chad.Davis@emc.com wrote:
>> Especially since the most valuable single
>>> bit of advice one can give a new Maven user is:  "if you don't do
>>> things Maven's way, Maven will fight you and Maven will win."
>>>
>> I disagree that it is the "most valuable single bit of advice." It is repeated far
>> too frequently, often in cases where there *is* a reasonable technical
>> answer to the question being asked.
>>
>> Maven is much more flexible than many give it credit for. You can write your
>> own plugins to do nearly anything, or invoke Ant with AntRun if you have
>> existing Ant-based builds
> I would have to disagree here.  For instance, writing your own plugins is a horrible idea unless you are very, very, very wise maven user.  The problem is that the docs talk a lot about how it's a plugin architecture and how you can write your own mojo's.  I've just dealt with a project where they wrote their own mojo's for a bunch of stuff that was already provided by other existing plugins.  The documentation should emphasize the existing body of plugins and provide a guide to the most useful of those and BURY the concept of writing your own.
>
> I think the whole notion of configuring or customizing maven in any way is a very tricky issue.  It's front page on the docs, but it's the kind of thing that would best be put in Chapter 19 of a long book that covered all of the standard stuff  before even broaching the topic.

Very well put.

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

RE: The Maven Way

[Ch...@emc.com]

> Especially since the most valuable single
> > bit of advice one can give a new Maven user is:  "if you don't do
> > things Maven's way, Maven will fight you and Maven will win."
> >
> 
> I disagree that it is the "most valuable single bit of advice." It is repeated far
> too frequently, often in cases where there *is* a reasonable technical
> answer to the question being asked.
> 
> Maven is much more flexible than many give it credit for. You can write your
> own plugins to do nearly anything, or invoke Ant with AntRun if you have
> existing Ant-based builds

I would have to disagree here.  For instance, writing your own plugins is a horrible idea unless you are very, very, very wise maven user.  The problem is that the docs talk a lot about how it's a plugin architecture and how you can write your own mojo's.  I've just dealt with a project where they wrote their own mojo's for a bunch of stuff that was already provided by other existing plugins.  The documentation should emphasize the existing body of plugins and provide a guide to the most useful of those and BURY the concept of writing your own.   

I think the whole notion of configuring or customizing maven in any way is a very tricky issue.  It's front page on the docs, but it's the kind of thing that would best be put in Chapter 19 of a long book that covered all of the standard stuff  before even broaching the topic.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Curtis Rueden <ct...@wisc.edu>]

Hi everyone,


Especially since the most valuable single
> bit of advice one can give a new Maven user is:  "if you don't do
> things Maven's way, Maven will fight you and Maven will win."
>

I disagree that it is the "most valuable single bit of advice." It is
repeated far too frequently, often in cases where there *is* a reasonable
technical answer to the question being asked.

Maven is much more flexible than many give it credit for. You can write
your own plugins to do nearly anything, or invoke Ant with AntRun if you
have existing Ant-based builds. Even conventions like "one project = one
JAR" are not universally true—the assembly plugin lets you do all kinds of
nifty stuff including building multiple artifacts as part of the same
project. People complain about the nested "src/main/java" directory
structure but you don't even need that; it is actually really easy to
override the source and resource directories in the great majority of
cases. People complain about profiles being "evil" but they are an
extremely powerful tool, and like any powerful tool are only as "good" or
"evil" as their use.

I think it is great to caution people against anti-patterns, etc., pointing
out how they could make their lives easier by structuring things
differently. But if we are not careful, such advice can degenerate into
nonconstructive criticism, as illustrated by the unfortunate saying: "Don't
fight against Maven, you'll loose [sic]." This attitude causes real
problems within the developer community: at least one of the teams with
which I collaborate dislikes Maven due to its "our way or the highway"
attitude.

Maven is an extremely powerful set of building blocks, and I think we
should be focusing on promoting that power and flexibility, rather than
criticizing anyone who tries to use Maven in an unconventional way. After
all, the beauty of "convention over configuration" is that you *can*
configure and override behavior as needed.


People extol the virtues of "convention over configuration", but where
> is the compact definitive specification of The Conventions?
>

I think one major difficulty is that as Maven develops, there is an
evolving vision and understanding of what works well and what doesn't. And
that is OK, and will continue to be the case. That said, someone could
probably make some good money writing a book about the current vision and
understanding, as well as updating it with new editions over time. :-)

Regards,
Curtis


On Tue, Apr 17, 2012 at 11:12 AM, Mark H. Wood <mw...@iupui.edu> wrote:

> On Tue, Apr 17, 2012 at 07:12:26AM -0700, Eric Kolotyluk wrote:
> > I also recommend taking the Sonatype training courses - especially if
> > you are a software architect.
> >
> > There is a lot to be said when you can ask question as the instructor is
> > going over the material.
> >
> > However, you are right, if someone were to write a book called the "The
> > Maven Way" in the style you suggest, I would certainly be interested in
> > buying a copy.
>
> You are not alone in that.  Especially since the most valuable single
> bit of advice one can give a new Maven user is:  "if you don't do
> things Maven's way, Maven will fight you and Maven will win."
>
> People extol the virtues of "convention over configuration", but where
> is the compact definitive specification of The Conventions?
>
> --
> Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
> What is obvious to A may be not so obvious to B and downright
> ridiculous to C. -- Asimov
>

Re: The Maven Way

[Ron Wheeler <rw...@artifact-software.com>]

On 18/04/2012 4:03 PM, Curtis Rueden wrote:
> Hi everyone,
>
> Thanks to all for the robust discussion!
>
> To Ron, I apologize if my comments sounded overly critical of you in
> particular. I get that you are trying to help guide people in the right
> direction, and it is certainly good for them to question their assumptions,
> and to understand the Maven basics before they go creating a rat's nest of
> unnecessary complexity. So I completely agree with your perspective and
> comments.
>
> What concerns me a bit is perhaps nitpickery: sayings like "you will lose"
> and "Maven will win" imply that advanced or unconventional configuration
> cannot be done with Maven. Of course, we all know that that is not the
> case. But a newbie doesn't.
Point taken.
I just want to make them stop long enough to think about their project's 
real build situation.
I know that once they start to describe what they want to build rather 
than ask how to get past a roadblock, the technical resources here will 
explain how to get a build that follows "Best Practices" or at least 
known successful pattern.

>
> The ideas I personally would like to see communicated are:
>
> 1) When used properly, Maven does a *lot* of heavy lifting for you—much
> more than Ant.
>
> 2) Most projects can be expressed concisely in a POM by following Maven
> conventions. Many things that required substantial configuration with Ant
> etc. come largely for free with Maven.
>
> 3) When you must stray from conventions and standards, that is OK—but first
> be sure that you really must. And be aware that by doing so, you pay a
> *heavy* price. (And consider giving feedback to the maintainers of the
> standards you didn't use, so they can be improved in the future to
> encompass your use case.)
>
> Unfortunately, I haven't come up with any witty slogans along these lines...
Witty does not always get you loved!!!

>
> Eric Kolotyluk wrote:
>
>> I think the comment "if you don't do things Maven's way, Maven will fight
>> you and Maven will win." is humor - not fact. Keeping your sense of humor
>> is always good advice when working with Maven.
>>
> For sure. The first time I saw that saying I thought it was pretty funny
> too, because I had already been through the learning curve and understood
> what it's trying to say.
>
> But regarding it being humor rather than fact: there is usually an element
> of truth in humor. We should keep in mind that newbies are coming in blind,
> with very little context. Some people, including very experienced
> developers, might read it more as a statement of fact or at least attitude
> that what they are trying to do is wrong, and conclude that Maven and/or
> its community is inflexible and inappropriate for their use, which is a
> shame, because as I said before Maven is actually extremely flexible and I
> think should be used whenever possible. :-)
>
>
> Wayne Fay wrote:
>
>> But no matter what is done along these lines, you will always have some
>> nontrivial percentage of the population that "doesn't have time to read all
>> of that" and just wants to make their build work right now. We can point
>> people at books all day long but they can (and do) ignore that advice.
>>
> Yep, writing good documentation is really hard!
>
> I would also add: how the docs are organized is just as important as the
> content itself. We each have our own threshold for reading the docs versus
> "just trying it" and how the documentation is laid out will affect whether
> we find the answers with the limited effort we expend.
>
>
> Regards,
> Curtis
>
>
> On Wed, Apr 18, 2012 at 12:33 PM, Wayne Fay<wa...@gmail.com>  wrote:
>
>>> The Maven site is not the most friendly place to start as a new Maven
>>> user but it is not the only resource.
>>>
>>> Perhaps the community should try to come to a consensus about the books
>>> and recommend one as the "best" starting point for a new user and one as
>>> the best place to find "Best Practices".
>> We may need more Maven documentation like this:
>> http://learnpythonthehardway.org/
>>
>> But no matter what is done along these lines, you will always have
>> some nontrivial percentage of the population that "doesn't have time
>> to read all of that" and just wants to make their build work right
>> now. We can point people at books all day long but they can (and do)
>> ignore that advice.
>>
>> The reality is that Maven has a bit of a learning curve and most
>> people new to it (mostly coming from Ant) will try to mold Maven to
>> their uses (by applying it to their existing projects and swapping Ant
>> config for Maven plugin config line by line) instead of leveraging the
>> great functionality out of the box (with zero config so long as you
>> stick with those pesky conventions). I'm not sure how to help people
>> short-circuit this learning process even WITH documentation.
>>
>> ESR's essay on asking the right questions is key to getting proper
>> help on this list:
>> http://www.catb.org/~esr/faqs/smart-questions.html#goal
>>
>> Wayne
>>
>> ---------------------------------------------------------------------
>> 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

Re: The Maven Way

[Eric Kolotyluk <er...@gmail.com>]

Thanks - it has been one of the more interesting adventures in my 
professional life :-)

Cheers, Eric

On 2012-04-18 4:37 PM, Ron Wheeler wrote:
> Eric,
> I remember when you first started visiting the forum.
> As you described, you came with some pretty strong views about how 
> Maven should work.
>
> I do remember how carefully and well, you sought out advice from the 
> people here.
> In spite of your strong feelings that you were an experienced 
> developer, you actively sought out advice from the forum and were 
> extremely flexible in adopting the advice that you got.
>
> It was fun to watch your progress as you advanced through your 
> conversion.
>
>
> Ron
>
> On 18/04/2012 6:59 PM, Eric Kolotyluk wrote:
>>
>>
>> On 2012-04-18 1:03 PM, Curtis Rueden wrote:
>>> Hi everyone,
>>>
>>> Thanks to all for the robust discussion!
>>>
>>> To Ron, I apologize if my comments sounded overly critical of you in
>>> particular. I get that you are trying to help guide people in the right
>>> direction, and it is certainly good for them to question their 
>>> assumptions,
>>> and to understand the Maven basics before they go creating a rat's 
>>> nest of
>>> unnecessary complexity. So I completely agree with your perspective and
>>> comments.
>>>
>>> What concerns me a bit is perhaps nitpickery: sayings like "you will 
>>> lose"
>>> and "Maven will win" imply that advanced or unconventional 
>>> configuration
>>> cannot be done with Maven. Of course, we all know that that is not the
>>> case. But a newbie doesn't.
>>>
>>> The ideas I personally would like to see communicated are:
>>>
>>> 1) When used properly, Maven does a *lot* of heavy lifting for you—much
>>> more than Ant.
>>>
>>> 2) Most projects can be expressed concisely in a POM by following Maven
>>> conventions. Many things that required substantial configuration 
>>> with Ant
>>> etc. come largely for free with Maven.
>>>
>>> 3) When you must stray from conventions and standards, that is 
>>> OK—but first
>>> be sure that you really must. And be aware that by doing so, you pay a
>>> *heavy* price. (And consider giving feedback to the maintainers of the
>>> standards you didn't use, so they can be improved in the future to
>>> encompass your use case.)
>>>
>>> Unfortunately, I haven't come up with any witty slogans along these 
>>> lines...
>>>
>>>
>>> Eric Kolotyluk wrote:
>>>
>>>> I think the comment "if you don't do things Maven's way, Maven will 
>>>> fight
>>>> you and Maven will win." is humor - not fact. Keeping your sense of 
>>>> humor
>>>> is always good advice when working with Maven.
>>>>
>>> For sure. The first time I saw that saying I thought it was pretty 
>>> funny
>>> too, because I had already been through the learning curve and 
>>> understood
>>> what it's trying to say.
>>>
>>> But regarding it being humor rather than fact: there is usually an 
>>> element
>>> of truth in humor. We should keep in mind that newbies are coming in 
>>> blind,
>>> with very little context. Some people, including very experienced
>>> developers, might read it more as a statement of fact or at least 
>>> attitude
>>> that what they are trying to do is wrong, and conclude that Maven 
>>> and/or
>>> its community is inflexible and inappropriate for their use, which is a
>>> shame, because as I said before Maven is actually extremely flexible 
>>> and I
>>> think should be used whenever possible. :-)
>>
>> Humor is in fact 'art' and we all experience art differently - but 
>> the community we hang out with influences how we experience it. Thank 
>> goodness there are many people in the Maven community with a sense of 
>> humor or I could have gone insane %-)
>>
>> Maven is in fact a lot about attitude, and learning this was perhaps 
>> the hardest thing for me to understand. Coming from a background of 
>> 'make' and then 'ant' I simply had the wrong attitude about 
>> developing software. I mean the word 'wrong' sincerely because Maven 
>> is what I always wanted in the end, and 'make' and 'ant' are simply 
>> tools I used and attitudes about software development were the 
>> state-of-the-art at the time. I also mean the word 'wrong' personally 
>> because it is not for me to tell other people not to use make, ant, 
>> or any other tool they are most comfortable with. But I will 
>> evangelize Maven as much as I can until something better comes along.
>>
>> I started out hating Maven vehemently - it was because I was trying 
>> to learn various new technologies such as Hibernate, and I simply 
>> could not find any simple "hello world" examples of how to get 
>> started that did not require having to first learn to use Maven. 
>> There are just too many people who casually assume everyone should 
>> learn to use Maven - be dammed if you can't - and I still find that 
>> terribly offensive.
>>
>> Weeks later after I had finished my research and assessment of new 
>> technologies, and I had calmed down, I decided to investigate Maven 
>> simply because of the ubiquitous evangelizing I found in my travels - 
>> if Maven has so many fans I simply have to see what all the hype is 
>> about. After choosing to adopt Maven for a new project I then spent 6 
>> months hurting myself because I was convinced I could simply learn 
>> Maven on my own - my own arrogance that I could figure it out on my 
>> own - and taking shortcuts was ok. After finally taking the Sonatype 
>> training courses suddenly most of the pain went away and I was left 
>> with a Maven I can now rave about - and still complain about (but 
>> more articulately now).
>>
>> Maven is one of the most powerful software development tools I have 
>> ever come across - and one thing I know about 'power tools' is that 
>> for the untrained then can be very painful. Maven is also a club, a 
>> culture a community - a very welcoming community - and the first 
>> thing beginners should learn about Maven, is to engage the community.
>>
>> The single most important thing about Maven is users@maven.apache.org
>>
>>>
>>>
>>> Wayne Fay wrote:
>>>
>>>> But no matter what is done along these lines, you will always have 
>>>> some
>>>> nontrivial percentage of the population that "doesn't have time to 
>>>> read all
>>>> of that" and just wants to make their build work right now. We can 
>>>> point
>>>> people at books all day long but they can (and do) ignore that advice.
>>>>
>>> Yep, writing good documentation is really hard!
>>>
>>> I would also add: how the docs are organized is just as important as 
>>> the
>>> content itself. We each have our own threshold for reading the docs 
>>> versus
>>> "just trying it" and how the documentation is laid out will affect 
>>> whether
>>> we find the answers with the limited effort we expend.
>>>
>>>
>>> Regards,
>>> Curtis
>>>
>>>
>>> On Wed, Apr 18, 2012 at 12:33 PM, Wayne Fay<wa...@gmail.com> wrote:
>>>
>>>>> The Maven site is not the most friendly place to start as a new Maven
>>>>> user but it is not the only resource.
>>>>>
>>>>> Perhaps the community should try to come to a consensus about the 
>>>>> books
>>>>> and recommend one as the "best" starting point for a new user and 
>>>>> one as
>>>>> the best place to find "Best Practices".
>>>> We may need more Maven documentation like this:
>>>> http://learnpythonthehardway.org/
>>>>
>>>> But no matter what is done along these lines, you will always have
>>>> some nontrivial percentage of the population that "doesn't have time
>>>> to read all of that" and just wants to make their build work right
>>>> now. We can point people at books all day long but they can (and do)
>>>> ignore that advice.
>>>>
>>>> The reality is that Maven has a bit of a learning curve and most
>>>> people new to it (mostly coming from Ant) will try to mold Maven to
>>>> their uses (by applying it to their existing projects and swapping Ant
>>>> config for Maven plugin config line by line) instead of leveraging the
>>>> great functionality out of the box (with zero config so long as you
>>>> stick with those pesky conventions). I'm not sure how to help people
>>>> short-circuit this learning process even WITH documentation.
>>>>
>>>> ESR's essay on asking the right questions is key to getting proper
>>>> help on this list:
>>>> http://www.catb.org/~esr/faqs/smart-questions.html#goal
>>>>
>>>> Wayne
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Ron Wheeler <rw...@artifact-software.com>]

Eric,
I remember when you first started visiting the forum.
As you described, you came with some pretty strong views about how Maven 
should work.

I do remember how carefully and well, you sought out advice from the 
people here.
In spite of your strong feelings that you were an experienced developer, 
you actively sought out advice from the forum and were extremely 
flexible in adopting the advice that you got.

It was fun to watch your progress as you advanced through your conversion.


Ron

On 18/04/2012 6:59 PM, Eric Kolotyluk wrote:
>
>
> On 2012-04-18 1:03 PM, Curtis Rueden wrote:
>> Hi everyone,
>>
>> Thanks to all for the robust discussion!
>>
>> To Ron, I apologize if my comments sounded overly critical of you in
>> particular. I get that you are trying to help guide people in the right
>> direction, and it is certainly good for them to question their 
>> assumptions,
>> and to understand the Maven basics before they go creating a rat's 
>> nest of
>> unnecessary complexity. So I completely agree with your perspective and
>> comments.
>>
>> What concerns me a bit is perhaps nitpickery: sayings like "you will 
>> lose"
>> and "Maven will win" imply that advanced or unconventional configuration
>> cannot be done with Maven. Of course, we all know that that is not the
>> case. But a newbie doesn't.
>>
>> The ideas I personally would like to see communicated are:
>>
>> 1) When used properly, Maven does a *lot* of heavy lifting for you—much
>> more than Ant.
>>
>> 2) Most projects can be expressed concisely in a POM by following Maven
>> conventions. Many things that required substantial configuration with 
>> Ant
>> etc. come largely for free with Maven.
>>
>> 3) When you must stray from conventions and standards, that is OK—but 
>> first
>> be sure that you really must. And be aware that by doing so, you pay a
>> *heavy* price. (And consider giving feedback to the maintainers of the
>> standards you didn't use, so they can be improved in the future to
>> encompass your use case.)
>>
>> Unfortunately, I haven't come up with any witty slogans along these 
>> lines...
>>
>>
>> Eric Kolotyluk wrote:
>>
>>> I think the comment "if you don't do things Maven's way, Maven will 
>>> fight
>>> you and Maven will win." is humor - not fact. Keeping your sense of 
>>> humor
>>> is always good advice when working with Maven.
>>>
>> For sure. The first time I saw that saying I thought it was pretty funny
>> too, because I had already been through the learning curve and 
>> understood
>> what it's trying to say.
>>
>> But regarding it being humor rather than fact: there is usually an 
>> element
>> of truth in humor. We should keep in mind that newbies are coming in 
>> blind,
>> with very little context. Some people, including very experienced
>> developers, might read it more as a statement of fact or at least 
>> attitude
>> that what they are trying to do is wrong, and conclude that Maven and/or
>> its community is inflexible and inappropriate for their use, which is a
>> shame, because as I said before Maven is actually extremely flexible 
>> and I
>> think should be used whenever possible. :-)
>
> Humor is in fact 'art' and we all experience art differently - but the 
> community we hang out with influences how we experience it. Thank 
> goodness there are many people in the Maven community with a sense of 
> humor or I could have gone insane %-)
>
> Maven is in fact a lot about attitude, and learning this was perhaps 
> the hardest thing for me to understand. Coming from a background of 
> 'make' and then 'ant' I simply had the wrong attitude about developing 
> software. I mean the word 'wrong' sincerely because Maven is what I 
> always wanted in the end, and 'make' and 'ant' are simply tools I used 
> and attitudes about software development were the state-of-the-art at 
> the time. I also mean the word 'wrong' personally because it is not 
> for me to tell other people not to use make, ant, or any other tool 
> they are most comfortable with. But I will evangelize Maven as much as 
> I can until something better comes along.
>
> I started out hating Maven vehemently - it was because I was trying to 
> learn various new technologies such as Hibernate, and I simply could 
> not find any simple "hello world" examples of how to get started that 
> did not require having to first learn to use Maven. There are just too 
> many people who casually assume everyone should learn to use Maven - 
> be dammed if you can't - and I still find that terribly offensive.
>
> Weeks later after I had finished my research and assessment of new 
> technologies, and I had calmed down, I decided to investigate Maven 
> simply because of the ubiquitous evangelizing I found in my travels - 
> if Maven has so many fans I simply have to see what all the hype is 
> about. After choosing to adopt Maven for a new project I then spent 6 
> months hurting myself because I was convinced I could simply learn 
> Maven on my own - my own arrogance that I could figure it out on my 
> own - and taking shortcuts was ok. After finally taking the Sonatype 
> training courses suddenly most of the pain went away and I was left 
> with a Maven I can now rave about - and still complain about (but more 
> articulately now).
>
> Maven is one of the most powerful software development tools I have 
> ever come across - and one thing I know about 'power tools' is that 
> for the untrained then can be very painful. Maven is also a club, a 
> culture a community - a very welcoming community - and the first thing 
> beginners should learn about Maven, is to engage the community.
>
> The single most important thing about Maven is users@maven.apache.org
>
>>
>>
>> Wayne Fay wrote:
>>
>>> But no matter what is done along these lines, you will always have some
>>> nontrivial percentage of the population that "doesn't have time to 
>>> read all
>>> of that" and just wants to make their build work right now. We can 
>>> point
>>> people at books all day long but they can (and do) ignore that advice.
>>>
>> Yep, writing good documentation is really hard!
>>
>> I would also add: how the docs are organized is just as important as the
>> content itself. We each have our own threshold for reading the docs 
>> versus
>> "just trying it" and how the documentation is laid out will affect 
>> whether
>> we find the answers with the limited effort we expend.
>>
>>
>> Regards,
>> Curtis
>>
>>
>> On Wed, Apr 18, 2012 at 12:33 PM, Wayne Fay<wa...@gmail.com>  wrote:
>>
>>>> The Maven site is not the most friendly place to start as a new Maven
>>>> user but it is not the only resource.
>>>>
>>>> Perhaps the community should try to come to a consensus about the 
>>>> books
>>>> and recommend one as the "best" starting point for a new user and 
>>>> one as
>>>> the best place to find "Best Practices".
>>> We may need more Maven documentation like this:
>>> http://learnpythonthehardway.org/
>>>
>>> But no matter what is done along these lines, you will always have
>>> some nontrivial percentage of the population that "doesn't have time
>>> to read all of that" and just wants to make their build work right
>>> now. We can point people at books all day long but they can (and do)
>>> ignore that advice.
>>>
>>> The reality is that Maven has a bit of a learning curve and most
>>> people new to it (mostly coming from Ant) will try to mold Maven to
>>> their uses (by applying it to their existing projects and swapping Ant
>>> config for Maven plugin config line by line) instead of leveraging the
>>> great functionality out of the box (with zero config so long as you
>>> stick with those pesky conventions). I'm not sure how to help people
>>> short-circuit this learning process even WITH documentation.
>>>
>>> ESR's essay on asking the right questions is key to getting proper
>>> help on this list:
>>> http://www.catb.org/~esr/faqs/smart-questions.html#goal
>>>
>>> Wayne
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> 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

Re: The Maven Way

[Eric Kolotyluk <er...@gmail.com>]

On 2012-04-18 1:03 PM, Curtis Rueden wrote:
> Hi everyone,
>
> Thanks to all for the robust discussion!
>
> To Ron, I apologize if my comments sounded overly critical of you in
> particular. I get that you are trying to help guide people in the right
> direction, and it is certainly good for them to question their assumptions,
> and to understand the Maven basics before they go creating a rat's nest of
> unnecessary complexity. So I completely agree with your perspective and
> comments.
>
> What concerns me a bit is perhaps nitpickery: sayings like "you will lose"
> and "Maven will win" imply that advanced or unconventional configuration
> cannot be done with Maven. Of course, we all know that that is not the
> case. But a newbie doesn't.
>
> The ideas I personally would like to see communicated are:
>
> 1) When used properly, Maven does a *lot* of heavy lifting for you—much
> more than Ant.
>
> 2) Most projects can be expressed concisely in a POM by following Maven
> conventions. Many things that required substantial configuration with Ant
> etc. come largely for free with Maven.
>
> 3) When you must stray from conventions and standards, that is OK—but first
> be sure that you really must. And be aware that by doing so, you pay a
> *heavy* price. (And consider giving feedback to the maintainers of the
> standards you didn't use, so they can be improved in the future to
> encompass your use case.)
>
> Unfortunately, I haven't come up with any witty slogans along these lines...
>
>
> Eric Kolotyluk wrote:
>
>> I think the comment "if you don't do things Maven's way, Maven will fight
>> you and Maven will win." is humor - not fact. Keeping your sense of humor
>> is always good advice when working with Maven.
>>
> For sure. The first time I saw that saying I thought it was pretty funny
> too, because I had already been through the learning curve and understood
> what it's trying to say.
>
> But regarding it being humor rather than fact: there is usually an element
> of truth in humor. We should keep in mind that newbies are coming in blind,
> with very little context. Some people, including very experienced
> developers, might read it more as a statement of fact or at least attitude
> that what they are trying to do is wrong, and conclude that Maven and/or
> its community is inflexible and inappropriate for their use, which is a
> shame, because as I said before Maven is actually extremely flexible and I
> think should be used whenever possible. :-)

Humor is in fact 'art' and we all experience art differently - but the 
community we hang out with influences how we experience it. Thank 
goodness there are many people in the Maven community with a sense of 
humor or I could have gone insane %-)

Maven is in fact a lot about attitude, and learning this was perhaps the 
hardest thing for me to understand. Coming from a background of 'make' 
and then 'ant' I simply had the wrong attitude about developing 
software. I mean the word 'wrong' sincerely because Maven is what I 
always wanted in the end, and 'make' and 'ant' are simply tools I used 
and attitudes about software development were the state-of-the-art at 
the time. I also mean the word 'wrong' personally because it is not for 
me to tell other people not to use make, ant, or any other tool they are 
most comfortable with. But I will evangelize Maven as much as I can 
until something better comes along.

I started out hating Maven vehemently - it was because I was trying to 
learn various new technologies such as Hibernate, and I simply could not 
find any simple "hello world" examples of how to get started that did 
not require having to first learn to use Maven. There are just too many 
people who casually assume everyone should learn to use Maven - be 
dammed if you can't - and I still find that terribly offensive.

Weeks later after I had finished my research and assessment of new 
technologies, and I had calmed down, I decided to investigate Maven 
simply because of the ubiquitous evangelizing I found in my travels - if 
Maven has so many fans I simply have to see what all the hype is about. 
After choosing to adopt Maven for a new project I then spent 6 months 
hurting myself because I was convinced I could simply learn Maven on my 
own - my own arrogance that I could figure it out on my own - and taking 
shortcuts was ok. After finally taking the Sonatype training courses 
suddenly most of the pain went away and I was left with a Maven I can 
now rave about - and still complain about (but more articulately now).

Maven is one of the most powerful software development tools I have ever 
come across - and one thing I know about 'power tools' is that for the 
untrained then can be very painful. Maven is also a club, a culture a 
community - a very welcoming community - and the first thing beginners 
should learn about Maven, is to engage the community.

The single most important thing about Maven is users@maven.apache.org

>
>
> Wayne Fay wrote:
>
>> But no matter what is done along these lines, you will always have some
>> nontrivial percentage of the population that "doesn't have time to read all
>> of that" and just wants to make their build work right now. We can point
>> people at books all day long but they can (and do) ignore that advice.
>>
> Yep, writing good documentation is really hard!
>
> I would also add: how the docs are organized is just as important as the
> content itself. We each have our own threshold for reading the docs versus
> "just trying it" and how the documentation is laid out will affect whether
> we find the answers with the limited effort we expend.
>
>
> Regards,
> Curtis
>
>
> On Wed, Apr 18, 2012 at 12:33 PM, Wayne Fay<wa...@gmail.com>  wrote:
>
>>> The Maven site is not the most friendly place to start as a new Maven
>>> user but it is not the only resource.
>>>
>>> Perhaps the community should try to come to a consensus about the books
>>> and recommend one as the "best" starting point for a new user and one as
>>> the best place to find "Best Practices".
>> We may need more Maven documentation like this:
>> http://learnpythonthehardway.org/
>>
>> But no matter what is done along these lines, you will always have
>> some nontrivial percentage of the population that "doesn't have time
>> to read all of that" and just wants to make their build work right
>> now. We can point people at books all day long but they can (and do)
>> ignore that advice.
>>
>> The reality is that Maven has a bit of a learning curve and most
>> people new to it (mostly coming from Ant) will try to mold Maven to
>> their uses (by applying it to their existing projects and swapping Ant
>> config for Maven plugin config line by line) instead of leveraging the
>> great functionality out of the box (with zero config so long as you
>> stick with those pesky conventions). I'm not sure how to help people
>> short-circuit this learning process even WITH documentation.
>>
>> ESR's essay on asking the right questions is key to getting proper
>> help on this list:
>> http://www.catb.org/~esr/faqs/smart-questions.html#goal
>>
>> Wayne
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Curtis Rueden <ct...@wisc.edu>]

Hi everyone,

Thanks to all for the robust discussion!

To Ron, I apologize if my comments sounded overly critical of you in
particular. I get that you are trying to help guide people in the right
direction, and it is certainly good for them to question their assumptions,
and to understand the Maven basics before they go creating a rat's nest of
unnecessary complexity. So I completely agree with your perspective and
comments.

What concerns me a bit is perhaps nitpickery: sayings like "you will lose"
and "Maven will win" imply that advanced or unconventional configuration
cannot be done with Maven. Of course, we all know that that is not the
case. But a newbie doesn't.

The ideas I personally would like to see communicated are:

1) When used properly, Maven does a *lot* of heavy lifting for you—much
more than Ant.

2) Most projects can be expressed concisely in a POM by following Maven
conventions. Many things that required substantial configuration with Ant
etc. come largely for free with Maven.

3) When you must stray from conventions and standards, that is OK—but first
be sure that you really must. And be aware that by doing so, you pay a
*heavy* price. (And consider giving feedback to the maintainers of the
standards you didn't use, so they can be improved in the future to
encompass your use case.)

Unfortunately, I haven't come up with any witty slogans along these lines...


Eric Kolotyluk wrote:

> I think the comment "if you don't do things Maven's way, Maven will fight
> you and Maven will win." is humor - not fact. Keeping your sense of humor
> is always good advice when working with Maven.
>

For sure. The first time I saw that saying I thought it was pretty funny
too, because I had already been through the learning curve and understood
what it's trying to say.

But regarding it being humor rather than fact: there is usually an element
of truth in humor. We should keep in mind that newbies are coming in blind,
with very little context. Some people, including very experienced
developers, might read it more as a statement of fact or at least attitude
that what they are trying to do is wrong, and conclude that Maven and/or
its community is inflexible and inappropriate for their use, which is a
shame, because as I said before Maven is actually extremely flexible and I
think should be used whenever possible. :-)


Wayne Fay wrote:

> But no matter what is done along these lines, you will always have some
> nontrivial percentage of the population that "doesn't have time to read all
> of that" and just wants to make their build work right now. We can point
> people at books all day long but they can (and do) ignore that advice.
>

Yep, writing good documentation is really hard!

I would also add: how the docs are organized is just as important as the
content itself. We each have our own threshold for reading the docs versus
"just trying it" and how the documentation is laid out will affect whether
we find the answers with the limited effort we expend.


Regards,
Curtis


On Wed, Apr 18, 2012 at 12:33 PM, Wayne Fay <wa...@gmail.com> wrote:

> > The Maven site is not the most friendly place to start as a new Maven
> > user but it is not the only resource.
> >
> > Perhaps the community should try to come to a consensus about the books
> > and recommend one as the "best" starting point for a new user and one as
> > the best place to find "Best Practices".
>
> We may need more Maven documentation like this:
> http://learnpythonthehardway.org/
>
> But no matter what is done along these lines, you will always have
> some nontrivial percentage of the population that "doesn't have time
> to read all of that" and just wants to make their build work right
> now. We can point people at books all day long but they can (and do)
> ignore that advice.
>
> The reality is that Maven has a bit of a learning curve and most
> people new to it (mostly coming from Ant) will try to mold Maven to
> their uses (by applying it to their existing projects and swapping Ant
> config for Maven plugin config line by line) instead of leveraging the
> great functionality out of the box (with zero config so long as you
> stick with those pesky conventions). I'm not sure how to help people
> short-circuit this learning process even WITH documentation.
>
> ESR's essay on asking the right questions is key to getting proper
> help on this list:
> http://www.catb.org/~esr/faqs/smart-questions.html#goal
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: The Maven Way

["Mark H. Wood" <mw...@IUPUI.Edu>]

Zero configuration?  Really?

  mwood@mhw ~ $ mkdir testmvn
  mwood@mhw ~ $ cd testmvn
  mwood@mhw ~/testmvn $ mvn install
  [INFO] Scanning for projects...
  [INFO]
  ------------------------------------------------------------------------
  [INFO] Building Maven Default Project
  [INFO]    task-segment: [install]
  [INFO]
  ------------------------------------------------------------------------
  [INFO]
  ------------------------------------------------------------------------
  [ERROR] BUILD ERROR
  [INFO]
  ------------------------------------------------------------------------
  [INFO] Cannot execute mojo: resources. It requires a project with an
  existing pom.xml, but the build is not using one.
  [INFO]
  ------------------------------------------------------------------------
  [INFO] For more information, run Maven with the -e switch
  [INFO]
  ------------------------------------------------------------------------
  [INFO] Total time: < 1 second
  [INFO] Finished at: Thu Apr 19 08:48:32 EDT 2012
  [INFO] Final Memory: 5M/75M
  [INFO]
  ------------------------------------------------------------------------

So I need to write a POM.  I hear that Maven can do that for me:

  mwood@mhw ~/testmvn $ mvn archetype:generate
  [INFO] Scanning for projects...
  [INFO] Searching repository for plugin with prefix: 'archetype'.
  [INFO]
  ------------------------------------------------------------------------
  [INFO] Building Maven Default Project
  [INFO]    task-segment: [archetype:generate] (aggregator-style)
  [INFO]
  ------------------------------------------------------------------------
  [INFO] Preparing archetype:generate
  [INFO] No goals needed for project - skipping
  [INFO] Setting property: classpath.resource.loader.class =>
  'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
  [INFO] Setting property: velocimacro.messages.on => 'false'.
  [INFO] Setting property: resource.loader => 'classpath'.
  [INFO] Setting property: resource.manager.logwhenfound => 'false'.
  [INFO] [archetype:generate {execution: default-cli}]
  [INFO] Generating project in Interactive mode
  [INFO] No archetype defined. Using maven-archetype-quickstart
  (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
  Choose archetype:
  [long list]
  Choose a number:
  (1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41)
  15: : 

[It doesn't know which archetype I want.  Fair enough.]

  [INFO] artifact
  org.apache.maven.archetypes:maven-archetype-quickstart: checking for
  updates from central
  Define value for groupId: : edu.iupui.ulib
  Define value for artifactId: : testmvn
  Define value for version:  1.0-SNAPSHOT: : 

[Maven does not supply GAV coordinates.  I have to configure them.  Of
course I do -- how could it possibly know them until I tell it?]

  Define value for package:  edu.iupui.ulib: : 

[A reasonable guess.]

  Confirm properties configuration:
  groupId: edu.iupui.ulib
  artifactId: testmvn
  version: 1.0-SNAPSHOT
  package: edu.iupui.ulib
   Y: : y
  [INFO]
  ----------------------------------------------------------------------------
  [INFO] Using following parameters for creating OldArchetype:
  maven-archetype-quickstart:RELEASE
  [INFO]
  ----------------------------------------------------------------------------
  [INFO] Parameter: groupId, Value: edu.iupui.ulib
  [INFO] Parameter: packageName, Value: edu.iupui.ulib
  [INFO] Parameter: package, Value: edu.iupui.ulib
  [INFO] Parameter: artifactId, Value: testmvn
  [INFO] Parameter: basedir, Value: /home/mwood/testmvn
  [INFO] Parameter: version, Value: 1.0-SNAPSHOT
  [INFO] ********************* End of debug info from resources from
  generated POM ***********************
  [INFO] OldArchetype created in dir: /home/mwood/testmvn/testmvn
  [INFO]
  ------------------------------------------------------------------------
  [INFO] BUILD SUCCESSFUL
  [INFO]
  ------------------------------------------------------------------------
  [INFO] Total time: 1 minute 48 seconds
  [INFO] Finished at: Thu Apr 19 08:51:33 EDT 2012
  [INFO] Final Memory: 14M/173M
  [INFO]
  ------------------------------------------------------------------------

That's quite a bit more than zero:

  mwood@mhw ~/testmvn/testmvn $ ls -l pom.xml 
  -rw-r--r-- 1 mwood mwood 750 Apr 19 08:51 pom.xml

You could try doing it yourself:

  mwood@mhw ~/testmvn/testmvn $ echo "<project/>" > pom.xml

but you'll generate a FATAL ERROR.  "Not a v4.0.0 POM."  It must be
configured.

Returning to the generated configured POM, 'mvn deploy' chugs along
quite well for a bit and then dies because it doesn't know where the
repository is.  Of course it doesn't.  You have to configure it.  It's
nice enough to give you ten lines of POM template XML, but it can't
know what goes between the tags.

'mvn site:deploy' also doesn't know how to distribute the site.  You
have to configure it.  In two different files.  In two different
directories.  (There are good reasons for that.)

I'm being silly to make a point: 'zero configuration' isn't possible.
You need to configure your project even to start, and you need to know
some rather nontrivial and non-obvious stuff about Maven to do that
properly.  A complete deployable can't be done without more
configuration, some of it a bit abstruse.  This is not something
lacking in Maven; it must be that way to do its job: modelling and
orchestrating complex processes with many necessary parameters whose
values vary unpredictably with each application.

Some of this configuration can't be done until you know your local
policies, which means someone has to *create* local policies.

Maven strives heroically to simplify all this for us but, as Einstein
observed, there are limits to how much you can usefully simplify a
model.  Maven does very well, but it can't do everything for us.  It's
not possible to have concrete conventions for some aspects of a
project, since there is more than one possible project.

As long as I'm ranting: the Project Object Model is quite complex, of
necessity.  The Conventions represent a view over that model which
obscures many aspects of its complexity.  You often don't have to
write anything to control those aspects, but you do always have to
think about them.

Convention is simply built-in configuration which was agreed on by
some people who (we hope and believe) knew what they were doing and
which is generally accepted in the community.  Choosing not to
configure something is choosing to configure it the way Maven comes
out of the box.  Which means one needs to understand how Maven is
configured out of the box in order to make good choices.  Maven's
conventional configuration is pretty good and fairly general, but
discovering all of the bits you have to know can be challenging and,
until you know what bits to look for, Maven's behavior can be
puzzling.

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.

Re: The Maven Way

[Wayne Fay <wa...@gmail.com>]

> The Maven site is not the most friendly place to start as a new Maven
> user but it is not the only resource.
>
> Perhaps the community should try to come to a consensus about the books
> and recommend one as the "best" starting point for a new user and one as
> the best place to find "Best Practices".

We may need more Maven documentation like this:
http://learnpythonthehardway.org/

But no matter what is done along these lines, you will always have
some nontrivial percentage of the population that "doesn't have time
to read all of that" and just wants to make their build work right
now. We can point people at books all day long but they can (and do)
ignore that advice.

The reality is that Maven has a bit of a learning curve and most
people new to it (mostly coming from Ant) will try to mold Maven to
their uses (by applying it to their existing projects and swapping Ant
config for Maven plugin config line by line) instead of leveraging the
great functionality out of the box (with zero config so long as you
stick with those pesky conventions). I'm not sure how to help people
short-circuit this learning process even WITH documentation.

ESR's essay on asking the right questions is key to getting proper
help on this list:
http://www.catb.org/~esr/faqs/smart-questions.html#goal

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Ron Wheeler <rw...@artifact-software.com>]

On 18/04/2012 9:52 AM, Mark H. Wood wrote:
> On Tue, Apr 17, 2012 at 02:40:53PM -0400, Thiessen, Todd (Todd) wrote:
>> Good read.
>>
>> Documentation can be much better, but I suppose it is up to us as community members to make that happen. Maven isn't owned by anyone.  The guys at Sonatype have done a good job of posting various blogs.  If anyone has the time and desire I am sure she/he could pull many of these various tid bits of good practices into one coherent doc.
>>
>> I think it says something that it has not been done yet.  While everyone says it would be great to have, clearly no one has felt strongly enough about it (yet) to make it happen.  It is more of a very nice to have than a hard and fast requirement.
> Or, perhaps no one who feels strongly about it also feels he
> understands it well enough to write something worth reading.  I could
> write reams of misleading rubbish but what purpose would that serve?
>
> I've written documentation for other people's code.  It's exhausting,
> incredibly time-consuming, and often unsatisfactory.  The whole reason
> I wanted documentation was because I didn't understand the product --
> if I were in a position to document it well, I wouldn't need the
> documentation so badly!
>
I feel the same way.

I have written some blog posts (http://blog.artifact-software.com/tech)  
about things that we now understand and would propose our solutions as 
Best Practices for consideration by others who might be in a similar 
situation.

I have not completely read all of the books and reference materials from 
Sonatype and the Maven project, so I am not sure that all of the 
criticism of documentation is justified.
The Maven site is not the most friendly place to start as a new Maven 
user but it is not the only resource.

Perhaps the community should try to come to a consensus about the books 
and recommend one as the "best" starting point for a new user and one as 
the best place to find "Best Practices".

Perhaps some Maven experts might be interested in offering a series of 
short low cost webinars for new people that run on a regular basis.

Ron

-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: The Maven Way

["Mark H. Wood" <mw...@IUPUI.Edu>]

On Tue, Apr 17, 2012 at 02:40:53PM -0400, Thiessen, Todd (Todd) wrote:
> Good read.
> 
> Documentation can be much better, but I suppose it is up to us as community members to make that happen. Maven isn't owned by anyone.  The guys at Sonatype have done a good job of posting various blogs.  If anyone has the time and desire I am sure she/he could pull many of these various tid bits of good practices into one coherent doc.
> 
> I think it says something that it has not been done yet.  While everyone says it would be great to have, clearly no one has felt strongly enough about it (yet) to make it happen.  It is more of a very nice to have than a hard and fast requirement.

Or, perhaps no one who feels strongly about it also feels he
understands it well enough to write something worth reading.  I could
write reams of misleading rubbish but what purpose would that serve?

I've written documentation for other people's code.  It's exhausting,
incredibly time-consuming, and often unsatisfactory.  The whole reason
I wanted documentation was because I didn't understand the product --
if I were in a position to document it well, I wouldn't need the
documentation so badly!

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.

RE: The Maven Way

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

> I'm tackling the topic on my blog in upcoming weeks.  The first thing
> I'm going to talk about is how Maven expects all dependencies to be
> handled via repositories, and how to make non-standard artifact types
> work like this, such as custom assemblies, etc.

Good stuff sir. I tip my hat to you.

I am wondering if it would be useful to put your work on a more official central maven location?  Blogs are great but they tend to reflect the views of a single individual. We almost need some kind of official maven wiki where we can add things and have a few volunteers that could vet.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Ron Wheeler <rw...@artifact-software.com>]

On 17/04/2012 2:47 PM, Chad.Davis@emc.com wrote:
>
>> Good read.
>>
> Thanks.
>
>> I think it says something that it has not been done yet.  While everyone says
>> it would be great to have, clearly no one has felt strongly enough about it
>> (yet) to make it happen.  It is more of a very nice to have than a hard and fast
>> requirement.
> I'm tackling the topic on my blog in upcoming weeks.  The first thing I'm going to talk about is how Maven expects all dependencies to be handled via repositories, and how to make non-standard artifact types work like this, such as custom assemblies, etc.

This would be good to add to the Maven site. It is the kind of 
information that is lacking.

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

RE: The Maven Way

[Ch...@emc.com]

> Good read.
> 
Thanks.

> I think it says something that it has not been done yet.  While everyone says
> it would be great to have, clearly no one has felt strongly enough about it
> (yet) to make it happen.  It is more of a very nice to have than a hard and fast
> requirement.

I'm tackling the topic on my blog in upcoming weeks.  The first thing I'm going to talk about is how Maven expects all dependencies to be handled via repositories, and how to make non-standard artifact types work like this, such as custom assemblies, etc.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: The Maven Way

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

Good read.

Documentation can be much better, but I suppose it is up to us as community members to make that happen. Maven isn't owned by anyone.  The guys at Sonatype have done a good job of posting various blogs.  If anyone has the time and desire I am sure she/he could pull many of these various tid bits of good practices into one coherent doc.

I think it says something that it has not been done yet.  While everyone says it would be great to have, clearly no one has felt strongly enough about it (yet) to make it happen.  It is more of a very nice to have than a hard and fast requirement.

> -----Original Message-----
> From: Chad.Davis@emc.com [mailto:Chad.Davis@emc.com]
> Sent: Tuesday, April 17, 2012 2:32 PM
> To: users@maven.apache.org
> Subject: RE: The Maven Way
> 
> 
> > You are not alone in that.  Especially since the most valuable single
> bit of
> > advice one can give a new Maven user is:  "if you don't do things
> Maven's
> > way, Maven will fight you and Maven will win."
> >
> > People extol the virtues of "convention over configuration", but
> where is the
> > compact definitive specification of The Conventions?
> >
> 
> Interestingly, I just wrote a detailed blog entry about the irony of a
> CoC tool with a body of documentation that documents the configuration
> rather than the conventions.  It's kind of darkly humorous if you think
> about it.  The configuration is the way to get in trouble with maven,
> but it's the only thing documented.
> 
> In case you're interested:
> 
> http://zeroinsertionforce.blogspot.com/2012/04/maven-does-not-suck-but-
> maven-docs-do.html
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: The Maven Way

[Ch...@emc.com]

> You are not alone in that.  Especially since the most valuable single bit of
> advice one can give a new Maven user is:  "if you don't do things Maven's
> way, Maven will fight you and Maven will win."
> 
> People extol the virtues of "convention over configuration", but where is the
> compact definitive specification of The Conventions?
> 

Interestingly, I just wrote a detailed blog entry about the irony of a CoC tool with a body of documentation that documents the configuration rather than the conventions.  It's kind of darkly humorous if you think about it.  The configuration is the way to get in trouble with maven, but it's the only thing documented.

In case you're interested:

http://zeroinsertionforce.blogspot.com/2012/04/maven-does-not-suck-but-maven-docs-do.html



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

["Mark H. Wood" <mw...@IUPUI.Edu>]

On Tue, Apr 17, 2012 at 07:12:26AM -0700, Eric Kolotyluk wrote:
> I also recommend taking the Sonatype training courses - especially if 
> you are a software architect.
> 
> There is a lot to be said when you can ask question as the instructor is 
> going over the material.
> 
> However, you are right, if someone were to write a book called the "The 
> Maven Way" in the style you suggest, I would certainly be interested in 
> buying a copy.

You are not alone in that.  Especially since the most valuable single
bit of advice one can give a new Maven user is:  "if you don't do
things Maven's way, Maven will fight you and Maven will win."

People extol the virtues of "convention over configuration", but where
is the compact definitive specification of The Conventions?

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
What is obvious to A may be not so obvious to B and downright
ridiculous to C. -- Asimov

Re: The Maven Way

[Eric Kolotyluk <er...@gmail.com>]

I also recommend taking the Sonatype training courses - especially if 
you are a software architect.

There is a lot to be said when you can ask question as the instructor is 
going over the material.

However, you are right, if someone were to write a book called the "The 
Maven Way" in the style you suggest, I would certainly be interested in 
buying a copy.

Cheers, Eric

On 2012-04-17 7:00 AM, Markku Saarela wrote:
> Hi,
>
> I recommend two "books" from Sonatype, Maven by Example 1) and Maven 
> Cookbook 2)
>
> 1) http://www.sonatype.com/index.php/Support/Books/Maven-By-Example
> 2) http://www.sonatype.com/index.php/Support/Books/The-Maven-Cookbook
>
> Markku
> On 17.4.2012 16:55, Wolf Geldmacher wrote:
>> Hi list,
>>
>> a simple question with (hopefully) a simple answer:
>>
>>     Is there some coherent documentation of "the Maven way"?
>>
>> I'm *not* looking for:
>> * documentation of the Maven syntax
>> * documentation of Maven plugins
>> * Maven reference documentation
>> * "Use the Source, Luke!" style of advice
>>
>> What I'm looking for is:
>> * a collection of patterns / anti-patterns in the use of Maven,
>> * documentation on the "Do's and Dont's" when using Maven,
>> * documentation of the best practices implemented by Maven,
>> * documentation of basic assumptions in Maven.
>>
>> I'm being bitten by gotcha's that spring up at inconvenient times
>> and *then* being told that I've strayed from "The Way"; I'd rather
>> follow some road signs upfront than find myself confronted with
>> scathing dogs in some lonely backyard that I happen to stumble into.
>>
>> Something along the lines of Chapter 3.6 of "Maven: The Complete
>> Reference", which sets out to "... distill some of this knowledge to
>> help you adopt best practices from the start without having to wade
>> through years of discussions ..." but then, unfortunately, only covers
>> two (Dependency Grouping and Multi-module vs. Inheritance).
>> Similar to this, just much more complete and with some
>> background/rationale thrown in, if possible.
>>
>> Pointers anyone?
>>
>> Pretty please?
>>
>> Regards,
>> Wolf
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: The Maven Way

[Martin Höller <ma...@xss.co.at>]

On 17 Apr 2012, Markku Saarela wrote:

> Hi,
> 
> I recommend two "books" from Sonatype, Maven by Example 1) and Maven 
> Cookbook 2)
> 
> 1) http://www.sonatype.com/index.php/Support/Books/Maven-By-Example
> 2) http://www.sonatype.com/index.php/Support/Books/The-Maven-Cookbook

There is also "Apache Maven 2: Effective Implementations" from Brett
Porter [1], which basically describes the maven way most of the time.

The disadvantage of this book is, that it's quite old and the maven way
sometimes changed over time.

hth,
- martin

[1] http://www.packtpub.com/apache-maven-2-effective-implementation/book

Re: The Maven Way

[Markku Saarela <ma...@pp6.inet.fi>]

Hi,

I recommend two "books" from Sonatype, Maven by Example 1) and Maven 
Cookbook 2)

1) http://www.sonatype.com/index.php/Support/Books/Maven-By-Example
2) http://www.sonatype.com/index.php/Support/Books/The-Maven-Cookbook

Markku
On 17.4.2012 16:55, Wolf Geldmacher wrote:
> Hi list,
>
> a simple question with (hopefully) a simple answer:
>
>     Is there some coherent documentation of "the Maven way"?
>
> I'm *not* looking for:
> * documentation of the Maven syntax
> * documentation of Maven plugins
> * Maven reference documentation
> * "Use the Source, Luke!" style of advice
>
> What I'm looking for is:
> * a collection of patterns / anti-patterns in the use of Maven,
> * documentation on the "Do's and Dont's" when using Maven,
> * documentation of the best practices implemented by Maven,
> * documentation of basic assumptions in Maven.
>
> I'm being bitten by gotcha's that spring up at inconvenient times
> and *then* being told that I've strayed from "The Way"; I'd rather
> follow some road signs upfront than find myself confronted with
> scathing dogs in some lonely backyard that I happen to stumble into.
>
> Something along the lines of Chapter 3.6 of "Maven: The Complete
> Reference", which sets out to "... distill some of this knowledge to
> help you adopt best practices from the start without having to wade
> through years of discussions ..." but then, unfortunately, only covers
> two (Dependency Grouping and Multi-module vs. Inheritance).
> Similar to this, just much more complete and with some
> background/rationale thrown in, if possible.
>
> Pointers anyone?
>
> Pretty please?
>
> Regards,
> Wolf
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org