| On 01/21/2014 10:36 PM, Doug Schaefer
      wrote:
 
      
      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.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). 
 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,
 
 |