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).
Related
I have a grails application with multiple internally developed plugins. Since upgrading from 4.x to 5.2.3, codecs are not found in one plugin, but are found in others. Specifically, I can place the same file (UsernameListCodec.groovy, package name changed from one plugin to the next but otherwise no changes) in grails-app/utils in one plugin and it works; when placed in grails-app/utils in another plugin it fails with MissingMethodException.
What could cause this? The plugins are fairly different in terms of what they provide, but very similar in terms of how they're built, published, etc. Clearly this is something I'm doing wrong (since the codec works in another plugin) but I don't even know where to begin looking. Does a plugin need to do something in particular to be able to provide custom codecs as of grails 5?
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've just inherited an application written in Grails (version 1.0.3) and would like to upgrade it to the newest release (version 1.3.5).
I can't seem to find a reference that enumerates the differences between the two versions. I know there is the "grails upgrade" command - but is this the best option given the large differences in versions.
I have a similar question that I asked today as well for upgrading the version of Groovy, and the sntactical differences to be aware of (between version 1.3.5 and 1.7.5) - but I thought it may be best to separate the two questions to focus on each.
Many thanks,
~Aki
Things have changed quite a bit since 1.0.3, and unfortunately grails upgrade isn't going to do much for you.
Two significant changes that come to mind are that there was a bug in 1.0.3 and previous where 1-many and many-to-many collections (hasMany/belongsTo) were supposed to be lazy-loaded but weren't. This was fixed in 1.0.4 and several users found that they were relying on the behavior and saw issues. Most people didn't, and just saw a significant performance boost. So watch out for lazy loading exceptions.
Another thing that changed is that plugins are no longer in the root of the project in the 'plugins' folder but are now stored under your $HOME/.grails folder. If you've checked the plugins into source control (and especially if you've made any changes) then you can revert to 1.0.x behavior by adding a property to BuildConfig.groovy (a new file that was introduced in 1.1):
grails.project.plugins.dir = 'plugins'
I described my process for upgrading plugins and apps here: How to install Grails plugin from source code? - it's about a plugin project but the same goes for app upgrades.
The log4j configuration changed from one that's properties-based to a DSL. This means that if you leep your config settings from Config.groovy the log4j behavior will be the default, so you'll need to convert that.
Another change that isn't required but should be considered is that Ivy jar file resolution from Maven repos is now preferred over putting jar files in the lib directory. You can still put them in the lib dir, but it's more DRY to have Ivy download them once.
You'll probably also find that some of the plugins you have don't work in 1.3, so there might be some migration work there.
There are two recent books that cover Grails 1.2/1.3, "Grails: A Quick-Start Guide": http://www.amazon.com/dp/1934356468/ and "Getting Started with Grails, 2nd ed": http://www.infoq.com/minibooks/grails-getting-started - you should probably check those out since they're the most current Grails books.
Overall it shouldn't be that bad, as long as you don't try to upgrade in-place. Use the approach I described in the other post I referenced, i.e. create empty apps and diff files to see what changed (basically a 3-way diff).
The newest release is 1.3.6 (as of Dec 15). You can get a list of changes from the Release Notes of each release. Also, the upgrading from previous versions link the documentation is a good source of changes.
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