[...]
> 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
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:
>
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
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
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
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
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
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
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
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"
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.
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
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
> 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
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
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
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
20 matches
Mail list logo
