On Thu, 2013-06-06 at 15:24 +0100, sebb wrote: > On 6 June 2013 15:08, Oleg Kalnichevski <[email protected]> wrote: > > On Thu, 2013-06-06 at 08:57 -0400, Karl Wright wrote: > >> Can you elaborate as to what you feel are the advantages of gradle? Why do > >> you want to switch over? > >> > >> Karl > >> > > > > Both build frameworks have their pros and cons. There is enough material > > on the web specially after several high profile projects having moved to > > Gradle. > > > > I am quite fine with Maven itself but some its plugins are just plain > > horrible. One of which is the site plugin. > > +1 > > And the release plugin. >
And assembly. I just did not want to sound too negative about Maven. > > Now that we have to use > > SvnPubSub for web site publishing, Maven Site plugin simply causes more > > trouble and helping with the process. And here comes the main drawback > > of Maven for me as a HC release manager: one can do anything with Maven > > but nontrivial operations simply require creation of a custom binary > > plugin. > > I agree here. > > > The trouble with this approach in the context of ASF is that > > every little modification of deployment logic would require a bloody > > release vote. > > In Commons we agreed to use lazy consensus for Commons Parent pom updates. > > Since build helpers are not really part of the formal HC release, I > don't see why that approach should not be extended to ASF-specific > Maven plugins created for use in HC. > What does it take to adopt the same model for parent, notice-plugin and (to be created) hc-style-check? > > Gradle on the contrary provides a very rich scripting > > environment where almost anything can be done inside the build script. > > One Site plugin (or one Release plugin for that matter) simply cannot be > > coerced into covering all possible deployment scenarios without becoming > > an unmanageable abomination. > > You may well be correct there too. > > If a Maven build is not working correctly, it can be incredibly > difficult to establish the cause, and pretty difficult to fix (e.g. > writing plugins). > Customising Maven builds is much harder than with Ant. > > My only caveats with Gradle are: > - yet another tool to learn > - will it support all the functionality we need? > - will there be areas of Gradle that turn out to be really awkward? > This is all very true. However given that Spring, Hibernate, and recently Android moved to Gradle as their primary build tool, I expect there to be enough momentum to help deal with point 2 and 3. I would propose a very gradual and pragmatic approach: continue using Maven to build, test, install and deploy binary artifacts and evaluate Gradle as an alternative for building deployment packages and generating web site content. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
