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.    

Oleg



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


Mime
View raw message