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.
Related
What is the simplest way to migrate a Grails app developed in 3.0.4 to 3.0.6?
The grails documentation recommends to create a new app and migrate every component one by one. But there should be a simple way if we are migrating within version 3?
Any help much appreciated
I run a grails create-app to create a fresh install of the new version. I then copy the files from the new version over top of my older v3 version. It's then pretty simple using version control tools to check for changes that need to be merged. The following files will have some changes that need to be merged into my existing project files:
build.gradle
gradle.properties
To be safe I usually also copy over the following, though they are less likely to have changes:
gradle/
gradlew
gradlew.bat
grails-app/conf/application.yml
grails-app/conf/logback.groovy
grails-app/i18n/messages.properties
grails-app/init//Application.groovy
With version control it usually takes less than a few minutes to review and merge back any changes that need to be retained. I find the process fairly simple.
I think you refer to this documentation https://grails.github.io/grails-doc/latest/guide/upgrading.html which is really about grails 2.x to 3.0.x migration.
In the case you're already on 3.0.4 you can just look at the release note of the version to see what is new and if there's any impact. As you will see its a lot of bug fixes and the introduction of the new web profile to create REST specific applications.
We are using this openAM 9.5 RC1 branch source in our project. https://github.com/svn2github/openam.git
In order to fix some bugs, we have to modify existing openAM's amserver library. For this, we have downloaded the source code from above location and tried to compile it offline using ant (as stated in README). But we are not able to compile it anyhow (even after making necessary changes, adding dependencies etc.)
Is there any way to construct required library (amserver.jar) from this source code ?
The OpenAM 9.5.x and 10.0.x versions are rather difficult to build, but from 11.0.0 the build process should be much more simpler since the project has been migrated over to Maven build system.
In any case, the version you are using (Snapshot 9.5.1 RC1) is very much outdated and most likely has several critical issues (not to mention the security issues).
I would strongly advise against putting effort into backporting fixes to that ancient version. Instead you should realize that you are running a more than 4 years old version of a security component, and upgrade your system to a more recent version as soon as possible.
I recently get to know grails and start to using it, I know that grails is a great language and it is very helpful for rapid development, but I cant understand why grails dont have a good backward compatibility, I use grails 2.3.8 and grails 2.4 for my projects but many of sample codes in the internet are 2.2 or less, and it isn't time efficient to convert them to 2.3.8 or 2.4 because there are many changes from one version to another. And some times although I do any things right and every thing must work like it works with grails 2.1 or 2.2 but some things still remains.
Am I wrong? I skipped some things that make converting version so hard?
And above all this, what are the guaranties that projects I'm developing right now will be compatible with higher versions of grails that comes in the future?
Joshua Moore is right with his answer, but I do not see it as passimistic as he does.
The grails development team is brave enough to make changes which break with the past. I consider this as a great feature - Grails does not ride dead horses.
For me, most of the changes don't seem to bee too radical. Most of the time, I skip 2-3 version and then upgrade my apps to the current stable version in less than a day. This also helps me to get to know the new features.
If you don't know how to upgrade, the safest way is to use the grails upgrade command. Just increase you version number step by step and do an upgrade and re-run your test (yes, tests help you in your upgrade process :-). If tests fail, take a look at the great changelogs and the "What new in Grails x.y?" sections of the documentation.
Often it is also helpful to compare your old grails version app with a new and empty target version project with a good comparison tool like BeyondCompare. This way you easily spot changed configurations.
Hope that helps
Update: When you are new to "all those webconcepts" you should first decide on the platform you want to work on. If it is the java ecosystem, Grails is the best webframework on the market :-) Otherwise PHP, Rails, DJango etc. could also be a match.
So if you want to learn Grails (and with Grails all those webconcepts), I would suggest to start reading the Guide which will tell you how Grails works. If you need more examples, I can suggest the "The Definitive Guide to Grails 2" published by Apress. It covers basically the same content as the guide, but it does so by walking you through a process of building a sample application.
When it comes to the samples you find on the net... as soon as you get to know the framework better, you will probaply know ho to handle the examples - but there is no silver bullet...
Nothing guaranties that your projects will be compatible with future versions of Grails. In fact, from my own experience, they won't. Often things change, and sometimes radically too, as Grails matures into higher versions.
The same holds true of backwards compatibility as well.
All you need do is take a look at the introduction section of the Grails documentation to see how often things change significantly between versions. A lot of times these changes require significant refactoring of older projects to upgrade them. I still have several large projects running on the 1.3.x branch of Grails because we don't have the resources (time) to go through and upgrade them.
Often this upgrade process involves creating a new empty project then slowly moving the code from the old project into the new project, updating code to reflect newer means of doing the same thing and testing. It's not easy for projects where you have 100+ Domain classes, 1000+ GSPs, 50+ Services and several hundred thousand lines of tests.
Grails 2.0 projects currently come with resources plugin 1.1.5, which appears to have several dependency problems (e.g. see answer for this post). I'm using IntelliJ, and while I updated BuildConfig.groovy to
runtime ":resources 1.1.6"
which appears to cause IntelliJ to bring in new files, it doesn't update the plugins section (it still shows the old 1.1.5).
So then I did an uninstall-plugin-in resources, which got rid of the plugin in the Grails view. I then did install-plugin resources, and even though the resources plugin website shows it is at 1.1.6, I got a resources-1.1.3 plugin.
How is this possible? That's several versions back now. Additionally the website says it was updated 3 weeks ago to version 1.1.6.
Should one ever even use install-plugin? Can someone please tell me the preferred way to bring plugins into projects?
Thanks.
P.S. Not clear how to download this plugin.
The format for the dependency resolution DSL is group:name:version.
For the resources plugin it should be runtime ":resources:1.1.6"
The install-plugin command has been unofficially deprecated in favor of the dependency resolution DSL.
BUT, here's the first reference to install-plugin in the latest Grails 2.0 documentation:
"Grails supports Rails-style migrations via the Database Migration plugin which can be installed by running
grails install-plugin database-migration
IT WOULD APPEAR GRAILS 2.0 NEEDS TO HAVE AN OVERVIEW SECTION IN CHAPTER 3 -- JUST A FEW WORDS --, EXPLAINING THE DEPARTURE FROM USING INSTALL-PLUGIN, vs CREATING CONFUSION, AND NOT EVEN DOCUMENTING refresh-dependences anywhere in the main Grails 2.0 document if one searches for the term.
Otherwise I think developers like myself spend lots of time doing just the opposite of the main goal of what Grails is, wasting hours configuring things and getting them to run together, realizing the exact opposite of the Grail's goal: "the search is over", easy/fast application development.
Have been developing with Grails for couple of weeks now,
Though I've loved the experience and the possibilities, I've seen following problems starting up.
Please share if you've had similar issues.. and remedies would help too.
Transaction management (in-built) doesn't seem to work in some circumstances.
AOP with domain objects doesn't work
Grails IDE-plugins are pretty primitive
GWT-Integration (with the plugin)
Plugin installation (fails unusually) probably cause plugins are not matured enough.
Lack of extensive documentation (though what is available is pretty good)
Debugging support
If you actually want solutions for these problems you should post a separate question for each with a lot more information than you've provided here. For example, I can't possibly diagnose the cause of the problem when all I know is
Transaction management (in-built)
doesn't seem to work in some
circumstances.
Here is my opinion on these issues:
Transaction management (in-built) doesn't seem to work in some circumstances.
I haven't noticed any such problem
AOP with domain objects doesn't work
I guess what you mean here is that meta-programming domain objects doesn't work. I have encountered this and haven't found any solution. If you really meant AOP then I can't help you as I've never used it with Groovy.
Grails IDE-plugins are pretty primitive
The IntelliJ plugin is very, very good. The Netbeans plugin is OK. Last time I tried the Eclipse Groovy plugin it was awful. However, I believe that a new Eclipse Groovy plugin has recently been released as part of the Spring Tool Suite (STS). It's supposed to be big improvement on the previous Eclipse Groovy plugin, but I don't think it has much Grails support yet
GWT-Integration (with the plugin)
I don't use GWT, so have no comment
Plugin installation (fails unusually) probably cause plugins are not matured enough.
I've never had problems installing plugins, though if I update a plugin, I sometimes need to manually remove the old version from the .grails directory.
Lack of extensive documentation (though what is available is pretty good)
I think the level of documentation for Grails is way ahead of most OS projects. There is a wide range of Grails books available, there's an active mailing list, and the official document is 176 page long.
Debugging support
Again, it depends on the tools you're using. With IntelliJ, debugging a Grails app is as easy as debugging a Java app with Eclipse.
My own pet peeves about Grails development are:
Upgrading from one version to another is often a very painful process due to lack of backward compatibility. When I upgraded from 1.0.4 to 1.1.1 about 20% of my tests started failing
Application reloading is very hit and miss.
My feedback after few months with Grails:
Didn't happen to me.
I don't use AOP
Wrong. IntelliJ is very good and especially the last beta version. You can download it for a free trial. I know that Eclipse support is very limited and NetBeans becomes better but still behind IntelliJ
I can't say. I don't use it
Agree. My piece of advice here is to follow these following principles: 1.Use plugins as few as you can. Your application will be lighter and more maintainable. Also, you will upgrade Grails version more easily. 2.if you want to use a plugin, test it before with a dummy project. It takes few minutes for creating a grails application and you could test your next plugin rapidly. Be aware that sometimes plugins have compatibility issues between theselves so, do not hesitate to install all of the plugins you need into your dummy project
Agree. Grails is a very complex framework and documentation does not cover every aspect of Grails. But what is available is well explained. Also, grails community is very responsive, so if you don't find something you will easily have an answer in Grails forum or even on StackOverflow
Definitely Agree. Again, with IntelliJ you can debug easily but it is resource-consuming and takes time when reloading your app. So usually, I end up with logging traces and I debugg my full stack of exceptions like that! IMHO, this is one of the major shortcomings of Grails.