Related
I started digging into the liferay 6.x ServiceBuilder framework and really liked its code generation approach. A simple service.xml file can generate ready to use powerful services without even writing a single line of code.
I also tried looking into AndroMDA which can generate similar services from the UML model, which sounds even more interesting since it will link my business model directly without me needing to learn a new xml config for service.xml (in case of liferay ServiceBuilder)
now I am in the process of deciding which tool should I use. Based on your experience with any of these tools Please let me know what are Pros/Cons of using any of this library,
I am interested to know these aspects, along with your own thoughts
Which is better to keep my development more productive in long term.
If I use ServiceBuilder will I be able to use the services outside portal env (lets say running same service from a non-portal app server.
Is UML driven approach always good or there are some practical cons/challenges of it.
Do you know of any other code generation library which is better than these two for liferay 6.x development? I also checked these SO Threads
Do You Use Code Generators
Java Code Generation
Following few problems I have experienced with Servicebuilder (I am using liferay 5.2.3) :
Not able to make use ORM framework. There is no way to generate
relations among objects. Because of this I am effectively working
just object mapper. It is not generating onetomany kind of relations
Can not use basic object oriented things like inheritance with domain or services
It is quite hard to write unit test cases
I still didn't understand what is the need of complex domain structure
I feel the code it is generating can be quickly written using an IDE
But definitely it has its own benefits like Egar said, it is specifically made for Liferay. So it can quickly generate everything that is needed for liferay. I heard in latest versions of liferay few of above problems are fixed.
Overall it depends on your requirement. If you need more control over your ORM layer and you have complex business logic which needs quite a lot of unit testing, go for normal spring services which can be exposed as webservices or REST services to your portlets.
Otherwise service builder is also good for simple portlets. Other approach could be using both. All complex services as a separate project and simple ones with service builder.
There is an important fact that you should be aware of. ServiceBuilder has been used to help building the portal itself and it is tightly integrated into it. You cannot use it outside of Liferay...I mean it probably could be taken and modified for general usage, but I doubt it would make sense.
Most importantly because Portal and each plugin that you are developing have their own web application context in a servlet container - each has its own classloader. Plugins are using Portal classloader and portal services, etc. etc.
Simply put, ServiceBuilder generated code and spring context can exist only if there is a webapp/ROOT/ which is Liferay Portal with portal classloader etc.
AndroMDA is a MDA framework for general usage. I don't know it much, so that I'm rather not going to make comparisons. The power of ServiceBuilder is that it is not a framework for general usage - the more powerful it is for liferay plugin development.
SpringSource (now VMWare) has two very similar technologies: Grails and Spring Roo. I have been using Grails, but I see that SpringSource is actively working on something that is a competitor for that technology and that makes me worried about the future of Grails.
Does anyone know how these technologies relate, are they going to be merged, or one of them will be abandoned?
Besides, are there any important technical differences betweent Grails and Roo?
SpringSource's goal is to make it as fast and easy as possible for people to build, run and manage Spring-based solutions. We have both Grails and Spring Roo because we deeply care about developer productivity and unquestionably both of these tools deliver a serious boost to what teams can achieve on top of Spring.
We have both technologies because Roo and Grails are very different at philosophical and implementation levels (as already noted in the other replies). Each technology approaches its primary language (Java or Groovy) and operating model (dev-time or runtime) with the philosophy of "how do we make the value proposition unbelievably good using this language and operating model combination?". As such you'll see each technology adopting a different style that maximises that combination (Roo's Java+Dev-time or Grail's Groovy+Runtime) and the commensurate benefits.
These differences are actually very positive, because they mean the Spring community can chose which "flavour" of productivity solution they prefer. While these initial differences around language choice and runtime/dev-time operation are immediately apparent, the choice of Grails or Roo also extends to more subtle considerations such as the default technologies used, user interaction model, IDE support, dependencies, standards, roadmap, extensions etc. Nearly all of these differences are a natural consequence of pursuing a best-of-breed solution for a particular language style.
Our best advice is to consider both solutions. Each have their sweet spots, but there are differences between the two which will make your overall experience better with one technology or the other in a given context. Both reference guides detail the respective benefits of each solution. Of course, remember the time investment is minimal in trying both out. In 10 minutes you can build a project in Roo or Grails, so give them a try and see what feels more natural for you given your specific background and project needs.
The main difference is that Roo is a pure Java framework whereas Grails leverages Groovy as well as Java. Both are built on the core Spring libraries and make use of popular Java open source libraries.
This question was asked back when Roo was announced and Graeme Rocher (Grails lead) says that both frameworks have a place within Spring and are supported equally.
If anything, I think Grails has a brighter future than Roo. I love developing with it and don't see any downsides to it not being pure Java.
Grails and Roo are very different. The first major difference is the language used. While you can write Groovy code like traditional Java code you still need the Groovy dependencies to run Grails applications. To be as productive as possible in Grails you also need to have a grasp of features in Groovy that are not currently part of Java such as Closures. Another difference is the philosophy the frameworks take to generating code. Grails generates a lot of methods at runtime while Roo generates them on request during the development process. Roo has no behind the scenes magic accept for the usage of aspect oriented programming, and you can view all the code that Roo generates. For example in Roo you must use a command to have it generate dynamic finder methods such as findByBook() and then view the generated code in the .aj files. In Grails the findByBook() method is created at runtime, and you can’t view the generated code. Roo also allows you to stop using the framework if you chose while continuing to have a running application by merging all the generated code into normal .java files. You then have no dependencies on any Roo libraries at either runtime or design time. If you decide you don’t like Grails there’s no way to stop using the framework while continuing to have a functioning application.
IMO the two are not very similar. Even though there are similarities the following are significant differences:
Roo uses "Stock-Standard Java",
Grails is based on Groovy
Grails is a Web framework, Roo is not
Roo is very similar to Grails' command line system (e.g. the create-app, create-domain-class, test-app type commands found in Grails). I would not be surprised to see some "cross-pollination" between this part of the Grails framework and Roo.
Ben Alex from SpringSource talks about Roo in this interview and he is asked about Grails vs Roo. The main difference besides using different languages (Groovy vs Java as others mentioned) is that Roo is mainly a development time tool and Grails is more involved in runtime.
They're actually not that similar. Roo does it's magic at compile time, where Grails is does it runtime. Because of that Roo projects does not take any performance hits at runtime.
I can't see how they could be merged as Grails is built upon Groovy and Roo on Java.
I saw some comments on the Grails mailing lists which indicated that the authors believed that Roo exists only as a stepping-stone to Grails! However I am personally considering a possible switch from Grails to Roo. I think the main difference is between dynamic and statically typed languages - to me this is huge. I love many features of Grails but I prefer the IDE support and compile-time checking of a statically typed language. Some others feel exactly the opposite, hence horses for courses. That said, static groovy is currently under heavy development so who knows what the future holds.
We had a requirement where we had an application in production and was developed in Spring MVC and the velocity of developing new features were slow. We had to explore alternate frameworks like Grails and Roo. I personally spent close to a month exploring which one was better.
If you want to see the details of the analysis visit # http://krishnasblog.com/2012/05/08/roo-vs-grails/
We explored following features in both these and below is our findings. The final verdict we are not sure we will use either one, we are still exploring
I'm a Java developer trying to learn Grails, and I'd like to get exposure to as many parts of the Grails framework as possible. Preferably doing so by solving small real-world problems using the "Grails way to do it" (DRY, convention-over-configuration, and so on).
Three example could be:
Learn about GORM by creating a few classes (say Movie, Actor, etc.) and relations/mappings between them (1:1, 1:N, N:N, etc.).
Learn about the layout support (sitemesh) by using it to generate headers and footers common to all GSP:s on the site.
Learn about the filter support by using it to make sure all accesses to a certain controller comes from authenticated users.
My question goes to all Grails developers out there - what would you include in a "Grails curriculum" and in what order?
All input appreciated!
Here's some examples, but be warned that they're fairly trivial and don't really show you how the system works together. One of the strengths of Grails is that the different parts all combine to reduce your code complexity and speed development. I recommend doing a single project of moderate size (like blogging software or a photo gallery) that forces you to touch virtually everything. I'm currently working on a ticket management application, and I've had to learn basically everything in the framework. It's really not that much material, actually.
That being said, here's my list of "must study", along with some examples:
Groovy, especially closures, maps, and properties. If you're coming from Java, closures might seem a little strange at first. However, once you wrap your head around them, it'll be hard to go back to a language that doesn't use them. Maps and properties use ideas that might be familiar, but the syntax and usage is different enough that it's worth studying them closely. Grails uses these three things ALL THE TIME, all throughout the framework. For a good example, examine the "BeanBuilder" that instantiates the Spring beans defined in resources.groovy. Also, run through the Groovy documentation at groovy.codehaus.org. A couple of hours there will save you DAYS down the road.
MVC programming. The "MVC" model in Grails pretty closely matches the one used in Rails, but it's significantly different than the "MVC" model used in Java desktop applications. Basically, all incoming URL requests are a message to a controller, which returns a view. Domain objects are the data that you want to store, view, and manipulate through views and controllers. Do an input form that validates the user's input using constraints, and then manipulates it somehow using a controller. Something like a page that takes in your birthday, and returns your Zodiac sign and Chinese Zodiac animal. See if you can get it to return errors to the user when bad input is given.
GORM. GORM is super-important, but you'll be forced to learn it with virtually any project you pick. Give the documentation a once-over, just so you know what its' capabilities are.
Filters and Services. These are "the grails way" to do a lot of DRY programming. Authentication is a canonical example, and it's perfect for learning filters. For services, write something that will send out email. There's a great example of a simple emailer service on the Grails website.
Groovy Server Pages. If you've worked with a templating engine before, then this should seem familiar. Get to know the GSP tag library, it's a huge help. Practical examples include: virtually anything. Every application needs a front-end. Try and make it pretty. NOTE: This spills into a lot of stuff that isn't Grails-specific, like JavaScript, CSS, etc. Unless you have that knowledge already, prepare for a bit of a learning curve.
Your "conf" directory. Get to know every file in there, especially UrlMappings.groovy. Play with UrlMappings so that you have an app that takes meaningful information from the URL. Something like /myapp/calculate/36/times/145, where the app returns an answer.
I'd say those are the basics, but there's a lot of other topics like webflows, i18n, testing, session handling, and so on. The best way to learn those is by building a decent sized project. While you're doing that, you'll probably find yourself thinking, "Gosh, I wish that Grails did ____". Read through the excellent documentation on Grails.org, and you'll probably find a built-in capability or plugin that does what you want. The reference PDF lives on my desktop, and I've found it invaluable during my learning experience.
Oh, and look at the scaffolding code that Grails generates. You'll probably end up pitching it all out, but it'll give you a good idea of how the system works.
Have fun, and happy hacking!
Step 1 - Learn Groovy
If you already know Java, I highly recommend Programming Groovy. It's a lot more concise and up-to-date than the otherwise excellent Groovy in Action. Neither of these books cover the significant language changes in Groovy 1.6, so you should also read this page.
Step 2 - Learn Grails
The Definitive Guide to Grails is probably the standard Grails reference - make sure you get the second edition. Grails in Action is slightly more recent, but I haven't read it so can't comment further on it. I found TDGTG a little lighton GORM, so you might also consider checking out Grails Persistence with GORM and GSQL. It's a very short book, but worth it's weight in gold.
Step 3 - Dive In
Try and modify the sample app in the Grails book, or build your own from scratch. The Groovy console is a great way to experiment with snippets of Groovy code.
If the audience is not familiar with programming in Groovy there should be an introduction to that. Java will work but it gets the juices going when you see how less verbose the code is in Groovy. When discussing GORM include constraints and how they influence validation. Scaffolding is a real time saver when starting a new project so be sure to include it. One of the features of Grails that really has helped me is Plug-ins. Pick a few and show how they provide solutions while saving development time. A security plug-in would fit right into the filter topic you mention. Testing, can there ever be enough testing?
I would really recommend reading the Definite Guide to Grails, Second Edition. It covers everything you need to know about writing applications in Grails. It probably lacks the "what happens under the hood" knowledge, but you should get the hang of it. You can buy it as a PDF and start reading it immediately.
You should also have a list of plug-ins to use - Grails has some really nice ones that come in handy. I can tell you some of the ones I use, but that may be a good question here, too. :-)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Grails vs Rails. Which has better support? And which one is a better choice to develop medium size apps with? Most importantly which one has more plug-ins?
One other thing worth mentioning: the design philosophy of both framework is somewhat different when it comes to the model. Grails is more "domain-oriented" while Rails is more "database-oriented".
In Rails, you essentially start by defining your tables (with field names and their specifics). Then ActiveRecord will map them to Ruby classes or models.
In Grails, it's the reverse: you start by defining your models (Groovy classes) and when you hit run, GORM (Grails ActiveRecord equivalent) will create the related database and tables (or update them). Which may also be why you don't have the concept of 'migrations' in Grails (although I think it will come in some future release).
I don't know if one is better than the other. I guess it depends on your context.
This being said, I'm still myself wondering which one to choose. As Tom was saying, if you're dependent on Java you can still go for JRuby - so Java reuse shouldn't be your sole criterion.
I guess if you are a Java developer and want to have access to all the existing enterprise Java libraries and functionality... go with Grails.
Rails is more mature, has more plugins, has a bigger userbase, has better documentation and support available. It can also run on JRuby giving access to Java libraries if you require.
Grails has some interesting qualities, but can't claim to be up there with rails just yet. However, if you're predominantly a Java or groovy developer you may prefer it. Otherwise though, I'd suggest using Rails for medium sized projects right now.
I say grails since there are so many java libraries out there. But I am a bit biased due to the fact that I come from a java background.
If the app isn't going to be big, either suffices - and the choice ought to depend on existing infrastructure. Say if you already have a java servlet container server running, you might as well stick with grails instead of provisioning another server for rails.
I used rails before and liked it quite a bit. However, my current company had a lot of legacy java code and therefore the natural choice was grails.
When I started with rails, very few sites were using it and documentation was atrocious. There was railscast that was great and railsforum.com, but anything out of the ordinary, you're on your own. Deploying it was a nightmare, and using mongrel-clusters was not really production ready. This is very different now as everybody can see, much more mature and deployed everywhere.
Over a year back, I had to learn grails due to reason I cited above. Transitioning to grails was very easy, since it is very similar to Rails. Again, it was very similar to the early stages of rails, with one huge difference. Because you can easily import java code, grails users can use almost all the production tested java libraries available out there. I've been able to successfully integrate our legacy java projects into grails projects and very little tweaking are needed. You will also notice that plugin development has been rapid, mainly because developers are just writing grails "hooks" but the underlying code are the old java libraries. Deploying grails is also just deploying a WAR file.
Another thing you have to look at is IDE. If you're comfortable with eclipse, then eclipse-STS for grails gives you all the bells and whistles. I still see a lot of rails developers use textmate, though rubymine has made great strides (the early version of rubymine used to grind my ubuntu to a halt).
The bottom line, both are great MVC frameworks. RoR is much more mature and has a lot more developers. Grails is where RoR was 3-4 years ago, but I see the progress a lot more faster. Hope this helps.
It depends on your skills with Ruby and/or Groovy, whether you have legacy Java systems to deal with, and where you want to deploy your applications.
I was initially thrilled with Rails. At the time, there wasn't an option of deploying on the application servers at work since work is all Java. This has changed. I couldn't abandon the Java infrastructure and applications already in place and switch to Ruby, even though I thought Rails was awesome. Grails works because we can mix and match Groovy with the existing Java solutions.
Outside of work, Ruby is easier to find hosting for at the low end of the price spectrum. Because Grails uses a lot of existing Java projects the .war files, even for a small app, tend to be large. If you have a dedicated server this isn't a problem but trying to run on shared hosting with 128 MB RAM doesn't work.
2008 is the year of Groovy and Grails books but there are still many more Rails resources available.
Based on your specific criteria, Rails may be a better framework to learn. If you have any Java knowledge, or baggage ;-), you should look at Grails.
Seeing as how the guys who make Grails just got bought out by Spring source yesterday, I would say Grails.
Also, since Groovy is a superset of Java, you can dive right in just using the Java you know without having to learn Ruby. Now, you'll learn a lot of dynamic stuff too and eventually write Groovy code instead of Java code, but it lowers the barrier to entry.
Grails all the way!
I would go with Grails since I like its approach (specify your domain classes and have Grails generate everything else) better than the Rails one (build database tables and have Rails generate everything else). If you're a Java developer, you'll also like that Java code is valid Groovy code, and a Groovy class is a Java class so the integration is seamless both ways.
As a Grails developer coming from Java, I loved it from the very first time.
Now, I'm starting to dig into Rails and having problems with gem. While MySQL connection setup with Grails was pretty straightforward, I'm still struggling to make it work with Rails.
The command gem install mysql is not working, apparently because I don't have XCode intalled.
If it weren't for its memory consumption issue, I'd say Grails is perfect.
May I suggest Merb? It is rack-based, modular, ORM-agnostic, built for speed from ground up by Ezra Zygmuntowicz. It is starting to gain some heat now...
Rails is more mainstream, but less flexible. Grails is still changing rapidly, doesn't have the same developer ecosystem, and the documentation isn't nearly as mature, but it will work in some situations Rails won't.
I have used turbogears and rails a little bit. Before using rails, I tried using grails because I was using groovy for my scripting. Grails was a difficult experience.
The groovy call stack is difficult to read for a small program, but when you add in several heavy weight frameworks a simple error can yield 100s of lines. Unlike rails the grails version that I was using didn't have tools to help me determine what was mine and what belonged to the framework.
I eventually switched to using the Google Web toolkit since I really didn't need the database.
I think Grails and Groovy hold promise, but the user experience of working with them is cumbersome at present (present being last spring).
I think it depends on the environment you're working in to some extent.
Grails seems to have more corporate level acceptance.
Rails has the Koolaid-vibe, and is very acceptable for start-ups with no legacy systems.
Personally I'm using both. Though only really just starting out in the Grails world - I like that authentication/authorisation is easier in Grails-one simple plugin; Shiro. I like that Rails isn't dependant on JVM, and doesn't take a minute or so to startup.
I find setting up BDD/Cucumber within Rails was far easier, but that could just be because that's what I'm comfortable with! There's definitely efforts in the Grails world (cuke4duke etc) to make this easier-and an active community developing Grails.
Just my 2p·
Try both :)
My company is in the process of starting down the Grails path. The reason for that is that the current developers are heavy on Java but felt the need for a MVC-style language for some future web development projects. Personally, I'm coming from the design/usability world, but as I take more "front-end" responsibilities I'm starting to feel the need for learning a language more intensively so I can code some logic but especially the front-end code for my UIs and stuff.
I've been trying to get into Python/Django personally, but just never invested too much time on it. Now that my company is "jumping" into Grails I bought the "Agile Web Development with Rails (3rd Ed - Beta)" and I'm starting to get into RoR. I'd still like to learn Python in the future or on the side, but my biggest question is:
Should I be learning RoR, and have a more versatile language in my "portfolio", knowing that my RoR knowledge will be useful for my Grails needs as well??
-OR-
Should I just skip RoR and focus on learning Grails that I'll be needing for work soon, and work on learning RoR/Django (Ruby/Python) later?
Basically the question revolves around the usefulness of Grails in a non-corporate setting and the similarities between Rails and Grails. (and this, while trying to avoid the centennial discussion of Python vs Ruby (on Rails) :))
Mmh, I don't know how to say this. Some people might bash me over this.
Language (Groovy and Ruby)
As a language I reckon Ruby is more funky compared to Groovy. Groovy only exists to ease Java programmer as you don't need to learn too much new syntax. But overall I reckon is not as funky as Ruby. Groovy wouldn't be the JVM language that is worth to learn based on attender's vote in this year's JavaOne but instead Scala is the one to go. Besides that, the original creator of Groovy himself does not have faith in the language he created himself in the first place.
Community and Job openings
As for the community, Grails community is not as big as Rails, though since the acquirement by Spring more and more people are using it in serious application. Rails has more job openings in the market compared to Grails (that is if you want to invest in looking a new job).
The framework (Grails and Rails)
But, as a framework, if you really care about maintainability and need access to Java framework and legacy Java system, Grails is the way to go as it provides cleaner access to Java. Grails itself is built upon several popular Java framework (Spring & Hibernate). Rails itself IMHO is funky like Ruby itself, but it's funkyness costs you maintainability. Matz himself prefers Merb over Rails 2 because Rails create a DSL on top of Ruby which is really against the Ruby philosophy. And I reckon because Rails itself is opiniated, which in turn if you don't have the same opinion as the creator, it might not fit your needs.
Conclusion
So in your case, learn Grails as that is the company's consensus (you need to respect the consensus) and if you still want to secure your job. But, invest some time learning Rails and Ruby too if you want to open a chance getting a new job in the future.
Just a bit of a question, is the reason they are choosing Grails because Groovy is closer in syntax to Java than Ruby, or because they want access to Java?
If it is the former, then I would say try to focus on Grails since that is what you will be using. If it is the latter, you might want to see if the development team is open to using JRuby.
I have never used Grails or Rails before, but I have used Groovy and Ruby before, and as a language I think Ruby is much cleaner and more consistent, and the team might enjoy production more. As a platform, Rails has been out longer and has a lot of attention, so I would imagine it is a more stable platform to use with more fleshed out features.
JRuby has full access to classes written in Java, so this is why I would say consider trying Rails. If it is too late in the decision time to consider it then I guess you can just ignore this post.
Basically, if you just want to hook in with Java, then JRuby is an option you should consider, but if the team is afraid of non-Java like syntax, maybe continue as is.
I would learn both. They are both up and coming technologies. Learning RESTful coding is a real benefit in any language.
I use GRAILS at work and RoR for side projects. I can say that the RoR community is much larger (I'm talking about RoR vs Grails not RoR vs Java) and very helpful.
Short Answer: They are similar.... what could it hurt?
Just skip RoR. There are really not a lot of similar things(besides the name)
I certainly believe that being enough familiar with Java, plus some experience programming with a dynamic language is more than enough if you plan to do serious development with Grails.
Comparing just only views(taglibs in Grails, RHTML in RoR) and the persistence stuff(GORM vs ActiveRecord) is just too different in the core, to invest time learning the nitty gritty details of RoR. Just dive into Grails, you won't regret.
Edit: corrected typo.
I've been learning RoR and Grails and the latter is far easier to learn.
Both frameworks share the same principles (agile, kiss, dry, duck typing and so..) but Groovy syntax is...well is simply great, something you can learn and use in a blink of an eye.
I truly feel that Grails has brighter future than RoR.
PD: Just in case you find it useful, a college of mine it's working full time with Grails and has a blog with some tips:
http://dahernan.net/search/label/grails
You should just skip RoR and focus on learning Grails that you'll be needing for work.
#Levi Figueira
For one thing, Grails is far more flexible than Rails. Rails is difficult to use with a legacy DB because ActiveRecord has too many design constraints that many legacy DBs didn't follow. Grails, oth, can use standard Hibernate mappings, which can accommodate a much broader range of DB designs.
The Rails community has been very vocal in evangelising RoR, with the result that high expectations have been set and not always met (programmer productivity is good, but ensuring good performance once deployed isn't so easy).
Grails has been designed as the scripted successor to Java, whereas the Ruby-Java integration used in JRuby on Rails, for example, has had to be retrofitted.
I would suggest that you stick with Grails; it may not have the same glitz as RoR, but it's a pragmatic choice; you get improved productivity and the re-use of existing Java libraries.
Jump straight into Grails. I'm sure Ruby/Rails is good but so in Groovy/Grails. I recommend this book.
http://beginninggroovyandgrails.com
Remember the errata is online. There are a couple of mistakes in the book.
http://beginninggroovyandgrails.com/site/content/errata
Also, check out the 3 minute and 30 second demo of creating your first Grails app.
http://grails.org/Grails+Screencasts
This tutorial will show you the basics.
http://grails.org/Quick+Start
Yes Grails is the way to go. RoR is good but it ties you in to the Ruby ecosystem. Part of the effort of learning a new framework or language is learning the class libraries as well as the language syntax. If your co-workers are all Java types you will be much better placed to receive help and support as they will all be speaking the same language as you.
The other advantage to learning a bit of Groovy and Java is that web frameworks like GWT will open up to you. Grails has a GWT plugin and as a front end developer you will appreciate the ease of use and cross browser compatibility.
Also there is at least one hosting company offering free Grails application hosting (http://www.mor.ph/) which means that you can prototype sites at small data volumes before having to pay.
I favor Grails over Rails, but learning Rails will give you a more balanced perspective and actually open your eyes to overlooked things that are possible in Grails.
At a first glance you would think they are completely differente stories, since they are based on extremely different languages (Ruby and Groovy).
Then, after reading a couple of tutorials, you'll realize they share the same principles, scaffolding, duck typing, .. and finally the same goal:
making agile programming feasible.
If you already feel comfortable with terms like IoC and MVC, you'll find any of these options easy and exciting to learn.
I would say no, I'm learning Grails as well, and I've considered this as well, but just learning Grails is pretty big, plus learning Groovy (which granted is easy, but still gotta learn it right?) and all that... so learning Rails would have been just too much.
Yes if we compare grails and rails I would choose grails (I developed some intranet applications in grails).
But Django is superior to both - as python is well hmm a perfect choice.
You might also want to take a look at Clojure, a JVM language that's just starting to get popular. It may be a good choice for a Java-based company since it's compatible with your old codebase, and has a lot of modern innovations going for it. There are some good web frameworks emerging, including Compojure.