On 6 June 2013 15:43, Oleg Kalnichevski <[email protected]> wrote: > 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.
I find that OK. >> > 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? I think it's enough for us to hold a vote. >> > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
