Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InteillJ stucks in recompiling with Grails 6.2.0 once groovy file changes #13525

Closed
ghostfox911 opened this issue Jun 18, 2024 · 10 comments
Closed

Comments

@ghostfox911
Copy link

Issue description

Environment

  • IntelliJ 2024.1.3
  • Grails 6.2.0
  • JDK openjdk-17.0.2

Previous with grails-6.1.2 everything works. When running grails-6.1.2 project in IntelliJ in debug mode IDE can auto recompile and re-run project once groovy file updates.

But after upgraded to grails-6.2.0 once groovy file updated IDE stucked in recompiling and never restarted project. You have to manully click on re-run button.

I tried to clear all caches and rebuild project but nothing helped.

Does anyone have same issue?

@duxnp
Copy link

duxnp commented Jul 17, 2024

I can't say if this is something that should be fixed by JetBrains or Grails, but I did figure out a workaround.

Instead of creating a Run/Debug Configuration using a Grails or Micronaut template, use a Gradle template and enter "bootRun" as the task.

@duxnp
Copy link

duxnp commented Jul 17, 2024

Also, you do of course still need developmentOnly("org.springframework.boot:spring-boot-devtools") in build.gradle

@ghostfox911
Copy link
Author

Also, you do of course still need developmentOnly("org.springframework.boot:spring-boot-devtools") in build.gradle

Thanks so much. This setting really fixed this issue.

BTW. Since some time IntelliJ cannot recognize grails project and we have to use gradle - application - bootRun. And also ctrl + alt + G cannot open grails command prompt. Any clues? Thanks in advance.

@duxnp
Copy link

duxnp commented Jul 18, 2024

Some of what we're talking about here probably belongs in the discussions section rather than issues section, or even the JetBrains YouTrack issue tracker.

With Grails 6.2.0, the current IntelliJ Grails plugin (version 241.14494.158) stopped working. This is why the Run Grails Command dialog doesn't appear when you press CTRL + ALT + G. A workaround for this is to add implementation org.grails:grails-shell:6.1.2 to the dependencies in the build.gradle file. This will get the Grails plugin mostly working again. It will recognize all the artefacts and give you all those nice features such as syntax highlighting, code completion, navigation, etc.

However, the Run Grails Command still won't work. It hasn't worked since 6.0.0. The dialog will appear when you press CTRL + ALT + G, but the commands won't run successfully. If you run "--version" from Run Grails Command, it will report "Grails Version: 6.1.2", but you'll see it's running the commands like this \AppData\Local\Temp\1\idea_arg_file1093355971 org.grails.cli.GrailsCli --version. This makes me think it's trying to use some old CLI code still left in grails-core or something as opposed to the newer CLI in grails-forge. If you try to run a command like "create-controller foo" you'll get an error like "Could not resolve all dependencies for configuration ':profile'.", but I think profiles don't exist anymore from Grails 6 onward.

There's a workaround for running Grails commands as well. The Run/Debug workaround is pretty transparent, however this workaround will be a bit disruptive to your workflow. This will involve running the commands manually from the terminal. Since there's no longer Grails wrapper, you'll have to install the new Grails CLI (https://grails.org/blog/2023-03-29-grails-6-m2.html). If you're able to use SDKMan this is pretty trivial. If for whatever reason you're not able to, this is actually pretty annoying as it's a more manual process and I haven't seen any guidance on how to automatically switch CLI versions per project. If you're in this situation it seems like it's up to you to decide on a way to change your GRAILS_HOME environment variable to the correct path.

The disruptive part for you will be initially installing the new CLI and getting accustomed to running the commands from somewhere else. Using "Run Grails Command" or for example right clicking on the services folder to generate a new Grails service from the context menu was pretty convenient, but I'd say running commands from the terminal is as fast or faster.

@ghostfox911
Copy link
Author

Some of what we're talking about here probably belongs in the discussions section rather than issues section, or even the JetBrains YouTrack issue tracker.

With Grails 6.2.0, the current IntelliJ Grails plugin (version 241.14494.158) stopped working. This is why the Run Grails Command dialog doesn't appear when you press CTRL + ALT + G. A workaround for this is to add implementation org.grails:grails-shell:6.1.2 to the dependencies in the build.gradle file. This will get the Grails plugin mostly working again. It will recognize all the artefacts and give you all those nice features such as syntax highlighting, code completion, navigation, etc.

However, the Run Grails Command still won't work. It hasn't worked since 6.0.0. The dialog will appear when you press CTRL + ALT + G, but the commands won't run successfully. If you run "--version" from Run Grails Command, it will report "Grails Version: 6.1.2", but you'll see it's running the commands like this \AppData\Local\Temp\1\idea_arg_file1093355971 org.grails.cli.GrailsCli --version. This makes me think it's trying to use some old CLI code still left in grails-core or something as opposed to the newer CLI in grails-forge. If you try to run a command like "create-controller foo" you'll get an error like "Could not resolve all dependencies for configuration ':profile'.", but I think profiles don't exist anymore from Grails 6 onward.

There's a workaround for running Grails commands as well. The Run/Debug workaround is pretty transparent, however this workaround will be a bit disruptive to your workflow. This will involve running the commands manually from the terminal. Since there's no longer Grails wrapper, you'll have to install the new Grails CLI (https://grails.org/blog/2023-03-29-grails-6-m2.html). If you're able to use SDKMan this is pretty trivial. If for whatever reason you're not able to, this is actually pretty annoying as it's a more manual process and I haven't seen any guidance on how to automatically switch CLI versions per project. If you're in this situation it seems like it's up to you to decide on a way to change your GRAILS_HOME environment variable to the correct path.

The disruptive part for you will be initially installing the new CLI and getting accustomed to running the commands from somewhere else. Using "Run Grails Command" or for example right clicking on the services folder to generate a new Grails service from the context menu was pretty convenient, but I'd say running commands from the terminal is as fast or faster.

Thanks so much again for such detailed explanations.

@rlconst
Copy link

rlconst commented Oct 4, 2024

Related issues #13512 IDEA-353327

@jamesfredley
Copy link
Contributor

Give it a try on the Grails 6.2.1 release: https://grails.org/blog/2024-10-03-introducing-grails-6-2-1.html

@ghostfox911
Copy link
Author

ghostfox911 commented Oct 9, 2024 via email

@vsachinv
Copy link

@ghostfox911 Doesn't your app restart automatically after auto-recompile code with Spring-dev-tool? We are facing alot issue due to this even minor change in controller or service restarting whole app in the background automatically.

@jamesfredley
Copy link
Contributor

spring-boot-devtools is the route for Grails 4, 5 and 6. Grails 7 SNAPSHOTS are currently working with https://github.com/HotswapProjects/HotswapAgent

You also need groovy hotswap:

https://andrewclement.blogspot.com/2010/03/groovy-eclipse-groovy-hotswap-support.html

https://github.com/groovy/groovy-eclipse

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants