groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: Binary compatibility fixed + Kotlin DSL
Date Wed, 20 Mar 2019 12:52:53 GMT
I am probably -0 on the change at this time. I don't see this as a language
threat issue
but we are very keen to make the barrier to entry as low as possible for
new contributors.
Over time, I suspect more folks will have picked up some Kotlin exposure,
so this
wouldn't be as strong as a -1 from me.

Cheers, Paul.

On Wed, Mar 20, 2019 at 5:22 PM C├ędric Champeau <cchampeau@apache.org>
wrote:

> Hi folks,
>
> Some of you have noticed that I have fixed the binary compatibility
> reports on master. I also fixed checkstyle and CodeNarc, which were failing
> to execute. I did not, however, fixed the many errors we see when running
> those, nor the ones with spotbugs. It's a bit annoying because it makes the
> "build" task fail, but we can live with that for some time.
>
> Some of you noticed, because this is the first time I introduce a Gradle
> Kotlin DSL script for this. Let me explain why: first, it gives a better
> user experience: completion in the IDE is working, and you can navigate to
> sources. Second, its syntax is so close to the Groovy one that if I had
> replaced .kts with .groovy, I bet hardly anyone would have noticed.
>
> To me it's a step towards a better build: we should'nt see this as a
> threat to Groovy, and I'm not saying that it wouldn't have been possible to
> achieve the same thing with Groovy, but this is the reality now: the Kotlin
> DSL for Gradle gives a better UX than the Groovy one. I think it' going to
> be particularly important for newcomers in the future. And as I am the main
> maintainer of the build, it's also important to me, given the little amount
> of time I can give to this project. My plan is to migrate the build to
> Kotlin, slowly but surely, and as part of this effort, remove a lot of the
> bad practices we're using, or internal APIs. Publishing for example is in a
> terrible state.
>
> But coming back to this build script: take a look at it and tell me if
> it's not as clear, or even more readable than the Groovy one (you can
> compare with the old binarycompatibility.groovy file). Also, I strongly
> believe that's an opportunity for us to learn from Kotlin and maybe borrow
> some if its features
>
> So I'm asking you to vote on *keeping* this .kts file, and actually
> migrating the build incrementally. If you see Kotlin as a threat, I'd
> understand but would be disappointed.
>
> Thanks,
>

Mime
View raw message