@IntelliJ's build system: We use IntelliJ Groovy build, and have very
vanilla requirements with regards to building our projects (basically
it's just a larger number of interdependent modules with a bunch of
artifacts), but alas even that does not work without a hitch: The
"build-repeatedly-magically-fails"-problem I described here a while ago
has (after years) thankfully disappeared, just to be replaced by a more
benign one, where any change in one of a couple of our central Groovy
modules makes the regular minimal rebuild fail, and we always have to
rebuild the failing module in its entirety in that case. We can only
live with it since those modules are relatively stable.*
Also Intellisense in the IntelliJ version we are currently using
(2019.3.1) gets confused after a short while, and will mark correct code
as invalid (as a weird workaround, one can comment out the "invalid"
part of the line, and when commenting it back in, IntelliJ will be back
on track most of the time).*
Which brings me to:
@"Another thing that comes to mind, JetBrains produces Kotlin, and
Kotlin competes with Groovy - figure that one out!"
Alas, yes. As I have said here back when the discussion about Gradle
Groovy vs Kotlin happened, there is an obvious conflict of interests
here - ideally you would want your IDE supplier to be as language
agnostic as possible, which, due to the introduction of and ongoing
investment in Kotlin, for Jetbrains is no longer the case.
I am still giving them the benefit of the doubt, but thinking back,
IntelliJ Groovy support used to be top notch, and nowadays it is
incomplete and suffers from quite a bit of problems. Hmmm...
In any case, even though the Groovy ecosystem is large & strong, in the
end we are small fry, since it seems obvious to me their actual goal is
not to replace Groovy, but over time to replace Java.
Then the #1 IDE and the #1 JVM language would come from one company in
Prague. Not my dream scenario, for sure, after Java and the JVM
landscape finally made big strides to being completely open source &
much more community driven... (if I wanted MS (i.e. Visual Studio** &
C#), I would not have returned to the JVM world from .NET in 2008)
Cheers,
mg
*None of that can be fixed by clearing the IntelliJ caches btw, we do
that on a regular basis.
**Ironically enough, ReSharper by Jetbrains, at least back then, used to
be the quintessential Visual Studio refactoring plugin back in 2008.
On 11/03/2020 19:36, Blake McBride wrote:
Hi MG,
The issues I've had with IntelliJ/JetBrains are general. IntelliJ is
probably the best IDE out there but rather than make it even better
they seem comfortable just staying a notch above the competition. I
guess they don't have to do better.
I've had issues with IntelliJ that are utterly and clearly wrong but
they say it is a "feature".
Other times I spend hours trying to get IntelliJ to do something that
ends up hidden deep in the bowels of IntelliJ rather than putting them
where someone would look for them. This causes hours of wasted time,
immense frustration, and needless contact with their support.
While their support is very responsive, they're too quick to
dismiss nearly every issue.
Often a clear bug is discovered but their attitude is that not enough
people use that feature so we're not going to fix it. This attitude
has been a big problem and might also be a factor in the Groovy issue.
Another thing that comes to mind, JetBrains produces Kotlin, and
Kotlin competes with Groovy - figure that one out!
I've always thought that NetBeans was the most intuitive IDE. Anytime
I want to do something I guess at where it is and - boom - there it
is! I also see they're really making an effort to upgrade it. I'll
be watching them.
IntelliJ, like most build systems, has a convention over configuration
attitude. While this works really really well when you are building a
conventional app, with either, when you try to drift the
slightest from the convention (with good reason!) a five-minute setup
can turn into weeks and constant headaches!! In order to get around
IntelliJ's and other build system's (Maven, Gradle, etc.) conventions,
I ended up writing my own build system. Problem is, I still need an
IDE for developing and debugging. I try not to use them for builds.
With regard to eclipse, personally, I've never worked with a worse IDE
than eclipse. eclipse:
1. the most unintuitive IDE I've ever used
2. the most buggy IDE I've ever used
3. the most out-of-date IDE I've ever used
4. the least supported IDE I've ever used
I've had a lot better luck with NetBeans!
A number of years ago I embarked, with a team, on a large Java
project. We started with eclipse. We had endless memory issues and
crashes. We then switched to NetBeans and used it without
incident for years. I eventually switched to IntelliJ because of a
promised feature. I spent a lot of time moving this project (10,000
classes!) to IntelliJ only to find that the promised feature is
extremely buggy. When I reported the problems JetBrains told me that
not enough people used the feature and they are no longer supporting it.
While IntelliJ's support of Kotlin will no doubt remain first-class,
my inclination is that Groovy will experience declining support by
JetBrains for the above reasons. Moving forward, you may have better
luck with NetBeans.
[rant over]
Thanks.
Blake
On Wed, Mar 11, 2020 at 12:33 PM MG <mg...@arscreat.com
<mailto:mg...@arscreat.com>> wrote:
Hi Blake,
first of all thank you, and all who voted since my post, for
taking the time, appreciated.
Second: Is your IntelliJ/Jetbrains experience directly tied to
Groovy or to issues in general ? The guy responsible for Groovy in
IntelliJ, Daniil Ovchinnikov, seems to need community created,
upvoted child tasks:
see for instance his comment on the "Support for Groovy 3 syntax"
issue on 5 Dec 2018 17:07:
"@Pradeep Bhardwaj don't worry, the work is in progress. Most of
Groovy 3 features are already supported, please see child tasks
and vote for some (or all) of them."
In any case upvoting is the only thing we can easily do. If this
has no effect, my team will have to look into the Eclipse option
again - great, after we convinced management that paying for
IntelliJ was the way to go :-/
mg
On 11/03/2020 17:50, Blake McBride wrote:
Although I will vote up the Groovy issue you detail, being a
long-time IntelliJ user, I can tell you first hand that upvoting
an issue at JetBrains has no effect I am aware of. I have seen
critical issues get hundreds of votes and remain untouched for
years. They do what, when, and how they like.
On Wed, Mar 11, 2020 at 11:27 AM MG <mg...@arscreat.com
<mailto:mg...@arscreat.com>> wrote:
Hi guys,
up to this point, the first issue I created two days ago (see
previous
post for link) has gotten zero votes - if no one is voting
for these
issues, then it makes no sense for me to put them up, so
please do not
only vote for the umbrella issue (which just got vote 37 - still
incredibly low given the large number of Groovy users out
there), but
for each individual issue as well.
Consider to not only vote for the features you yourself would
immediately use - all of these features were included after some
discussion, because they were considederd to make Groovy a
better
language, and some things need time to establish themselves,
but there
is no chance of that happening, if the most prevalent Groovy
IDE marks
the code as invalid and accordingly offers no
Intellisense/refactoring/etc support*.
Cheers,
mg
*I keep wondering what people new to Groovy think, if they
try to use a
feature introduced nearly 2 years ago, but their IDE marks it
as invalid
code...
