Hey all,
I'm just starting with Grails in Netbeans (6.9.1). I got a demo working, but each time i change a groovy file i need to build the project, and then select run (ie the equivalent of "grails build" and "grails run-app"). If there is already an instance running, I need to first shut that instance down.
This seems wrong. It seems like i should be able to just change the groovy file, and it would get automagically reloaded. Isn't that the point of groovy?
Is this actually how it's supposed to work in Netbeans? Without getting into an IDE war, do other IDEs do it better? everyone seems to rave about the Grails support in IntelliJ. Is it worth it?
One last point... I noticed that a regular war maven project no longer automatically reloads on an F11 build. Could this be related?
Thanks
--Matthias
Do not expect to have reloading for all your files even by running your grails app through command line.
Depending on which groovy file you have changed, grails run-time auto-reloading will work or not. Indeed:
Files and folders supporting reloading in development mode: gsp files (in view folder), grails services (in service folder), controllers, taglibs, css, i18 resources, javascript files, some config files (like Config.groovy), url mappings. Note that there are some Grails bug when for instance, using spring transactional annotation in Services makes the reloading crashed
Files and folders NOT supporting reloading (and requiring a restart of the application): any code under src/groovy, src/java, Domain classes (under domain directory), some configuration files, changes in plugins, any code under utils folder (if you have any Codec for instance)
So in your case, if you change a controller groovy file AND NetBeans restarts the application, I recommend you to use a separate command line for running grails application and using the IDE for code changes. The only bad side is that you will not use the NetBeans debugger.
Actually this is the way I work with Grails and IntelliJ
Related
In grails 2 and earlier, plugins installed their source to .grails/<version>/projects/<projectName>/plugins/etc, this made it easy to debug plugins that were installed without having to check out and load the full source... find where problems were that could be hot-deployed. No need to install run the plugin locally.
In grails 3, this seems to be missing... or maybe I'm just missing something? Is there somewhere in my project I can directly modify the plugin source without checking out the plugin, compiling it and then installing it locally?
Yes, you're missing something rather important :)
Grails 2 plugins are distributed as ZIP files including source code, but Grails 3+ plugins are distributed as JAR files with the code compiled into classes. This has multiple benefits over the earlier approach, the biggest one being that you can no longer edit the source directly (which is the worst way to make changes to how a plugin works).
What you should do instead (in all versions of Grails) is to take advantage of the compilation/load/resolution order between the app and the installed plugins - plugins load first, then the app. This allows you to override nearly anything in a plugin just by creating a file (Groovy/Java/GSP/etc.) with the same name and same relative location in your app code, and it will automagically override the plugin's file or class. E.g. to override a plugin's com.foo.BarController controller, create grails-app/controllers/com/foo/BarController.groovy in your app (manually or by copying the original source and modifying it).
I have a collection of applications written in Grails v1.0.5. The application does work flawlessly. But, I'm looking into the possibility of upgrading to the latest version(2.4.4). I know it is quite a huge leap starting from 1.0.5 but any pointers on where to start?
Official site holds documentation only from 1.2.0(makes me feel like I'm in old age).
Any help would be much appreciated.
The safest way to upgrade an application from 1.x to 2.x would be to create an empty 2.x project, then slowly, by hand, move the following:
Contents of application.properties into BuildConfig.groovy (e.g. install plugins).
Contents of Config.groovy and Resources.groovy (do this by hand not by copying the file)
Tests (copy files)
Domain classes (copy files)
Controllers (copy files)
Services (copy files)
Filters (copy files)
URLMappings.groovy (by hand not by copying the file)
Depending on the size of the applications and complexity this could be very quick, or very painful. One thing to stress. Test, Test, Test.
Is there a way to check which Grails plugins are active and used durring application runtime?
I want to remove a plugin but I want to be absolutely sure that it is not used anymore...
Well, a brute force way would be to copy your Grails project (preferably using a source control tool like git's branching feature), remove the plugin, and make sure that:
No exceptions on a grails clean, grails compile, and grails refresh-dependencies.
All unit and integration tests pass (your team is writing those, right? ;) )
You can run the application and use it fairly normally; warning, this is the worst test, and by itself isn't sufficient, as you could end up with a BOMM.
If you're familiar with the classes in the plugin, but there are way too many Grails files to look through manually, you could use code search tools like those found in GGTS whatever IDE/text editor you're using. Even grep could be handy for finding references to those classes or some distinctly named methods.
Conversely, if the plugin is basically a black box, and your Grails app is small enough to get around, check the import statements at the top of your Controllers, Domains, and Services. If the plugin provides more client-side technology (like the jQuery plugin) check your GSPs and various items in the web-app directory (like Javascript files) for references to it.
I am working on grails 2.0.4 project and at some point I've found that recompilation process does not work. Further tries showed that first run-app after removing ~/.grails/2.0.4 has recompiling process working well, but running run-app next time ignores changes in files during run (no changes on pages and no Compiling… message in log after appears). So my question is how to debug recompilation process?
There's some JIRA issues related to the recompilation:
http://jira.grails.org/browse/GRAILS-8951
http://jira.grails.org/browse/GRAILS-8573
http://jira.grails.org/browse/GRAILS-8914
Only the third one is fixed. Looking in the first, some folks said that this not work:
grails run-app
But entering in the interactive mode works:
grails
run-app
Looking a bit in the code, I can see that GrailsProjectWatcher.java is responsible for file changes. Try to add debug to the related package and see if you get messages.
If it's one particular class that's not reloading, one thing you can check is that the package definition is correct. Grails will happily compile a class that is in the wrong package, but this breaks the reloading mechanism.
Running into a problem with an existing application. I'd like to get hundson running to do some CI but I cannot modify the Websphere settings (making changes appears to break the application that I want hudson to test against!)
So this is my current error message:
We detected that your servlet
container is loading an older version
of Ant by itself, thereby preventing
Hudson from loading its own newer
copy. (Ant classes are loaded from
bundleresource://22/org/apache/tools/ant/types/FileSet.class)
Perhaps can you override Ant in your
container by copying one from Hudson's
WEB-INF/lib, or can you set up the
classloader delegation to child-first
so that Hudson sees its own copy
first?
Without changing the classloarder delegation (which breaks the existing app) is there a way to update Websphere's ant library? I don't even know where it is, I tried searching for ant-lr but came up with many results.
Any help would be appreciated.
Why dont you run Hudson on a separate app server? You can even run it from the embedded servlet container directly from the war.
If you really need to run it on websphere look at the wiki.
http://wiki.hudson-ci.org/display/HUDSON/IBM+WebSphere#IBMWebSphere-KnownIssues
Read http://wiki.hudson-ci.org/display/HUDSON/IBM+WebSphere. It states specifically that you must set child-first class loading on WebSphere 6.1.