On Tue, 30 Sep 2014 01:39:49 +0200, clay <claytonw...@gmail.com> wrote:
On Monday, September 29, 2014 2:30:38 AM UTC-5, fabrizio.giudici wrote:
It depends. When you have heterogeneous groups where you have to enforce
some order, declarative is better because you can force people to stick
with a standard way to do things.
Maven gives a very superficial illusion of forcing declarative builds.
However, it is common to see imperative logic in Maven builds in the form
of ant tasks or plugins. Some builds really do justify imperative script
logic, Gradle just supports this with an actual programming language.
That's precisely the point for which Gradle is a disaster. I have five
years of experience with Maven now and there's no illusion. Rather I can
say that there's a clear barrier between things that are declarative and
things that are imperative (plugins or occasional ant tasks)...
Maven is designed with fixed build tasks and a fixed pre-defined
lifecycle.
Many projects have genuine need for custom build steps. Maven expects you
to rig your custom build steps into the predefined steps. Gradle lets you
define new tasks and task dependencies as you need them.
... which is precisely why Maven is better than Gradle. I cannot count the
projects that I've done with Maven and with the proper assistance they all
fit in the Maven lifecycle. There were just two exceptions: an ant task to
invoke iac for a period of time in which there was a bug in the Maven
plugin and a project that had a long history before being mavenized and
that needed a customization in creating some artifacts for functional
tests. In both cases the ant tasks have been carefully designed by the
expert (me) and placed in the superpom. Nobody had to know that there was
an ant task invoked, nor had the chance of tweak it. In other words, with
a proper design of inheritance you can confine the very few customization
in a place where nobody touches them.
On the contrary, make it easy to write custom scripts and you're soon in a
storm of shit. My customers precisely appreciated that, after the
mavenization, tons of custom scripts (usually made with Ant, in which
everybody had the good idea to incrementally add tweaks) were thrown away.
If you have a standard build, declarative build definitions are great.
Gradle and SBT really don't stop that. In fact, they make simple
declarative builds much more concise than Maven's mountains of XML.
I'm not obsessed by tags and none of my customers are. In the end what one
wants in a project is to reduce costs (time and money) and a few xml tags
don't really make a difference here. Xml obsession is just conference
hype. BTW, with Maven 3 poms could be written in json, so Xml is no more a
constraint, but as far as I know nobody felt the need to do that.
--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to javaposse+unsubscr...@googlegroups.com.
To post to this group, send email to javaposse@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse.
For more options, visit https://groups.google.com/d/optout.
