Thursday, January 24, 2008

Maven Groovy Plugin Example

Here is a powerful example by a co-worker on how to use the maven-groovy-plugin in your maven2 POMs. In this example Ron shows how you can embed a Groovy script in your POM to enforce a specific size of the resulting artifact (in this case an EAR).

This is very valuable because now you can do just about anything in your POM, including adding Java code as in this example (look under Using Java Classes).

However, with this power comes responsibility and you don't want to get in the habit of using this everywhere. Usually this is a red flag meaning you should create your own plugin to be reused by everyone. We should all be able to recognize the drawbacks of Copy+Paste.

Thursday, January 3, 2008

How to connect to a Grails HSQL Database

The following is how you can use DBVisualizer to connect to a Grails HSQL Database. Grails uses Spring and Hibernate and its default database uses HSQLDB. So why would you want to view the Grails database? Maybe you are curious of how GORM works; debug your Domains; perhaps you don't trust Grails, or finally you might be a control freak. Or like me you are all of the above.

Update Datasource.groovy
First, if you want to view the development database you need to change the url to not use an in-memory database because DBVisualizer will not have access to the Grails JVM memory. Open up the DataSource.groovy file and locate the development environment section and replace the existing url "jdbc:hsqldb:mem:devDB" with "jdbc:hsqldb:file:devDB;shutdown=true".







Start Grails

>grails run-app

Create New Database Connection in DBVisualizer
Open up DBVisualizer (my version is 6.0.7) and create a new Connection (if you are unable to use DBVisualizer you can also use the HSQL Database Manager - see this post).
  1. Type in a Connection Name: Grails Development
  2. Choose HSQLDB as the DatabaseType
  3. Choose HSQLDB embedded as your Driver using the hsqldb.jar located under your Grails home directory ($GRAILS_HOME/lib)
  4. Update the Database URL to include your grails app base directory (jdbc:hsqldb:file:{your-grails-app-base-dir}/devDB). For me this was jdbc:hsqldb:file:/workspace/checkout/netcds-admin/devDB. Note that according to the HSQL document, Window users don't have to specify the C: drive.
  5. Make sure your Userid is sa
  6. Click Connect













View Tables

Then on the left you should be able to see your tables under PUBLIC --> TABLE.
















Special thanks to the Nabble users who responded to my question: Christian Laakmann and Helmut Denk.

Friday, December 28, 2007

Justify using Groovy

How does one justify using Groovy on a project? To me it's no different than including any other dependency in my project and in the end it has the same result but with a lot more benefits. There are a lot of skeptics out there, specifically among my team members, and I just can't imagine why they wouldn't want to use Groovy in their every day development. I guess in this instance "knowledge is a curse." It's kind of difficult to explain why I believe in what Groovy is doing, but I will at least give it a try.

First, the biggest initial hurdle people can't get over is they think to start writing Groovy they have to stop writing Java. That couldn't be further from the truth. Groovy was never meant to replace Java. I have used Groovy to write unit tests for my Java code and I have written Groovy code that has used Java code and vic versa. My experience has shown that Groovy and Java just work seamlessly together, especially when using the maven-groovy-plugin and the IntelliJ Idea JetGroovy plugin (for more information see More Groovy Goodies by Joe Kueser).

Secondly, to me the biggest benefit of Groovy, with no cost to the developer, is the hundreds of extra methods added to existing Java classes (see the Groovy JDK). Just by including a new dependency, I have at my disposal hundreds of new time saving methods that I can start using immediately. For example, there are approximately 50 new methods added to java.lang.String (not sure I will ever use all of them but you get the picture). Now lets say for example you were using some open source project like JFreeChart. And you were using version 1.0.8, and 2.0 was out and it included hundreds of new methods. How long would it take you to change the version in your maven2 pom? To me this is not much different than using Groovy to "extend" Java.

Finally, I want to give a quick example of what the end result of a Groovy class is since Groovy is just complied into Java bytecode. Since I have repeatedly stated that Groovy is no different than including a new dependency in your project let me prove it.

Borrowing an example from my previous post, lets say my Groovy class looks something like this:

class GroovyFileTest {
def void test() {
def file = "/workspace/sandbox/grvyfile/src/test.txt"
println new File(file).text()
}
}

My next step would be to use the Groovy Complier (groovyc) to compile my Groovy source into Java bytecode (or just use the maven-groovy-plugin). That would produce GroovyFileTest.class. Using a Java decompiler, such as Jad, here is the outcome:
public void test()
{
Class class1 = GroovyFileTest.class;
Class class2 = groovy.lang.MetaClass.class;
Object file = "/workspace/sandbox/grvyfile/src/test.txt";
ScriptBytecodeAdapter.invokeMethodOnCurrentN(class1,
(GroovyObject)ScriptBytecodeAdapter.castToType(this, groovy.lang.GroovyObject.class),
"println", new Object[] {
ScriptBytecodeAdapter.invokeMethod0(class1,
ScriptBytecodeAdapter.invokeNewN(class1,
java.io.File.class,
((Object) (new Object[] {file}))), "text")});
}

For the sake of clarity I am not including all the other information that was decompiled (well.... because it's rather long). But to summarize, my two line Groovy script is convereted to 214 lines of decompiled Java code. Initially you might think that boosts well for Groovy and really shows the benefits of Groovy, but there is a lot of Groovy going on behind the scenes.

From my perspective this is the only current argument a Groovy skeptic can make: "well look at all that extra junk they are throwing in. Isn't that going to hurt performance?". And at the end it just might. I think it's obvious that Groovy bytecode probably won't run as fast as Java bytecode, but for me the benefits out way that disadvantage.

I by no means intended this to be an exhaustive list of Groovy benefits (for that I would recommend reading the excellent but lengthy article by Guillaume Laforge on the recent Groovy 1.5 features) . I just wanted to prove that the end result is no different. Hopefully people will respond with questions and criticisms and I can respond intelligently.

To me Groovy is sort of the legal steroids of programming. Those that use it have an unfair advantage, enabling them to deliver software quicker then their competitors and co-workers.