I've been stewing on this for a bit and while I think some of these
things are a "didn't know better/didn't know about that option", there
are some valid complaints in here.

ORDER OF TASKS

There are plenty of plugins - both available via repo1 and internally
developed here that would be much better served if we could bind them to
a particular time frame of a lifecycle goal.  For example - why does the
packaging type of ear care if the ejbs have been built yet because it
has dependencies on them?  Too often I think it'd be nice to choose to
bind the beginning or end of a goal - say, end of package stage for
anything to do with an ear.  Or maybe you want something between
process-resources and compile.  Or at the end of compile only.

TOO SLOW

Even with minimal reporting plugins configured, a 10 min build can
double or triple in time if you run mvn site.  Some of this is due to
known bugs (re-running the tests with instrumented classes for example),
the rest I can't explain.

EXTENDING MAVEN

This is a mixed bag - I shouldn't have to resort to google code search
to see how some constants/properties/methods/classes/etc. are used.   It
should be clearly spelled out in the documentation (which is isn't).
Additionally, if you'd LIKE to extend maven, the best way to do so is to
set up your own repository - forget about the "provided" option (lots of
branching/deleting/etc of jars that you shouldn't have to manage in this
way).

CONTRIBUTING

I can't say I've filed a billion bugs against maven, but I will agree
that it's like throwing change into a wishing well.  When you do find an
issue, more often than not, you're asked to file a bug only to be told
to use the latest of some plugin and that has the fix/behaves better.
This leads to not specifying versions in the plugin configuration which
is VERY dangerous.  It's wild when a build starts failing and you know
nothing has changed w/r/t the assembly/packaging instructions that
you're aware of.

DOCUMENTATION

Still poor - why not enforce some standards here?  There are standards
everywhere else.  Look at the site:stage goal output:

http://maven.apache.org/plugins/maven-site-plugin/stage-mojo.html

locales         String  -       A comma separated list of locales
supported by Maven. The first valid token will be the default Locale for
this instance of the Java Virtual Machine.

Why not have those listed right there?  Not too long ago I asked about
how to specify a range or "latest" of a dependency - I was handed back a
link to a wiki I spent some time searching prior to asking the board.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to