Quantcast

The Maven Way

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Ron Wheeler
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<[hidden email]>  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   [hidden email]
>>> What is obvious to A may be not so obvious to B and downright
>>> ridiculous to C. -- Asimov
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: The Maven Way

Thiessen, Todd (Todd)
In reply to this post by Anders Hammar
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Mark H. Wood
In reply to this post by Thiessen, Todd (Todd)
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   [hidden email]
Asking whether markets are efficient is like asking whether people are smart.

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Ron Wheeler
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: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Wayne Fay
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Curtis Rueden
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Ron Wheeler
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<[hidden email]>  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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Eric Kolotyluk
In reply to this post by Curtis Rueden


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 [hidden email]

>
>
> 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<[hidden email]>  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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Barrie Treloar
In reply to this post by Thiessen, Todd (Todd)
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Ron Wheeler
In reply to this post by Eric Kolotyluk
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 [hidden email]
>
>>
>>
>> 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<[hidden email]>  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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Barrie Treloar
In reply to this post by Barrie Treloar
On Thu, Apr 19, 2012 at 9:02 AM, Barrie Treloar <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Eric Kolotyluk
In reply to this post by Ron Wheeler
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 [hidden email]
>>
>>>
>>>
>>> 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<[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Mark H. Wood
In reply to this post by Wayne Fay
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   [hidden email]
Asking whether markets are efficient is like asking whether people are smart.

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Eric Kolotyluk
In reply to this post by Barrie Treloar
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
[hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

martin.eisengardt
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Wolf Geldmacher
In reply to this post by Eric Kolotyluk
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
> [hidden email] 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Mark H. Wood
In reply to this post by martin.eisengardt
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   [hidden email]
Asking whether markets are efficient is like asking whether people are smart.

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Maven Way

Ron Wheeler
In reply to this post by Wolf Geldmacher
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
>> [hidden email] 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
12
Loading...