Archive for November, 2008

G2One acquired by SpringSource and Grails 1.0.4 released

Saturday, November 15th, 2008

It has been a busy week for the Groovy and Grails teams. On November 11, it was announced that G2One, the company behind Groovy and Grails was acquired by SpringSource, the company behind the Spring Framework. You can find details about this at the SpringSource web site.

On November 14th, the release of Grails 1.0.4 was announced. You can get it from the Grails download page.

I have used portions of the Spring Framework for years. I have always thought their product was reliable and well documented. This work was primarily in server side development and, as such, did not use a lot of the features of the entire Spring Framework.

I have been playing around with Groovy and Grails for a couple of years now. I’ve deployed some Groovy applications, but Grails has been a learning exercise for me. Like I said, most of my work has been on the server side. However, I’m amazed at how quickly someone can have something functional in Grails. Maybe someday I’ll be able to use it on a real project.

I’m also looking forward to seeing what happens now with Groovy and Grails. I would expect to see the adoption increase with the respected name SpringSource now behind them.

Grails doc (Groovydoc) not quiet there yet

Saturday, November 8th, 2008

I spent some time today looking into the Grails doc script for generating Javadoc and Groovydoc for a Grails application. The script creates a docs directory (in the grails application directory) and, within that directory a directory for Javadoc (api) and a directory for Groovydoc (gapi).

The generated Javadoc looks as you would expect it to look. However, I ran into an issue when creating a package.html file to provide a description of the package. The grails script passed package.html as the name of a package to be processed by javadoc. The end result of that error was no Javadoc was produced until I removed that file.

The generated Groovydoc appears to handle methods fairly well, however links to Java classes (return types, parameters, etc.) are not created. Fields don’t appear to be handled at all, which is a disappointment. Since a lot of Groovy code relies on implicit getters and setters, I believe this is a pretty big issue.

A post in groovy-dev this summer by Hans Dockter, the project lead for Gradle, states that Groovydoc not being production ready is a critical problem for Groovy. I agree with him. The popularity of Groovy seems to continue to grow and developers are looking for code and documentation to expedite their learning.

I must point out that there have been recent improvements to Groovydoc. I hope progress will continue and we will see some significant improvements in Groovy 1.6.