Introducing Command Center – a Mini-IDE for command line Grails development

In my previous life as a Java developer, I was a devotee of the IDE – primarily Eclipse.  When I was introduced to Grails, I switched over to STS and things were good.  But, when I started a new job about a year ago and was given a company-mandated Windows laptop for development, Maven and STS expressed such mutual hatred that I was driven to explore text editor options.  After evaluating many options my life was changed forever upon finding Sublime Text 2.  (Seriously, as much as a text editor can change someone’s life, ST2 has done it – the 4-pane grid layout is a huge productivity win.)

However, moving to a text editor meant using the command line again.  The DOS prompt, 1980s-era, Windows command line, with all the joy it gives – block text selection (after right-clicking and selecting ‘Edit -> Mark’), an inability to clear  output while a command is still running, and a need for continual assurance, that yes, in fact, I do want to terminate that batch job.

Turning on logSql=true in Grails and attempting to debug the output of multiple requests in the Windows command line is a recipe for madness.  I found myself going back to STS (which by now I’d succeeded in getting working) just so I could clear the SQL output between requests.  Besides which, at this point I’d tired of typing “grails run-app” for what felt like the 10,000th time.  There had to be a better way.

Hence, the kernel of an idea for an app that would wrap the command line was born.  The result is a Java Swing app (but written in Griffon for Groovy goodness) that provides a number of conveniences without the bulk of a full IDE.

Command Center (or Grails Command Center, but I don’t think I can call it gcc – that acronym is already taken – so, suggestions on names are welcome) allows often-used commands to be configured as buttons which can then be executed in a single click.  New command buttons can be created using the “*” button, and a button’s config can be edited by right-clicking on it.

For instance, I find if I’m working on a specific unit or integration test for a while, I’ll quickly set it up as a button, click it in between code tweaks, and delete it once I’m satisfied with the resulting code and tests.

Commands can be entered directly into the combo box, with the history of these manual commands remembered in the drop-down.  Compare this to searching through your command history using the up and down arrow keys – which includes all the calls to “cls” or “clear”, and on Windows all the “y” entries to yes, really, terminate that batch job.

Output can be cleared with a keystroke (Ctrl/Cmd-W), the current command can be killed with a keystroke (Ctrl/Cmd-Q), the output can be searched and all instances of the found text highlighted, with more to come.  The Help -> About menu contains a list of possible future enhancements, but one of the main ones is to use something smarter than a text area for the output to allow for additional debugging possibilities – automatic color coding of user-specified words or phrases, font styling, etc.

There are more options in the app but I’ll mention a final one here.  While the app defaults to assuming all commands begin with “grails” – hence the “grails>” prompt above – this is configurable.  For instance, on Linux I use a script I’ve named “” which automatically determines the correct version of Grails to load based on the current project’s file, so my prompt is “>”.  An alternate way to achieve the same result would be to specify the full path to the correct bin/grails script for the current project.  And note that this prefix can be removed for a higher level of flexibility, at which point the buttons would need to be updated from “run-app” to “grails run-app”, but could also be used for non-Grails commands.

Note that currently one large shortcoming of the app is the inability to respond to requests for input in the text area.  So anything that prompts for input – “do you want to upgrade this plugin?” – will still need to be run from the actual command line.

I plan to open-source this tool on Github soon – once I’ve had the chance to clean up the code a bit and become a little more familiar with Git, honestly.  🙂  And by writing this app in Griffon, the code and project structure are very similar to Grails which should allow for easy extension and modification by Grails developers.  But in the meantime, give it a try, see what you think, and let me know.  I hope it improves your productivity and makes you hate the command line at least a little less.

Download here: GrailsCommandCenter.jar
(just in case, run the app as “java -jar GrailsCommandCenter.jar”)



This entry was posted in Grails, Griffon. Bookmark the permalink.

10 Responses to Introducing Command Center – a Mini-IDE for command line Grails development

  1. Pingback: Questa settimana in Grails (2012-32) - - Il blog di Luca Canducci: notizie, tips e nuove tecnologie dal mondo dell’IT.

  2. Pingback: An Army of Solipsists » Blog Archive » This Week in Grails (2012-32)

  3. Federico says:

    Hi, maybe the name could be GraCe

  4. Hi Dave-
    Nice idea. Can’t wait to see it on Github!
    Little bug: I set the command prefix to command-prefix”: “C:\grails-2.1.0\bin\grails” — and get

    2012-08-15 15:28:56,002 [main] ERROR griffon.util.GriffonExceptionHandler – Uncaught Exception
    groovy.json.JsonException: Expected a value on line: 1, column: 1067.
    But got an unterminated object.
    at grailscommandcenter.JsonUtil.readStringAsJson(JsonUtil.groovy:32)
    Deleting .griffon-command-center fixes the issue.

  5. davidkuster says:

    hey jeff, thanks. will post an update here once i get the code up on github. btw, i did set up the repo, it’s just empty right now. 🙂

    as for your bug, did you edit the .griffon-command-center file directly? if so i think you’d need to set the command-prefix value to use forward slashes, or else double backslashes. try: “C:/grails-2.1.0/bin/grails”.

  6. Yeah, I just blew away the config, and got around to making 210 default to not have to fully specify a full path.

  7. Way to go Dave! Keep’em posts a-coming 🙂

  8. Ken Liu says:

    any progress on open sourcing this?

    • davidkuster says:

      Ken, thanks for the ping. I had grand visions of getting all the bugs ironed out, tests written, documentation updated, etc etc etc, and then of course life intervened. I did recently make some progress, but am now planning to just throw the code out there warts and all. Look for it within a couple weeks – will post back here when it’s up.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s