[...]
> I disagree a bit. It's not only about code completion, but also about jumping
> to the definitions (and the documentation).
true, though.. I must say I found the gradle documentation for tasks quite
lacking... maybe looking at the code would give better insights, so jumping
might be mo
On Wed, Apr 3, 2019, 01:56 Jochen Theodorou wrote:
> Hi,
>
> I have never used it, but what you write is within my expectations. We
> should not forget we are *still* (after years) talking about an early
> version of the DSL.
>
> My experience with other people doing gradle is more like this:
> T
Hi,
I have never used it, but what you write is within my expectations. We
should not forget we are *still* (after years) talking about an early
version of the DSL.
My experience with other people doing gradle is more like this:
There is a problem, we search on stackoverflow and copy+paste the
s
On Fri, Mar 22, 2019 at 11:37 AM Thibault Kruse
wrote:
>
> While that is obviously true, the question is not as simple. The
> groovy community must make a recommendation to all gradle projects in
> the world about whether to use Gradle-Groovy-DSL or Gradle-Kotlin-DSL.
Answering myself, after havi
It was of course not directed against Cédric, I was just making a point
for what I consider the best interests of Groovy.
I have already replied to Thibault Kruse that it is evident Cédric has
been pondering this move for years. I don't envy the position he
evidently has been in for the last yea
First of all it would be nice of Cedric to explain what post it was that
triggered him like this. I still have trouble reading that post from MG
like that.
And sure there is a conflict of interests here, between Gradle and
Groovy. Gradle wants the best support for their developers for the
cheap
On 22/03/2019 03:37, Thibault Kruse wrote:
On Thu, Mar 21, 2019 at 11:03 AM MG wrote:
Maybe I am missing something, but it seems to me that Jetbrains could have put
their weight behind Groovy, especially its static part, gaining all the
benefits with regards to tool support / Intellisense
On 22.03.19 03:54, Thibault Kruse wrote:
Also, BTW, not sure why Cedric did not post this on this mailing list,
but he just announced in his blog:
https://melix.github.io/blog/2019/03/goodbye-groovy.html
"I’m stepping down from the Apache Groovy project
Today is a very sad day. I’ve decided to r
Hi Thibault,
I think the Groovy community has always shown itself to be embracing
of the entire JVM ecosystem and beyond. And for the most part has shown
itself to be very respectful of other community members. I don't think
anything
has changed. The pace of progress has slowed a little and we are
Also, BTW, not sure why Cedric did not post this on this mailing list,
but he just announced in his blog:
https://melix.github.io/blog/2019/03/goodbye-groovy.html
"I’m stepping down from the Apache Groovy project
Today is a very sad day. I’ve decided to resign from the Apache Groovy
PMC, as well a
On Thu, Mar 21, 2019 at 11:03 AM MG wrote:
>
> Maybe I am missing something, but it seems to me that Jetbrains could have
> put their weight behind Groovy, especially its static part, gaining all the
> benefits with regards to tool support / Intellisense they now claim for Kotlin
I believe in t
If there are known issues with the current build scripts, can they be
enumerated so that a plan for fixing by community member(s) can be described?
It seems if Cedric was not the only developer making changes to the build
scripts, some of the pressure would be relieved.
There seems to be enough desire to keep the files as Groovy, so I'll revert
for the time being. We can look at this issue again a bit further down the
track and see if there is a greater level of comfort in switching.
Cheers, Paul.
On Thu, Mar 21, 2019 at 12:03 PM MG wrote:
> Hi Cédric,
>
> I
Hi Cédric,
I think that It should be obvious that there is a conflict of interests
here, and that agreeing to you suggestion looks to be worse for Groovy
than the very old saying by the original Groovy author about "never
having done Groovy if he had known a certain other language existed"
(a
Well I think I disagree with most of what you just said. And Gradle Inc
will not deprecate the groovy support anytime soon. I'm well placed to know
it's not even in discussion. The only thing that I see could lead to such a
decision would be that groovy doesn't run on future versions of the JVM.
Le
I don’t know what do you imply that I am trying to hide.
I think:
- Gradle Groovy DSL helps Groovy adoption and thus survival.
same as Geb DSL on top of Selenium helps Groovy adoption and thus survival.
I think if everyone moves to Kotlin DSL, Gradle Inc will lose interest in
maintaining Gr
And do you honestly think that trying to hide that by not using the Kotlin
DSL would change anything?
Le mer. 20 mars 2019 à 21:45, Sergio Del Amo a
écrit :
>
> I do in fact see this as at least a minor threat. If Groovy itself can't
> even manage to use the Gradle Groovy DSL, what hope remains
> I do in fact see this as at least a minor threat. If Groovy itself can't
> even manage to use the Gradle Groovy DSL, what hope remains for the survival
> of the Groovy DSL?
Agree. I see a threat at least to Gradle Groovy DSL survival and probably to
Groovy in general. One may reason: If th
I tried to get some info from Gradle on adding Eclipse DSLD for Gradle and they
scoffed at me. They said it was a multi-person, multi-year effort so why even
try. I was able to get some very basic support without that much effort. It
could be moved forward and probably ported to IntelliJ as w
Just for curiosity... the Gradle team says that Kotlin DSL support was
introduced because (as you said) IDE support is then available for
editing build scripts.
But if this is the only (or at least the main...) advantage, why not
collaborating on investing into improving Groovy support in IDEs i
My point is that you have _no_ support with the current Groovy DSL. The new
one _does_ give support. It's MUCH easier for newcomers. Just open the
script, completion pops out. So I disagree that it makes things less
maintainable, I'm convinced of the opposite.
Le mer. 20 mars 2019 à 15:16, Daniel.
Hi Cédric,
At first, thanks a lot for your maintaining the build scripts, which make
our life easy.
As for the maintainability, -1 from me.
Since Groovy DSL can handle the build well and it is the default DSL for
gradle(even in the IntelliJ IDEA), it's better to avoid introducing a new
DSL. I am
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
23 matches
Mail list logo
