hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Gradle for HC builds
Date Thu, 06 Jun 2013 14:43:12 GMT
On Thu, 2013-06-06 at 15:24 +0100, sebb wrote:
> On 6 June 2013 15:08, Oleg Kalnichevski <olegk@apache.org> 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.    


To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message