On 01/21/2014 10:36 PM, Doug Schaefer
wrote:
Mind you, I would think the thing you’re building would have
something to do with it. Does gradle have good support for
building Eclipse plugins like Maven does with Tycho? (And I
won’t get into the native world where we have a similar mess of
choices to the Java people).
FYI, at last EclipseCon France, I had the opportunity to make a
tutorial together with Jeff Maury about Tycho. Most people who
didn't know Tycho (or built tools in general) were impressed by the
ability for Tycho to work with a few concepts to understand (target
platforms + pom files), and it's ability to easily plug interesting
stuff on it, such as surefire, jacoco or Sonar.
But some people immediately came after the talk to ask whether there
was some similar development available on Gradle (basically
integration of p2 as dependency resolver). Those people were quite
enthusiastic about Gradle which according to them is much simpler
that Maven. There is somewhere a piece of work of a Gradle plugin
for PDE/RCP project (https://github.com/gboissinot/gradleplugins)
but AFAIK it's not very usable.
I've seen some Gradle scripts, and I don't see them as a big
improvement over Maven. The main difference is that instead of XML
you have a DSL which is more concise in term of characters, but in
the end, you have the same amount of stuff to configure (the payload
is the same, just the format change). A big benefit of Gradle IMO is
that it automatically allows Groovy as _expression_ language, which is
pretty useful in some cases. The drawback of _expression_ language is
that it tends to make you build descriptor a big piece of script,
which is not that case with Maven and its pure-descriptive approach.
So when using Groovy in Gradle, you'd have to use or write Mojo with
Maven. The benefit of Maven mojos is that they can be shared.
Maven drives to homogeneity between pom files because of its
constraints; I'm feeling Gradle re-enables the big pitfall of Ant
with files quickly becoming big pieces of script readable and
maintainable by only the original author... IMO, conventions and
good practices are not enough to provide easy maintenance, I have
more trust in the benevolent dictatorship of Maven and conformance
to strong constraints.
So I'm not going to be an early adopter of Gradle. I have more hope
in having a less verbose Maven, using something else than xml (such
as Yaml) and with the ability to look in other files (MANIFEST) for
data to avoid duplication and derive the effective-pom; but with a
strict lifecycle and some strict constraints.
Cheers,
|