Overall I have enjoyed the development experience with Grails and I am excited about its future. I am a heavy Eclipse user so along with a number of folks in the community I have been a bit disappointed with the support in my favorite IDE. However, instead of letting that stop me I spent some time getting Eclipse to work better with Grails.
I realize that SpringSource is working to get better Grails support in Eclipse, but until then here are some tips and tricks that should help you have a more pleasant development experience. I break the setup instructions into the following:
Eclipse 3.4.2
Grails 1.1
Groovy Eclipse Plug-in 1.5.7 (Eclipse Update Site: http://dist.codehaus.org/groovy/distributions/update/)
The Grails Wiki offers some basic setup instructions for Eclipse/Grails development. These are helpful instructions to get you started but are lacking in areas. You can find these instructions at: http://grails.org/Eclipse+IDE+Integration. Although these are a bit dated, it provides a helpful reference.
I find it is helpful to know where Grails is generating all the artifacts necessary to compile, test, run, and deploy your application.
So you have Eclipse 3.4, the Groovy plug-in installed and a workspace created and ready to get going on starting development on a new Grails project. Where to start?
Before getting too far let’s prepare the Workspace for Grails development.
Default Groovy compiler output location: bin-groovy
Check the option Disable Check Package Matches Source Directory
Need the _GRAILSHOME\ Environment variable set. Goto Windows->Preferences->Java->Build Path->Classpath Variables ->New.
That is it – for now!!
Here are the steps to follow to get a new Grails project into Eclipse:
Open a command-line to the desired location you would like your Grails project to reside. Create your Grails project: grails create-app someAppName
Within your Eclipse workspace’s Java Perspective:
Right-click in the Package Explorer and select Import
Select General->Existing Projects into Workspace
Choose the directory where you created the Grails project
Select the project *Do Not check the option: Copy projects into workspace
Click Finish
Grails does generate an Eclipse-friendly project for importing. However this is where “tweaking” is required to get Grails working effectively within Eclipse.
Now you must set the Groovy plug-in settings for your newly imported project. When Grails creates your project it sets some defaults that we must re-configure – this is one of them.
Open the Project’s Properties
Select Groovy Project Properties and do the following:
Default Groovy compiler output location: bin-groovy
Uncheck the option Disable Groovy Compiler Generating Class Files
Check the option Disable Check Package Matches Source Directory
You will notice that the project rebuilt, and generated Groovy classes are output to bin-groovy.
To avoid switching from Grails command-line to Eclipse you can setup an external tool configuration within Eclipse to run Grails commands and refresh the workspace resources automatically.
Open External Tools Configurations
Right Click Program and select New
Name the Program Grails
Enter the path to the Grails exe or script (eg: GRAILS_HOME/bin/grails.bat for Windows)
Enter _${projectloc}\ in the Working Directory
In arguments enter _${stringprompt}\
On the Refresh tab, check Refresh resources upon completion. Select the option The project containing the selected resource
On the Common tab check the option to select display in favorites menu
Done. Test this out by:
Selecting the project in the Package Explorer
Run the External Tool
Enter string: create-domain-class TestDomain
You should see a TestDomain.groovy file in grails-app/domain source folder.
Now you can run any Grails commands on your project to start generating your various artifacts!
You can use this same approach to setup any number of useful external tools for common Grails commands to further reduce command typing.
Let’s start with creating a Run Configration for the project. One nice thing is when Grails generated the initial project, it created “most” of what we need to setup a run configuration in Eclipse. We will have to tweak it a bit:
Open Run Configurations
Select Java Applications->{your project should be in the list}
On Environment tab you have to add a JAVAHOME and GRAILSHOME environment variable.
On Source tab add your Java Project for debugging purposes
On Common tab Display in Run and Debug Favorites menus
Apply and Done
Test the run, by selecting the run configuration in the Run menu
Verify the Grails app is running by looking at the Eclipse Console
Browse to http://localhost:8080/
You see your app come up. Great!!
Stop the application from Eclipse console.
Just to verify that you can debug your Grails project within Eclipse, let’s carry through with the example started in the previous steps.
Open the TestDomain.groovy class and add a property – how about String testString. Save the file
Select the project, and with the Grails External Tool enter generate-all TestDomain to generate all the wonderful Grails scaffolding for you domain
Open the TestDomainController. Create a private method testDebug with a few lines code so you can set a breakpoint within this method. within the list closure call this newly created method
Start the application in Debug mode – from the Debug Run configuration menu
Open the application in the browser
Select the controller link. You should be directed to the Eclipse debugger where it is stopped at your breakpoint.
There may be a need to override the VM settings configured for your Run Configuration. To change these settings, open the Run Configurations, select your Grails project run configuration, and navigate to the Arguments tab. From here you can change VM settings to change to common things such as max heap and perm size. Here is an example:
_-Dbase.dir=”${projectloc:
Sometimes I add directories to the project source directories allowing me to more easily navigate to key areas of my Grails project. Some directories I add are:
grails-app/views
web-app/js (JavaScript files)
WARNING: Be careful not to place any groovy or java files in these source directories as Eclipse will pick them up as part of your runtime classes (small price to pay for easier navigation).
I ran into this issue when I had a Grails project that depended on the Grails Acegi (Spring Security) Plug-in. When working with the project in Eclipse I was getting all sorts of compile problems until I found a way to make Eclipse’s classpath happy so I could continue using Eclipse for Grails development.
Let’s say you have a Grails project that uses the Acegi plug-in for security, and has generated security controllers and domain classes – as per the Acegi plug-in instructions. When the Grails project is brought into Eclipse you will notice all sorts of compile errors.
This will force you to modify the Eclipse classpath to resolve these errors. Make sure that any entries you add to the Eclipse classpath are not exported for dependency projects in Eclipse (see screen shot below). Here is how it is done:
In order to resolve Acegi plug-in errors add the following to your project’s Java Build Path->Libraries (you may not need all of these):
That should be it! Your compile errors go away and you can continue to use Eclipse with your Grails Project.
A similar technique can be applied to resolve other classpath inconsistencies between Eclipse and Grails that you run across.
Since you specified to generate groovy class files to a directory (ie: bin-groovy) that should be enough to run Grails unit tests in Eclipse. Running unit tests from eclipse is a lot faster than running them from the command line, because eclipse will generate the class files needed as you develop. It’s really nice to have.
Grails integration tests require the Grails environment to be loaded and therefore must be executed via the Grails command line or via the Grails external tool you created in Eclipse. I find the external tool, with automatic refresh does the job just fine for integration tests.
One frequent hole in Test Driven Development (or any other comprehensive attempt to test) in Java web applications is the presentation layer. Especially when using an MVC pattern to separate the work from the display, the trend is to do that testing…
For the past several weeks, I’ve been working on a Grails app in my spare time, and I’m really excited about the future of Grails. However, I’ve been a bit disappointed in the tooling currently available. Myself and many of my clients use Eclipse…
At my current client, there’s a drive to put more unit tests on the Java code. It’s been a long hard process as few of the developers do strict, or even just “mostly,” test-driven development. As an attempt to try and drive this home, they’ve also…
Torey is a Chief Technologist at Object Partners Inc. specializing in Mobile & Enterprise technologies with over 19 years of professional experience. Most recently he has led a number of iOS-related projects, applying his expertise in building HTML5 and Native Objective-C & Swift-based apps for iOS (iPad/iPhone). He has led the development of various mission-critical applications and supports a pragmatic delivery approach using various agile methodologies. During his career he has gained expertise with iOS, Java/JEE ecosystem and its related open source (ie: Spring-related, Tomcat), Groovy/Grails, JavaScript & technologies (ExtJS, AngularJS) to deliver rich internet applications (RIAs), and various commercial technologies (ie: IBM/Tivoli, Oracle, Tibco).
