Andy,

You said, "My *personal* opinion about why *I* find maven so hard is the
complete
mental disconnect between the lifecycle phase (task) and the
configuration, coupled with the voodoo of 'convention'."

I think thats an amazingly concise description of what is hard about Maven.

I do think the solution is to document things like recipes.

I don't know why adding some sugar to spaghetti sauce makes it better (for
my family) but its in the recipe and I don't have to know.

I don't have to know why that magic bit of XML works but if I want to use
Ant to generate some source code (because my code generator has an Ant task)
then I put in this and, maybe, change the Ant target and the 'generated
sources' folder.

<build>
  <plugins>
  <plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <executions>
      <execution>
        <id>gensrc</id>
        <phase>generate-sources</phase>
        <configuration>
          <tasks>
            <ant antfile="build.xml" dir="." target="generate"
inheritRefs="true" />
          </tasks>
          <sourceRoot>${project.build.directory
}/generated-sources/java</sourceRoot>
        </configuration>
        <goals>
          <goal>run</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
  <plugins>
<build>

I have enough pom.xml files to be able to go steal bits of them when I need
to do something like that. I have begun to understand how that all fits into
the lifecycle and why it works. I suspect there is an example somewhere on
the web site or in this user list where I got it originally, before I had a
clue why it worked.

I think, that is the reason, this thread has seen so much emphasis on
collecting FAQ entries. These little examples make it easy to make your
build work and you don't have to know why.

Perhaps a POM editor that had a bunch of XML snippets would be useful. Then
the Maven user would need even less information on the internals. (That idea
is not patented. Feel free to implement it if you want.) Of course, some
problems would require close attention to how Maven works and after all the
easy build problems were solved and all the non-standard stuff was converted
to Maven standards the user would have an investment in Maven that would
make it worth figuring out the hard things.

(That does ignore the fact that sometimes you decide to go against Maven
conventions because you decide to follow the conventions for some other
tool. Some that come to my mind are Eclipse, RAD and its derivatives,
MyEclipse and pretty much any Application Server.)

Thanks.

-- Lee

On 9/27/07, andy law (RI) <[EMAIL PROTECTED]> wrote:
>
> > >
> > > This thread has highlighted the fact that the documentation doesn't
> > > help new users of maven, or users of maven who have no desire to
> > > become experts. Just dumping yet more documentation on this
> > group of
> > > people isn't going to answer their questions.
> >
> > There are some questions that come up repeatedly on this ml.
> > If you've subscribed for more than a few weeks and read most
> > emails, you've already seen what I'm talking about. My
> > personal pet peeve is the compiler target/source issue.
> >
> > In many of these common cases, the issue has been documented.
> > Usually in the FAQ and in the Wiki and in the plugin docs
> > too. Also it is documented well in Google and in the ml
> > archive. And yet people still ask this question every 5-10
> > days and sometimes more often.
> >
> > How can you help people who ask this question (and others
> > like it)? I agree that _more_ documentation is not
> > necessarily the magic bullet that many believe it is.
>
>
> The argument that "some people don't read documentation so there is no
> point in writing any more" is a non-sequitor. Please don't fall into
> that trap.
>
> My *personal* opinion about why *I* find maven so hard is the complete
> mental disconnect between the lifecycle phase (task) and the
> configuration, coupled with the voodoo of 'convention'. In ant, tasks
> seem to me to be the top-level view. In maven, goals and executions are
> embedded waaaay down the configuration and are necessary/unnecessary
> depending on what bindings were configured by annotations in the code
> that the developer thought were sensible (If I understand the
> documentation that I've read correctly :o} ). In maven, I tend to reach
> where I want to get in a similar fashion to a friend who got given a C++
> project some time ago. He said to me that he finally got it all to
> compile and run by "throwing various combinations of asterisks at it at
> random until I got something that worked". My pom file editing often
> feels like that.
>
> Later,
>
> Andy
>
> -------------
> Yada, yada, yada...
>
> Roslin Institute is a company limited by guarantee, registered in
> Scotland (registered number SC157100) and a Scottish Charity (registered
> number SC023592). Our registered office is at Roslin, Midlothian, EH25
> 9PS. VAT registration number 847380013.
>
> The information contained in this e-mail (including any attachments) is
> confidential and is intended for the use of the addressee only.   The
> opinions expressed within this e-mail (including any attachments) are
> the opinions of the sender and do not necessarily constitute those of
> Roslin Institute (Edinburgh) ("the Institute") unless specifically
> stated by a sender who is duly authorised to do so on behalf of the
> Institute.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
-- Lee Meador
Sent from gmail. My real email address is lee AT leemeador.com

Reply via email to