I have worked with Grails in the past and am very familiar with it. I am inheriting a legacy application that was built in Struts 1. There are some plans for immediate improvements and talk of moving to a more modern framework long-term.
For the long-term 'Spring' has been talked about, but I was thinking a transition to Grails might be a viable option. Is there a grails-struts plug that could help with the transition or is there some other recommended process for converting the Struts paradigm into the Grails paradigm?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am starting a new project with Grails and currently have no experience in it. Grails 3.0.9 is the latest version, but I have read that some plugins are not yet compatible with Grails 3, is this true? If this is true, should I consider a previous version of Grails?
Being unexperienced in web development, I am not yet sure what plugins I will require and am therefore unable to properly evaluate my need for those that aren't useable. Do the pros of using version 3.0 outweigh the cons? Or by using the latest version do you think avoiding the hassle of upgrading plugins in the future be something worth considering above all else?
Answer to Which version of Grails should be used could vary from person to person and is highly opinion based but there are some factors that could make the decision easier.
Especially I would talk about grails 2.5 and grails 3.x versions.
Reason to Choose 2.5 version:
Well built plugin support and a wide community help available.
Lesser number of bugs are there in 2.5 version as compared to lower versions but is heavy and is low in development time performance.
Good integration with IntelliJ idea is there for newer version.
You could move fast with 2.5 due to good documentation available.
If you have no plan to upgrade grails version ever in future and the project size is smaller.
Reason to Choose grails 3.x
Though good plugin support is not yet available, I would say you may use java libraries after all and no way blocked. Most plugins just provide an easier way to setup the library environment and some helpful tags etc which we could also create ourselves. Hence it could be a bit time consuming in setup but would be faster in development later especially when you override plugin features.
grails 3.x is on gradle which makes it highly recommended to be used as compared to grails 2.5. Gradle is ultimate build tool that has over come a lot of issues or weaknesses of older build tools.
it supports spring-boot and spring at it's core but is more diligent in using it. It gives enormous power and possibilities and flexibility just like any java project.
It has become lightweight now and comes with least configurations which makes it good choice in terms of performance.
Last but not least it comes with spring 4.1, groovy 2.4 and support for traits and enhanced IDE integration.
These seems some good points to consider while making a choice for grails framework.
In last this may have several opinions from experts but ultimate choice should be the newest but with good reviews only.
Edit: Elaboration of certain points which may not be obvious to all.
supports spring-boot and spring at it's core but is more diligent in using it :
spring-boot is the quick start helper for any spring application and is used just to get you started with spring and nothing more than that. In other words, it reduces count of your dependencies in maven or build.gradle.
grails 3.x provide public static void main(String ..args){} method as entry point to run your web application which makes it more springy. At the same point you could integrate any customisation required. You could run web application like a normal java/groovy main application. By diligent, I mean that things has been integrated carefully this time and not like old buggy grails version. There could be bugs here in 3.x as well but it's way better than 2.x.
So when you start working with grails 3.x you will feel working on spring with same artefact level feel i.e. domains, controllers and services would all behave same as earlier but you will notice configuration level changes like yaml files, libraries used etc.
In one sentence, after all it's spring / hibernate used inside, you know spring/hibernate you know grails more than anyone else knows
I am new to Grails as well. Just started to learn and doing a project for the past 5-6 weeks. I'm using 2.4 and still finding that some useful plugins are not compatible. Also a lot of books and documentations are done with 2.3. I'm thinking about redoing my project in 2.3 to make my life a bit easier.
Yes, as #vahid mentioned, good for learning. I first need to figure how Grails work with good examples.
My setup is a small JSF2.2 application. This application has two ManagedBean classes, which both implement the same Interface. One written in Mockito used for development and unit testing (we're using TestNG) and one written in ActiveMQ, used for Production and CI. How do I tell the Facelet which implementation to use? In spring I would use a different application-context, in Guice a different AbstractModule. Now before you say use CDI or EJB for this, there's a little catch, for various legacy reasons, beyond my control, or sphere of influence, we're not using a proper JavaEE container (we're using Jetty 9 (upgraded less than 2 months ago from Jetty 6, so yeah).
Now my first reaction would be "Go with what you know", but wiring Guice or Spring Beans into a JSF/PrimeFaces application just feels redundant and wrong.
So my somewhat long-winded question is, is there something I'm overlooking? What is the pure-JSF equivalent of a Spring #Configuration or Guice AbstractModule? Is Spring/Guice/CDI really a requirement for this?
I am wondering, do we have any framework / library that makes development easier?
For example, Apache Mina or Netty makes NIO programming easier.
I heard of Spring JMX, MX4J, are they very easy to use?
I've used Spring for it. It's very easy to use (especially if you already use Spring in your project) but it cannot handle some more advanced things (like MXBeans). In my current project we use a lot of the things that Spring offers but have implemented some parts ourselves.
http://static.springsource.org/spring/docs/3.0.5.RELEASE/reference/jmx.html
I like servo which was opensourced by netflix.
See [1].
[1] http://techblog.netflix.com/2012/02/announcing-servo.html?m=1
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