| Re: [cbi-dev] Build tool comparison |
Frankly the double maintenance of the version the the MANIFEST.MF and the pom.xml should be avoided. AFAIK Tycho cannot handle that due to the Maven life cycle.
Hence I hope for a better Maven with Polyglot Maven or for good Gradle support.
Best regards, Lars
On 02/05/2014 10:58 AM, Andrew Ross wrote:
Thanks for this Mickael, great & helpful post.
+1
Very helpful. "A-ha!" helpful.
Denis
On 05/02/14 02:25, Mickael Istria 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.
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,
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cbi-dev