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.
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 recently switched back from using a Spring MVC/Gradle/Groovy project back to a traditional Grails project. I have been noticing the file location conventions seem, intuitively, a little less organized. For example, having Groovy src files outside of src/main/groovy (exp. Controller filter), or having the src files themselves in src/java instead of src/main/java.
Now I know all of these things can be configured, but why don't they conform closer to the Maven3 structure?
Considering Maven 3 wasn't released until 2010 and Grails was around prior to that I don't see how they could have. The only "reason" Grails follows a different convention is because that's what the developers decided was the most logical structure for Grails. In a lot of cases it was to eliminate cruft (e.g. the /main/ in your example) or to place things more logically based on what they are.
I have few own APIs with around 2000 classes overall. Some of them use the new Path API from JDK7. Most other classes, however, do not rely on any new JDK APIs or new language features. So most classes could be used in a JDK6 environment (which I plan to do). Let's assume, I've annotated all JDK7-only classes with #Java7Only.
What I need now, is a way to create a JDK6-only subset of all my projects more-or-less automatically, without introducing new version branching or product lines (would be too complicated to maintain).
All projects are created using Netbeans, thus using Ant. Many projects depend on others.
Please help me evaluate, which ideas according to my problem is most appropriate. Which problems could occur with each idea?
Common first step for all ideas
Let an annotation processor search for #Java7Only-annotated classes and store the list to a properties file.
Idea 1 (specific)
Write a tool which would use the properties file to recursively copy the whole project, except JDK7-only files.
Build the copied project using JDK6 by invoking ant, thus getting a JDK6-compliant jar.
Idea 2 (specific)
Write a second annotation processor which would use the properties file to pass everything except JDK7-only files to a JavaCompiler instance.
Either build a jar using Java APIs or use Ant API for that.
(This would be a Java-only idea, but probably too complicated)
Idea X (abstract)
Somehow influence the Ant build process (by overwriting some targets?) and for each JDK6-compliant class: let Ant compile two versions of it (one time with JDK6 compiler, another time with JDK7 compiler).
(JDK7-only classes would be compiled only once, using the JDK7 compiler, of course)
Package each bunch to a separate jar.
Possible common problems to the ideas
Some projects dependent on others, so some actions (such as packaging) should consider this.
Remember: the JDK7 compiler generates downward incompatible class files, that's why every possible idea has to happen on sources-level (before or during the build process, not afterwards).
My thoughts on Idea 2:
Essentially this is invoking a compiler within a compiler. Annotation processors are run as part of compilation. Can this be done safely? Is there any static state in Sun's javac that would cause problems. (I don't know the answer but from memory there might be some static state that could cause problems in this scenario).
Idea 1 seems simpler and better to me.
But taking a step back, is it possible to separate out all the JDK 7 specific stuff into a separate module and compile it separately, into a different JAR?
Have the 'main' project, compiled using JDK 6 (which JDK 7 would have no problems reading because it is backwards compatible)
The JDK 7 specific module(s), with source in a different directory, which includes the 'main' JAR on the compilation classpath, could be built separately, with a different build.xml if necessary.
This only partially applies but I'd thought I'd mention it anyway.
The problem with just using -source 1.6 -target 1.6 options for validation is that you can still use Java 7 API when compiled using JDK 7.
I've used the Animal Sniffer Maven Plugin for a few projects now and it has proved quite useful. This plugin scans byte-code of your classes for JDK API usage. That is, you can tell it to fail the build if you attempt to use JDK 7 API when you are targeting JDK 6. This wont help much for separating out classes as you need but it could be useful as a final validation step combined with -source 1.6 -target 1.6 compiler options.
There is also an animal sniffer Ant plugin, as mentioned from the Animal Sniffer main page.
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