Put this following code inside of your_grails_app/scripts/ScriptTest.groovy

target ( default : 'Print args and java system properties' ) {
    //grails script-test arg1 arg2
    println "Grails CLI args"
    println Ant.project.properties."grails.cli.args" 

    //grails -Dprop1anything script-test
    println "Java system properties of prop1"
    println Ant.project.properties.prop1
}

So now you can run the following

$grails -Dprop1=anything script-test arg1 arg2
Welcome to Grails 1.1.1 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: /Library/Grails/Home

Base Directory: /Users/mjwall/src/sample1
Running script /Users/mjwall/src/sample1/ScriptTest.groovy
Grails CLI args
arg1
arg2
Java system properties of prop1
anything


For all it’s complexity, I like maven. Sometimes it makes complex tasks easier, but not always. Here is my situation. There are several java projects already using maven. I am building a grails project that will be used by some of these projects. The easiest integration is to package up a war file and deploy it to our local maven repository. Nexus is great by the way. The other projects can include my grails project as a dependency. So what is the best way to do that? Right, I hear you. By hand. However, I need to automate this.

I looked at the grails-maven-plugin, but it is too much. I am not trying to mavenize my project, just deploy it to Nexus.

Luckily, there is as a cleaner answer. Creating scripts in grails is easy. Those scripts can use the maven-ant-tasks. Download the jar file and put it in your lib directory.

I’ll create 2 tasks, one handle the ‘maven install’ so I can test locally and one to handle ‘maven deploy’. We need a pom file, but instead of checking one in, let’s generate it from the project so it picks up the latest version etc. (Note, I studied the gant build file pretty closely). Here is an example of MavenInstall.groovy file from the scripts directory

Not too scary, but what is going on here? The default task you will see depends on the war file being built. A temporary pom is created using the value defined in application.properties. Then the maven-ant-task for install is run and the pom is deleted. Pretty simple huh? It is once you see an example anyway.

How about a maven deploy. Basically the same thing, except the pom needs to generate a distributionManagement section. I set up a couple of properties in my Config.groovy at the end called maven.remoteReleaseUrl and maven.remoteSnapshotUrl. Change the pom generate to include them. Looks like this

Then instead of calling ant.”${antlibXMLns}:install”, call ant.”${antlibXMLns}:deploy”

Couple of notes. I did run into problems with my settings.xml file defined in ~/.m2, so I ended up creating one much like I did with the pom.xml. Only used when deploying, so it is not built for the install. Finally, because grails can only run one task per script, I DRYed up this whole thing with one file called MavenUtils that included all code for both install and deploy. Then, my MavenInstall file just loads the MavenUtils and calls install.

Wow, more explanation than I thought it would. And I guess the title is not entirely accurate. I am using maven, but not by calling the maven executable directly. Hopefully the new Maven/Grails integration will make this easier. Fingers crossed.

So, I did some digging through the bug tracker and subversion for the plugin. I also spent some time learning about IntelliJ plugins and reading newsgroups about what others have tried. The result is a patched version of the plugin that seems to be working. Here is the file if you want to try it. Unzip and replace the contents in your INTELLIJ_HOME/plugins/Groovy directory. Again, use at your own risk and backup your existing plugins/Groovy directory.

If you are interested, here are the details.

• Running on a Mac with java 1.5
• Check out code from http://svn.jetbrains.org/idea/Trunk/bundled/groovy
• Revert back to revision 21543. 21544 breaks something. Revision 21538 fixed the initial issue I saw, where the grails-1.1-beta2 library was not recognized, as reported in GRVY-1933.
• Add in revision 21697, which fixes GRVY-1943 so the app can run.
• Setup IntelliJ 8.0.1 build 9164 with the dev package
• Configure IntelliJ to build the plugin. These instructions helped. Groovy module configured to use Groovy-1.6_RC1. RT module configured to use groovy-1.5.7, cause 1.6 didn’t work.
• Build grammer with ant task, run Make and then run ‘Prepare All Plugin Modules for Deployment’.
• Shutdown IntelliJ.
• Remove INTELLIJ_HOME/plugins/Groovy directory. Unzip groovy.zip in INTELLIJ_HOME/plugins directory
• Restart IntelliJ

Hope it works for you and Happy New Year.

So I tried the EAP 9572 version to see if it included the fix that was reported in Jira. The bundled jetgroovy plugin appears to have the update. Yippee. Glad I didn’t have to build it myself according to the wiki,

Here is the interesting part that you may care about. I zipped up the plugins/Groovy folder and replaced the old version in Intellij 8.0.1. It seems to have fixed it for the stable version as well. Here is the file until JetBrains has something better. Use at your own risk, perhaps making a backup of the old plugins/Groovy folder.

UPDATE It appears there are issues with copying the plugin back to the 8.0.1 release. Loading the file inside grails-app just hangs. However, the EAP version is working just fine so far. Let me know if you have success getting it work in the stable version.

UPDATE 2 See this for a patched version that works better.

So I would like to detail some of the things I have missed noticed in the couple of months I have been back.

Productivity, everything just seems to take longer with Java.  Maybe I am just rusty, or maybe is the a combination of some of the other things listed here

Convention, there are too many choices I have to make and too many things I have to decide that distract me from writing the code.  Before I went to Ruby, I was an ant guy.  Now I am using maven and I think I like it.  The out of the box convention just feels better.  Still not sure about the dependency management though

Not needing an IDE, Vim and I have been friends for a long time and our friendship grew during my time as a Ruby developer.  Now that I am back to Java, I keep getting pulled toward an IDE again.  I used eclipse in the past, but I thinking I will go with IntelliJ.

Libraries, I forgot how many libraries there are.  It is nice to have a choice, but it sure adds time.

BDD/TDD, takes a lot longer.  I keep preaching, but it takes so much more effort the by in is just not there.

IRB, wow do I miss you.

Class Design is certainly different(better?)  I think part if it come trying to make to make things more testable and part of it comes from more focus on the DRY principle.

I’ll post more comments as I go.  Be on the lookout for Grails posts, as I just started rewriting a rest service with it.

Excuse me sir, can I see your license to commit please?

We can have some fun with that one.

This license expired just before the dotcom bubble

You have a languague restriction here that says you can commit only while wearing vb.net

I need to see some proof of build collision insurance.

But I digress. Sorry, back to the program.

As rails grows, I have some questions.

1. Where the heck is code for cruise control?
2. Can I use git?
3. Will it run against rails 2.1 since I am security conscience and have updated after the recent warnings and threats?

Let’s do some research.  The code used to be at rubyforge. Looks like the code is still there. However, according to this post, they are moving to github. The link in that post has an extra *, but sure enough, you can find cruisecontrol.rb at http://github.com/thoughtworks/cruisecontrol.rb. Cool, now I know where to get it.

What about git support?  A google search, turns up benburkert’s github branch. Looks promising. Searching git hub for cruisecontrol.rb shows several forks, but these are all from rubyforge git.  I want it straight from thoughtworks.  Digging a little in the code shows it is already in the thoughtworks master.  There is even a mercurial adapter.  Let’s give it a try. Sure enough, it works just fine with

cruise add projectname -r file:///home/me/src/gitproject -s git

Run

cruise help add

for all the options.

Great, 2 for 2.  Now what about support for Rails 2.1?  Unfortunately, it is not there. Cruisecontrol.rb currently runs with rails 1.2.3, and a simple version change in environment.rb doesn’t fix it. (Didn’t figure it would but I had to try it right?)  For all of us who have updated to ruby 1.8.7, we are stuck for now. Ruby 1.8.7 only runs rails 2.1. My last post about multiple version of ruby doesn’t really help either.

I did find this post answered by the team about porting cruisecontrol to merb. That sounds interesting indeed.

Until then, who is working on a rails 2.1 version of cruisecontrol.rb?

• Looks like Merb 0.9.2 got some fcgi love. That is what I want to try to replace rails on my shared host.
• Get on IRC if you need help – irc.freenode.net#merb. Really, IRC.
• If you can’t stay on IRC, go to http://groups.google.com/group/merb for a log
• Use these sake tasks if you are running the latest. sudo sake merb:update merb:install will update core, more and plugins
• merb-rspec is no longer in plugins, but included in core
• Watch this from Confreaks. Worth the investment.
• Most tutorials and articles are dated. This one helped though.

Looking forward to more from merb….

UPDATE: Having some trouble with typo’s caching. Going to repost this article.