On 13/10/2010 7:24 PM, Barrie Treloar wrote:
On Thu, Oct 14, 2010 at 9:34 AM, Graham Leggett<[email protected]> wrote:
[del]
As soon as you need to start documenting things, you're starting to go
wrong. Practically, you may have to document some things, such as where to
get certificates for access, but you should strive to keep this
documentation to zero or as near zero as humanly possible.
Documentation costs money to write, it costs money to read, it costs money
when someone missed the vital bit of the documentation and things go wrong.
This is where the "configuration by convention" really shines. If you know
the convention, you don't need to waste time with documentation,
troubleshooting, customisation, you just get on with it.
While in principle I agree, it assumes that the developer has
bootstrapped knowledge about how maven does stuff.
This is where people need to read the books on maven development.
So once they have read (and understood) the books at
http://maven.apache.org/articles.html then your statements become
true.
Maven does lack a "best practices" documentation that sorts out "what
you can do with Maven" from "what you should do with Maven".
You can do damn near anything with but most of these things are evil and
work against your best interests.
This is because my experience has been that a developer using Ant has
to learn Ant in order to get the build working, they become a
semi-expert or at least an advanced Ant user.
But those that use Maven can stay at a very basic level of Maven
understanding, "mvn install" and you are done.
The down side is that because they get stuck at a basic level it
becomes more difficult to become an advanced user.
Not becuase becoming an advanced user is hard, but they are not forced
to become one.
I do not want to become an expert Maven user. I have a very large portal
in production made up of over 60 Mavenize projects.
I just need Maven to work and do its thing without me having to bend it
to some crazy workflow that I used before we adopted Maven.
I do not want to use any more plug-ins than I have to (3 so far) and I
certainly do not want my team writing plug-ins or Ant procedures to
build the web services, servlets and stand-alone applications that we
need, if minor changes to our mindsets will avoid the need.
So it does mean that they lean on the local maven expert for knowledge
and when things go wrong have more trouble working out why and how to
fix it.
One should not try to force bad workflow practices onto Maven.
If one does things in a sensible way, a team does not need an Maven expert.
Having been the Ant expert and attempting to build the "one ant build
file for any project", I was finding this more and more difficult and
complex to achieve and maintain.
I found Maven 2 a few years back and I've never regretted the
decision, and as a last resort (because I'm too lazy to write a plugin
or the solution is too once off) I can always write an Ant snippet to
do some work that maven will run for me but not like the original
poster who started this thread off.
Ant is a wonderful programming language that I have also used in the
past but I am not going to make my Java developers learn it in order
build Java applications.
I want them to be Java, Spring, Hibernate and application design experts
and any time they spend on warping Eclipse/STS or the build process is
wasted.
Maven and Eclipse/STS has done what we need out of the box using the GUI
POM editor.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
