It looks like IntelliJ's (Ultimate EAP 15) support for Grails 3 is in the early stages yet. If I do Run -> Debug 'Grails:My App', I'm able to launch an app from inside IntelliJ, I can set breakpoints and it works as expected.
If I make changes however, I see in the console that the file is recompiled, but when I hit reload in the browser, I don't see the changes reflected there. I have to stop and restart the app in IntelliJ before I see them. Anyone know how I can get the auto-reloading working?
After chasing this for a week, this post finally provided an explanation.
It's actually a Grails issue, not a problem with IntelliJ's Grails integration: spaces in a file's path will break automatic reloading. Renaming my project from Grails Demo to GrailsDemo got everything straighted out. (Storing a project in a folder like My Documents will also cause trouble.) The post's author indicates that this started with version 2.4.4 and it's still happening for me in 3.0.4.
Related
any number of problems tonight.
I have a grails 3.3.8 app in intellij. I have built some domain classes, and in the ide I selected the domain classes and told it to generate the controllers, which it does.
if i right click the Application project in project browser (either to run debug) the app comes up but no controllers are loaded. so i have to cease the session.
if i open gradle view and issue the bootRun command the app starts and the controllers get loaded!
however if i right click on the boot run action and select debug, if disappears off into the ether on a background thread and the IDE never fires and i dont get control of the debug session in the IDE.
This has got terribly frustrating and i've burn't alot of time tonight going round in circles
does anyone know why the right click on Application, in project explorer, fails to load the controllers, whilst bootRun does load them .
If i can fix that - then the debug from the project explorer should work. Its very odd.
i had to try and recreate the project as this evening it got lost telling me my domain classes were no domain classes and when i tried to delete and controllers/services and rebuild them it kept telling me cmdb.$xxxServices gorm data services couldn't be found and refused to build hibernate datastore
you can find the project to look at enter link description here but it needs another project (ticketAdapter to run, and a library project softwoodUtils) i've used the json end points directly on my browser for the ticketAdapter (server) project and i know thats working - its not a grails app itself)
Looks like you are trying to launch a Run/Debug Configuration of a standard Java Application with the public static void main method. For Grails 3 rather use Grails Run/Debug Configuration where specify the Grails module to load and grails command to run the app with:
You can also use gradle actions like bootRun to run your app.id youdouble click a gradle actions from the gradle panel it will automatically create and run a gradle run configuration. Then you can run or debug that configuration.
I have ggts-bundle bundle 3.6.1 64 bit with JDK 7 (jdk1.7.0_67) on Win7 64bit.
I have grails home setup as GRAILS_HOME and grails version grails-2.4.3.
When i create a new action/method in the controller class in the tool suite and hit save and refresh the browser, it doesn't reload the changes in the application.
I even modified BuildConfig.groovy and added the following
grails.reload.enabled = true
I also tried with grails -reloading run-app
Nothing seem to reload the changes, I have to stop the server and restart it and then
it reflects the changes.
I am sure there's something i can do to have it reload the app.
I read online and tried other suggestion in questions on stackoverflow before i posted this.
Any suggestions.
Did you end up getting a solution to this?
I've just tried this out in GGTS and it looks like there is no problem.
Version: 3.6.3.RELEASE
Build Id: 201411281415
Platform: Eclipse Luna SR1 (4.4.1)
OS: Win7 64bit
I'm working on a plain vanilla (unmodified) install with default settings.
Using a simple Grails project, with a simple HelloController.groovy and a couple of GSPs... corresponding to two methods inside the controller. Launch the server...
Tried out two scenarios to see what happened, back in the IDE...
modify some simple output text in one of the GSPs, save, refresh the browser... yep, no problem, the change shows up
modify the HelloController.groovy to tell one of the methods to use a different GSP, save, refresh the browser... again, no problems, the change is reflected.
Note. I did have to wait a few seconds in scenario 2 for the IDE to notice the change and to recompile
Perhaps try updating your instance of GGTS to the latest release to see if that makes a difference?
Hope this helps.
When I invoke run-app in the Grails console, code changes are auto-detected, and a recompile is triggered.
But when I change conf/UrlMappings.groovy, even though I see "Compiling 1 source files" appear in the console, the live web server doesn't, in fact, update its behavior.
The problem appears specific to UrlMappings.groovy; for example, I can make changes to a controller class and they appear automatically when I hit "refresh" in the browser.
Any thoughts on what's causing this behavior and how I can fix it?
Thanks!
I have installed the grails web plugin. I can now browse to :
localhost:8080/myappname/console
And I can see the console displayed over there. I have bunch of test-cases written for application. I wish I can test my app from this web console.
Is it possible to do so? I'm very new to grails.
Thanks in advance.
Short answer no. The grails console is meant to write groovy code that interacts with your running application. Your running application does not include your test cases or the grails command line by default.
Long answer sort of. Provided you have all of your projects source code available somewhere in the file system where your application is running, you could call an external process to run test-app and return the result to the user. Here are some docs on running external processes in groovy: http://groovy.codehaus.org/Executing+External+Processes+From+Groovy. I suppose you could also package you application somehow to make this work, but I think doing that would be fairly complex.
I am not sure this is a good use case for the console plugin over all. Hope this helps
I am using STS and sometimes when I stop my app on a crash it opens up to a hundred different class files that seem to be deep deep inner working stuff. HTTPBuilder just stopped working, and I suspect its because I accidentally typed in one of these files and absent mindedly saved it. If I somehow destroyed a local file involved in HTTPBuilder, how would I refresh my dependencies? (have done install-plugin rest and also uncommented everything in BuildConfig.groovy repositories)
My specific problem and error is here:
Grails: HTTPBuilder stopped working suddenly
UPDATE: As much as I would love to blame STS, as you can see from my answer to my own other question, I was purely thwarted by my own carelessness.
We had an issue today that we suspect was due to the Artifactory Migration. Your problem may be similar. The first thing we did to diagnose the issue was to turn up the debug logging in BuildConfig.groovy (change log "warn" to log "debug"). Once we did that, it was evident that the Grails repos in Artifactory appear to be responding differently to queries made to calculate dependencies. To workaround these issues, we:
Removed grailsCentral, grailsHome, and grailsPlugins from BuildConfig
Added grailsRepo "http://grails.org/plugins" to BuildConfig
Changed one of our dependencies so that its transitive dependencies used specific versions instead of version ranges.
For 3, our specific example was to change:
runtime 'com.amazonaws:aws-java-sdk:1.3.4'
to
runtime 'com.amazonaws:aws-java-sdk:1.3.4', {
excludes "commons-logging",
"httpclient", "jackson-core-asl", "jackson-mapper-asl"
}
runtime 'org.codehaus.jackson:jackson-core-asl:1.7.9' {
configurationmapping "*->*,!sources,!javadoc"
}
runtime 'org.codehaus.jackson:jackson-mapper-asl:1.7.9' {
configurationmapping "*->*,!sources,!javadoc"
}
I'm not sure whether all of these steps were necessary, but they allowed us to move forward.