hc-dev mailing list archives

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

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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

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


Mime
View raw message