So Grails 1.1 Beta 2 is out. Rejoice! There are many new features that are detailed in the release notes. However, one of the main ones in this beta is the new support for Maven.
Regular readers of my blog will probably be aware of my long history as one who, ahem, is not particularily fond of Maven. Granted I am still not particularily fond of Maven, but it is the Christmas period and in the spirit of "why can't we all just get a long" I am proud to say that Grails integrates nicely with Maven now :-)
Peter Ledbrook, core Grails committers, has been tirelessly working away at making the Grails + Maven experience a seamless one. I personally even went as far as installing Maven 2 onto my machine, which was a huge jump for me I can tell you, and I can tell you Peter's done a great job!
As ever we encourage Maven users to give the Maven integration a go and report any issues that you may have with it in JIRA. Enjoy!
Tuesday, December 23, 2008
Tuesday, December 09, 2008
Grails + Spring Integration
Regular readers will recall I mentioned in my announcement of the SpringSource acquisition of G2One that the potential to integrate Grails with more Spring portfolio products is huge. Well, SpringSource colleague Russ Miles has taken the first steps in integrating Grails with Spring Integration 1.0.
For those of you who don't know, Spring Integration is a lightweight way to do message passing through endpoints in a similar way to some of the big ESBs. The article is a precursor to even more exciting stuff involving Spring Integration being made available as a Grails plugin. Watch this space.
For those of you who don't know, Spring Integration is a lightweight way to do message passing through endpoints in a similar way to some of the big ESBs. The article is a precursor to even more exciting stuff involving Spring Integration being made available as a Grails plugin. Watch this space.
Tuesday, November 25, 2008
Interview with me on Grails Podcast
Those crazy guys over at the Grails podcast interviewed me about various things ranging from being part of SpringSource to the upcoming Grails 1.1 release to my deep hatred of all things Maven. Check it out.
Tuesday, November 11, 2008
Groovy and Grails join the Spring family
You may have already read about it in the various news outlets and blogs covering the announcement, but if you haven’t I’m excited to spread the word that G2One - The Groovy/Grails company - has been acquired by SpringSource. The result is that Groovy and Grails join the growing number of excellent Open Source projects delivered by SpringSource.
The Spring Framework really pioneered simplified development on the Java platform. A philosophy that is the very essence of Grails. Both frameworks aggressively try to makes the lives of developers easier. The Spring Framework provides an abstraction layer of common Java enterprise APIs, whilst Grails uses the Groovy dynamic language to further simplify Spring and Java. In this sense Grails fits perfectly into SpringSource’s philosophy.
On the Grails front this is great news at multiple levels. With Grails already being based on Spring, users of Grails now have access to expertise about not only Grails, but also Spring, the framework that underpins all of Grails. Grails will benefit further from tighter integration with the Spring Framework with exciting integration possibilities on the horizon between Grails and great Spring portfolio products like Spring Batch, Spring Integration and SpringSource dm Server.
Grails will benefit from greater visibility and wider adoption simply by being under the SpringSource umbrella. In addition, SpringSource will bring all their expertise around Eclipse plugin development ensuring that users of Groovy and Grails have a first class experience in the Eclipse IDE.
At SpringSource, there is a lot of excitement about Groovy and Grails. Grails adds that little bit of Web 2.0 spice to the company and provides yet another avenue for users to adopt the Spring Framework. We’re literally buzzing with ideas on how Spring, Groovy and Grails can be integrated in the future and look forward to the feedback of the respective communities.
I personally will continue to lead Grails at SpringSource, whilst Guillaume remains the project lead of Groovy. The majority of the former G2One team have taken up positions at SpringSource. On the topic of Guillaume, he is as excited about this development as I am and has a great post on the benefits of the acquisition to Groovy. Check it out!
Resources:
The Spring Framework really pioneered simplified development on the Java platform. A philosophy that is the very essence of Grails. Both frameworks aggressively try to makes the lives of developers easier. The Spring Framework provides an abstraction layer of common Java enterprise APIs, whilst Grails uses the Groovy dynamic language to further simplify Spring and Java. In this sense Grails fits perfectly into SpringSource’s philosophy.
On the Grails front this is great news at multiple levels. With Grails already being based on Spring, users of Grails now have access to expertise about not only Grails, but also Spring, the framework that underpins all of Grails. Grails will benefit further from tighter integration with the Spring Framework with exciting integration possibilities on the horizon between Grails and great Spring portfolio products like Spring Batch, Spring Integration and SpringSource dm Server.
Grails will benefit from greater visibility and wider adoption simply by being under the SpringSource umbrella. In addition, SpringSource will bring all their expertise around Eclipse plugin development ensuring that users of Groovy and Grails have a first class experience in the Eclipse IDE.
At SpringSource, there is a lot of excitement about Groovy and Grails. Grails adds that little bit of Web 2.0 spice to the company and provides yet another avenue for users to adopt the Spring Framework. We’re literally buzzing with ideas on how Spring, Groovy and Grails can be integrated in the future and look forward to the feedback of the respective communities.
I personally will continue to lead Grails at SpringSource, whilst Guillaume remains the project lead of Groovy. The majority of the former G2One team have taken up positions at SpringSource. On the topic of Guillaume, he is as excited about this development as I am and has a great post on the benefits of the acquisition to Groovy. Check it out!
Resources:
Monday, November 03, 2008
Couple of nice Grails UI articles
Matt Taylor has posted a couple of nice articles demonstrating how to use GrailsUI's dataTable component. Cool stuff.
Saturday, November 01, 2008
GrailsUI 1.0 Released
Over the past few months we've had a lot of demand from different clients for a UI component library for Grails, built and supported by G2One. Thanks to a great collaborative effort, GrailsUI 1.0 is now available built on the excellent Yahoo UI library.
Matthew Taylor, G2One Software Engineer and the lead of the GrailsUI project, has the lowdown on what is on offer. Check it out!
Matthew Taylor, G2One Software Engineer and the lead of the GrailsUI project, has the lowdown on what is on offer. Check it out!
Friday, October 31, 2008
New GORM Features Coming in 1.1
Now that The Definitive Guide to Grails 2nd Edition (barring a few reviews) is a wrap, I've been refocusing in Grails development. First up, is GORM and we've implemented a number of great improvements including:
Better GORM events
Previously, GORM supported beforeInsert, beforeUpdate and beforeDelete events, now there is afterInsert, afterUpdate and afterDelete to complete the picture
Persistence of Collections of Basic Types
GORM now supports persisting basic types like String, Integer and so on using a join table:
It is now simpler to bind data to a subset of properties. Previously you could use the syntax:
Persistent instances can now be loaded in a read-only state using the read method:
Associations can now be sorted using a default sort order declared at the class level:
GORM now supports configuring batch fetching (an optimization of lazy loading) using the ORM DSL at the class level:
There is a new InList suffix that can be used with dynamic finders:
Many-to-many and Unidirectional One-to-many associations can use the joinTable argument to alter the way they map to the underlying database:
Better GORM events
Previously, GORM supported beforeInsert, beforeUpdate and beforeDelete events, now there is afterInsert, afterUpdate and afterDelete to complete the picture
Persistence of Collections of Basic Types
GORM now supports persisting basic types like String, Integer and so on using a join table:
class Person {
static hasMany = [nicknames:String]
}It is now simpler to bind data to a subset of properties. Previously you could use the syntax:
person.properties = paramsperson.properties["firstName","lastName"] = paramsperson.properties["firstName","lastName"].each { println it }Persistent instances can now be loaded in a read-only state using the read method:
def book = Book.read(1)Associations can now be sorted using a default sort order declared at the class level:
class Book {
String title
static mapping = {
sort "title"
}
}class Author {
static hasMany = [books:Book]
static mapping = {
books sort:"title"
}
}GORM now supports configuring batch fetching (an optimization of lazy loading) using the ORM DSL at the class level:
class Book {
String title
static mapping = {
batchSize 15
}
}class Author {
static hasMany = [books:Book]
static mapping = {
books batchSize:15
}
}There is a new InList suffix that can be used with dynamic finders:
def groovyBooks = Book.findByAuthorInList(['Dierk Koenig', 'Graeme Rocher'])def books = Book.findByTitle("Groovy in Action", [cache:true] )def books = Book.findByTitle("Groovy in Action", [lock:true] )Many-to-many and Unidirectional One-to-many associations can use the joinTable argument to alter the way they map to the underlying database:
class Book {
String title
static belongsTo = Author
static hasMany = [authors:Author]
static mapping = {
authors joinTable:[name:"mm_author_books", key:'mm_book_id' ]
}
}
class Author {
String name
static hasMany = [books:Book]
static mapping = {
books joinTable:[name:"mm_author_books", key:'mm_author_id']
}
}
Thursday, October 02, 2008
Sky.com relaunches written in Grails
The main portal for Sky television has relaunched written in Grails. Sky, also known as British Sky Broadcasting or BSkyB, employs 17000 people in the UK and operates the largest satellite network in the UK.
The site receives a million+ hits per day and joins all the other subsites also written in Grails:
Congrats to the Sky team!
Update 07/10: Couple of new things have arison since this was posted. Firstly, Sky actually employ 17000 people not 11000. Seems the Google sample data I obtained was out of date.
Also Glenn Saqui has a nice write-up on the architecture of Sky.com on Marc's Blog. Altogether the 4 subsites listed above receive over 110 million hits per month and run on a cluster of web layer machines and 2 db machines. Checkout the aforementioned link for more info.
The site receives a million+ hits per day and joins all the other subsites also written in Grails:
Congrats to the Sky team!
Update 07/10: Couple of new things have arison since this was posted. Firstly, Sky actually employ 17000 people not 11000. Seems the Google sample data I obtained was out of date.
Also Glenn Saqui has a nice write-up on the architecture of Sky.com on Marc's Blog. Altogether the 4 subsites listed above receive over 110 million hits per month and run on a cluster of web layer machines and 2 db machines. Checkout the aforementioned link for more info.
Tuesday, September 02, 2008
Terracotta meets Grails with the Terracotta for Grails plugin
Our busy community of plugin developers have been at it again and now there is a brand new plugin for Grails that adds support for the Terracotta data grid. It was always possible to do this with a bit of manual configuration, but now the plugin automates things nicely using a few new Grails command line scripts.
This is one of the really great things about Grails and Groovy, because Groovy classes are just standard Java classes it is possible to integrate Groovy or Grails applications with any existing Java infrastructure, including data grids like Terracotta and Coherence. Awesome stuff.
This is one of the really great things about Grails and Groovy, because Groovy classes are just standard Java classes it is possible to integrate Groovy or Grails applications with any existing Java infrastructure, including data grids like Terracotta and Coherence. Awesome stuff.
Monday, September 01, 2008
Groovy/Grails Community goes wild launches two sites
Wow, the Groovy/Grails community is really getting it together. First we had the launch of grailscrowd.com, which is a social networking site for Groovy/Grails people to connect with other Groovy/Grails people. The site is built on Grails and its only been up for a few days but aldready over 600 people registered. If you haven't done so do so! The source code for GrailsCrowd is also availabe at Github
Not to be outdown, however, Glen Smith has launched the Groovy Awards ! A site dedicated to nominating the best contributors and to the Groovy / Grails community. Awards up for grabs include Groovy / Grails t-shirts and other goodies. Check it out.
On my front, I know I have been rather inactive posting. Books are really all consuming beasts. I have given a go to twittering now and again about what I'm writing about, although I'm still not sure I "get" twitter.
Not to be outdown, however, Glen Smith has launched the Groovy Awards ! A site dedicated to nominating the best contributors and to the Groovy / Grails community. Awards up for grabs include Groovy / Grails t-shirts and other goodies. Check it out.
On my front, I know I have been rather inactive posting. Books are really all consuming beasts. I have given a go to twittering now and again about what I'm writing about, although I'm still not sure I "get" twitter.
Monday, July 28, 2008
London Groovy/Grails User Group Meeting - 31st July 2008
I'll be giving a talk on the state of Grails at the London Groovy+Grails user group meeting on the 31st of July. Skills Matter are hosting it as usual, be sure to sign-up here.
Monday, July 14, 2008
Groovy/Grails Training in North America
Apologies for not posting as frequently recently, I've been hard at work on the second edition of "The Definitive Guide to Grails" and also working on feature development for Grails 1.1 (we now have JSP tag library support in GSP and massive improvements to the plug-in system).
Nevertheless, on to the topic of this post, we (G2One Inc - The Groovy/Grails company) have launched our public Groovy & Grails training programme in the US. Announcing this exciting news is Jeff Brown, our main guy in the US, who has this to say:
"Our training events are a fantastic experience. G2One are the folks who lead and sustain the development of both Groovy and Grails. No one understands the technology better than the people who build it. G2One training events give developers an opportunity to spend several days with a technology expert covering everything from fundamentals to advanced language and framework features.
The sessions include a perfect mix of lecture and reinforcing lab work. That hands on approach is a great way for developers to internalize the details. There is no better way to quickly get a team up and running with the technology."
Check it out!
Nevertheless, on to the topic of this post, we (G2One Inc - The Groovy/Grails company) have launched our public Groovy & Grails training programme in the US. Announcing this exciting news is Jeff Brown, our main guy in the US, who has this to say:
"Our training events are a fantastic experience. G2One are the folks who lead and sustain the development of both Groovy and Grails. No one understands the technology better than the people who build it. G2One training events give developers an opportunity to spend several days with a technology expert covering everything from fundamentals to advanced language and framework features.
The sessions include a perfect mix of lecture and reinforcing lab work. That hands on approach is a great way for developers to internalize the details. There is no better way to quickly get a team up and running with the technology."
Check it out!
Monday, June 16, 2008
Brian Guan on Grails at LinkedIn
Brian Guan, one of the pioneers of Grails use within LinkedIn, has started a blog series about their experiences with Grails. The first post presents the slides the LinkedIn guys presented at the recent Groovy/Grails meetup at JavaOne. It makes for an interested read so check it out!
Friday, June 06, 2008
Grails 1.0.3 Released
We've just released Grails 1.0.3, which includes 230 issues resolutions and improvements since the last release. The release notes go through the full details, including outlining some of the new features like enum support and interactive mode.
Grails has come a long way, since the release of 1.0 Grails has been downloaded over 186000 times averaging out to around 50000 times per month. That puts it on par or not far behind some of the biggest open source projects like Spring, Hibernate and Struts in terms of downloads.
The most exciting thing for me though is the plug-in community with over 70 plug-ins in the repository some of the new ones include Axis 2 support, Java2D with GraphicsBuilder and profiling (contributed by one of the biggest Grails users LinkedIn) and debugging plug-ins. Awesome stuff.
Now I'm shifting my focus to the second edition of the book, and feature development for Grails 1.1.
Grails has come a long way, since the release of 1.0 Grails has been downloaded over 186000 times averaging out to around 50000 times per month. That puts it on par or not far behind some of the biggest open source projects like Spring, Hibernate and Struts in terms of downloads.
The most exciting thing for me though is the plug-in community with over 70 plug-ins in the repository some of the new ones include Axis 2 support, Java2D with GraphicsBuilder and profiling (contributed by one of the biggest Grails users LinkedIn) and debugging plug-ins. Awesome stuff.
Now I'm shifting my focus to the second edition of the book, and feature development for Grails 1.1.
Friday, May 23, 2008
Groovy Grails Training From G2One and Callista Enterprise
G2One, Inc. and Callista Enterprise AB have announced a partnership to support Advanced Groovy and Grails training in Scandinavia.
Göteborg 2008-09-08
Stockholm 2008-09-15
Malmö 2008-09-22
The 3 day comprehensive course covers details from intro to advanced for both the Groovy language and the Grails framework. The course description may be found here.
As with all G2One training events, students will receive a free 12 month license for IntelliJ IDEA. IDEA's JetGroovy brings fantastic support for both Groovy and Grails to the IDE.
Please contact us at training at g2one dot com with any training related inquiries.
Göteborg 2008-09-08
Stockholm 2008-09-15
Malmö 2008-09-22
The 3 day comprehensive course covers details from intro to advanced for both the Groovy language and the Grails framework. The course description may be found here.
As with all G2One training events, students will receive a free 12 month license for IntelliJ IDEA. IDEA's JetGroovy brings fantastic support for both Groovy and Grails to the IDE.
Please contact us at training at g2one dot com with any training related inquiries.
Thursday, May 22, 2008
Grails in Depth slides from JavaOne 08
Although I wasn't able to make JavaOne due to my bought of pneumonia, Guillaume did an excellent job of delivering my presentations and then did everyone a favour by posting them online! Here we go for those who haven't seen them yet:
Monday, May 19, 2008
Grails.org now powered by Grails
We've just launched a re-write of the Grails.org site in Grails. Previously the site was powered by Confluence (the Atlassian wiki), now in the spirit of eating ones own dog food it is a fully Grails powered site.
Ever since the Seam guys launched seamframework.org powered by Seam I felt something had to be done, before we could look them in the face again ;-)
Now its there and its more than a simple page turner, but a full featured wiki engine including versioning, diff'ing etc. and the source code is available at Codehaus. Enjoy!
Ever since the Seam guys launched seamframework.org powered by Seam I felt something had to be done, before we could look them in the face again ;-)
Now its there and its more than a simple page turner, but a full featured wiki engine including versioning, diff'ing etc. and the source code is available at Codehaus. Enjoy!
Saturday, May 10, 2008
On missing JavaOne 08
As I write this JavaOne 08 is being wrapped up and I am horizontal in bed. I somehow managed to get pleurisy and pneumonia a few days before the event so missed it completely.
Luckily, the awesome Guillaume Laforge delivered my talks on Groovy and Grails instead of me, but sorry to those who were expecting to see me there, health comes first in this case.
It seems to have been another successful conference from what I could infer from the twitter feed and various blog postings. Was nice to hear Groovy in Action was 3rd and The Definitive Guide to Grails 6th of the best seller list after day 1.
On that topic of the books, being bed bound for a couple of weeks has given me the chance (when I'm not sleeping and feeling too ill) to spend some time planning and writing the second edition of the "The Definitive Guide..".
I'm co-authoring with Scott Davis, so the book should be bigger badder and more impressive this time. Target release date is the end of the year. Lets hope the codene doesn't make my ramblings to incoherent!
Luckily, the awesome Guillaume Laforge delivered my talks on Groovy and Grails instead of me, but sorry to those who were expecting to see me there, health comes first in this case.
It seems to have been another successful conference from what I could infer from the twitter feed and various blog postings. Was nice to hear Groovy in Action was 3rd and The Definitive Guide to Grails 6th of the best seller list after day 1.
On that topic of the books, being bed bound for a couple of weeks has given me the chance (when I'm not sleeping and feeling too ill) to spend some time planning and writing the second edition of the "The Definitive Guide..".
I'm co-authoring with Scott Davis, so the book should be bigger badder and more impressive this time. Target release date is the end of the year. Lets hope the codene doesn't make my ramblings to incoherent!
Thursday, May 01, 2008
Spring Application Platform and Grails
For those of you interested, Grails applications deploy and execute on SpringSource's new Application Platform without any issues. I have updated the Grails deployment page to that effect.
Saturday, April 26, 2008
Grails wins second prize at JAX awards
Great to hear that Grails won second prize at the JAX innovation awards, Guillaume was there to accept the award as I was away on annual leave in Thailand.
Would have been nice to win first prize, but since Groovy won last year I guess that would be too much to expect :-)
There is a remarkable amount of innovation going on within the Grails community itself, just in the past week or so we've had new releases of the Selenium plug-in, the JSecurity plug-in, a JAWR plug-in, an OpenID plug-in and the new simple Authentication Plug-in.
All contributed by our awesome user community. Amazing.
Would have been nice to win first prize, but since Groovy won last year I guess that would be too much to expect :-)
There is a remarkable amount of innovation going on within the Grails community itself, just in the past week or so we've had new releases of the Selenium plug-in, the JSecurity plug-in, a JAWR plug-in, an OpenID plug-in and the new simple Authentication Plug-in.
All contributed by our awesome user community. Amazing.
Friday, April 25, 2008
Choosing an OSS License and the Ext-JS saga
The news that Ext-JS has, from one release to the next, changed from a modified LGPL to a GPL based license nearly made me fall off my chair. There have been many poor judged, and ill advised decisions made by software companies over the last few years, but this has got to be up there with the stupidist I've seen and I'm not even personally an Ext-JS user.
What they have effectively done is built up a community, taking full advantage of the open source model by accepting user contributions and patches and then turned around and kicked their own community up the backside. It is projects like Ext-JS that give open source a bad name. How can a company have faith in open source if the people behind it can't even decide how to license the thing?
When you start off in the software business you have to very early on decide whether you are an open source company or whether you are a commercial software company. If you choose the former then you need to choose an appropriate license. For platforms the GPL license can make a lot of sense (think Linux and Java) to prevent forks, force contributions etc. although I'm still not a big fan of it.
On the otherhand for libraries or frameworks only a few licenses make sense (Apache 2.0, MIT, BSD and to a lesser extent LGPL). With Grails we went for Apache 2.0 as one of the most liberal licenses out there. Once you've decided on the license as an open source company your job is the grow the community by attracting users who put faith in your product and the fact that its licensed in a liberal way. Those users would not come in the first place if you had a restrictive license.
By choosing the open source route you have made a decision as a company to promote the community driven approach. Of course this doesn't stop you from releasing a commercial version, you could dual license it as Ext-JS have done for those who want the comfortable feeling of paying for something. You cannot however, have it both ways you are either an open source company or you are not. Ext-JS seem to be stuck in 2 minds as to whether they really are an open source company, it is this indecisiveness that is going to see their community go elsewhere.
It is not like they're unique either, the Ajax framework space is super competitive and they've just dropped the ball and given their competitors a big advantage. My personally prediction on this one is that they'll lose a lot of users, probably to Yahoo UI and jQuery UI or possibly Dojo. Something else will soon come along to fill their space and soon they will have lost their competitive advantage, their users and all those license renewals.
What they have effectively done is built up a community, taking full advantage of the open source model by accepting user contributions and patches and then turned around and kicked their own community up the backside. It is projects like Ext-JS that give open source a bad name. How can a company have faith in open source if the people behind it can't even decide how to license the thing?
When you start off in the software business you have to very early on decide whether you are an open source company or whether you are a commercial software company. If you choose the former then you need to choose an appropriate license. For platforms the GPL license can make a lot of sense (think Linux and Java) to prevent forks, force contributions etc. although I'm still not a big fan of it.
On the otherhand for libraries or frameworks only a few licenses make sense (Apache 2.0, MIT, BSD and to a lesser extent LGPL). With Grails we went for Apache 2.0 as one of the most liberal licenses out there. Once you've decided on the license as an open source company your job is the grow the community by attracting users who put faith in your product and the fact that its licensed in a liberal way. Those users would not come in the first place if you had a restrictive license.
By choosing the open source route you have made a decision as a company to promote the community driven approach. Of course this doesn't stop you from releasing a commercial version, you could dual license it as Ext-JS have done for those who want the comfortable feeling of paying for something. You cannot however, have it both ways you are either an open source company or you are not. Ext-JS seem to be stuck in 2 minds as to whether they really are an open source company, it is this indecisiveness that is going to see their community go elsewhere.
It is not like they're unique either, the Ajax framework space is super competitive and they've just dropped the ball and given their competitors a big advantage. My personally prediction on this one is that they'll lose a lot of users, probably to Yahoo UI and jQuery UI or possibly Dojo. Something else will soon come along to fill their space and soon they will have lost their competitive advantage, their users and all those license renewals.
Thursday, March 13, 2008
Large commercial Grails site goes live
Sky (commercially known as BSkyB), who are the biggest satellite broadcaster in the UK and largely owned by News Corporation (Rupert Murdoch et al), have re-launched their Sky showbiz news portal, powered by Grails.
The site was put together by energizedwork, a consulting firm in the UK, well done guys!
This represents one of the largest, commercial public facing Grails applications (that we at G2One Inc are able to talk about at least ;-) out there at the moment with traffic in the region of 186 million page views a month. Its great to see so many huge companies taking the leap to Grails, long may it continue!
The site was put together by energizedwork, a consulting firm in the UK, well done guys!
This represents one of the largest, commercial public facing Grails applications (that we at G2One Inc are able to talk about at least ;-) out there at the moment with traffic in the region of 186 million page views a month. Its great to see so many huge companies taking the leap to Grails, long may it continue!
Grails at JavaOne & CommunityOne 08
This year, along with Guillaume, I will be presenting 2 talks at JavaOne 08 on Groovy and Grails:
As well as a single talk at Monday's CommunityOne 08 event:
See you there!
- TS-5764 - Grails in Depth
- TS-5793 - Groovy and Grails: Changing the
Landscape of Java™ Platform, Enterprise Edition (Java EE Platform)
Patterns
As well as a single talk at Monday's CommunityOne 08 event:
See you there!
Wednesday, March 12, 2008
Tuesday, March 11, 2008
Groovy is Java AND Groovy is not Java
There is a new dynamic language shootout featured on InfoQ where Groovy comes out on top as the JVM language of choice for a variety of reasons and one of the reasons cited was that it is a near superset of Java. Queue the comments from the Ola Bini brigade that:
"If you're going to use Groovy the same way you use Java, there is absolutely no gain. Just a performance hit."
However, this sadly is missing the point. Sure, if you write Groovy like Java you get no real benefit, but it provides that migration and, crucially, learning path onto a Groovier way.
Learning a programming language is for the most part trivial and can be achieved in a few days. Learning the libraries is what takes the time. Groovy shares the same Java APIs as standard Java, you know things that you know and love like java.io.File, java.lang.String etc.?
The real difference comes in what it adds to these standard libraries through the GDK. For example great stuff like this:
myFile.eachLine { println it }
def contents = new URL("http://google.com").text
def list = ['a','c','b']
list = list.collect { it.toUpperCase() }.sort()
def text = "Hello World"
text = text - "World"
println text // prints "Hello "
println text[0..-3] // prints "Hell"
Once you learn the "new way" combined with meta-programming capabilities that Groovy has on offer you'll never look back.
Scott Davis came up with a great quote to describe this at the recent 2GX: Groovy/Grails Experience:
"Groovy is Java AND Groovy is not Java at the same time"
In other words, you get the best of both worlds.
"If you're going to use Groovy the same way you use Java, there is absolutely no gain. Just a performance hit."
However, this sadly is missing the point. Sure, if you write Groovy like Java you get no real benefit, but it provides that migration and, crucially, learning path onto a Groovier way.
Learning a programming language is for the most part trivial and can be achieved in a few days. Learning the libraries is what takes the time. Groovy shares the same Java APIs as standard Java, you know things that you know and love like java.io.File, java.lang.String etc.?
The real difference comes in what it adds to these standard libraries through the GDK. For example great stuff like this:
myFile.eachLine { println it }
def contents = new URL("http://google.com").text
def list = ['a','c','b']
list = list.collect { it.toUpperCase() }.sort()
def text = "Hello World"
text = text - "World"
println text // prints "Hello "
println text[0..-3] // prints "Hell"
Once you learn the "new way" combined with meta-programming capabilities that Groovy has on offer you'll never look back.
Scott Davis came up with a great quote to describe this at the recent 2GX: Groovy/Grails Experience:
"Groovy is Java AND Groovy is not Java at the same time"
In other words, you get the best of both worlds.
Thursday, March 06, 2008
The Grails Podcast Returns
Sven is back with his Grails podcast, now a fortnightly event, and even better Glen Smith, the brilliant ozzie behind Gravl and Groovyblogs (2 great Grails sample applications), has joined him!
Check it out.
Check it out.
Wednesday, March 05, 2008
Using Grails with Atlassian Crowd
The Atlassian guys (creators of JIRA, Confluence etc.) are using Grails for some of their projects and have written a nice article on how to setup Grails, with the Acegi plugin, and Atlassian's single sign-on (SSO) solution Crowd. Nice work.
Monday, February 25, 2008
2GX: Groovy/Grails featured on eWeek
The nice chaps at eWeek turned up at the 2GX:Groovy/Grails Experience and interviewed me and Scott from aboutGroovy on the subject of Groovy and Grails and its relationship to Java. Check it out
2GX: Standalone Spring BeanBuilder from Grails
At 2GX - The Groovy/Grails Experience, I did a presentation on empowering Spring with Groovy DSLs which demonstrated Grails' Spring BeanBuilder in action.
The demo showed how Spring and Hibernate can be dynamically configured at runtime using BeanBuilder and then interacted with via the Groovy shell. I promised a few I would make it available so here it is.
You'll need Groovy 1.5 and Gant setup before you start then just type:
gant start
Enjoy.
The demo showed how Spring and Hibernate can be dynamically configured at runtime using BeanBuilder and then interacted with via the Groovy shell. I promised a few I would make it available so here it is.
You'll need Groovy 1.5 and Gant setup before you start then just type:
gant start
Enjoy.
2GX: Keynote - The Amazing Growth of Grails
So, I'm back from the 2GX - The Groovy/Grails Experience which was yet another event, brilliantly put together by Jay Zimmerman and the No Fluff crew. The good news is, if you missed out there is another one in the fall/autumn months in San Jose, CA.
The attendance was excellent for such a focused conference with close to 200 people in total all buzzing about Groovy & Grails. I delivered my "State of Grails" keynote on the Thursday evening which went into some analysis of where we are since the release of Grails 1.0 from a growth perspective, but also from a technology perspective.
I wasn't planning to, but a few people at the conference asked me to post my slides to help persuade managers etc. of the viability of Grails, not just from a technical perspective, but from a growth and community perspective. So if you're in the same position, check out my slides, the following is a summary of the contents.
When we released Grails 1.0, Codehaus' bandwith usage went up by a staggering 40gb. The downloads have been in the 10s of thousands since the release and luckily Contegix, the kind folks who host Codehaus, have freed up some extra bandwith for the servers.
The mailing list traffic on the Grails user mailing list has gone through the roof, averaging close to 140 messages a day in January and looking the same for Feb:
The traffic is contributing to make Grails one of the most vibrant communities around anyone one Java web framework according to Nabble:
Further evidence of the growing community is the Grails plug-in eco-system where Grails now has no less than 47 user contributed plug-ins in the plug-in repository representing nearly 2 million lines of user contributed code:
Blog traffic is also on the up, a year ago the blog traffic for Grails was merely a blip on the horizon (all probably posted by me ;-). Now according to technorati people are talking about Grails, a lot:
Clearly, we still have a long way to go to make Grails as hugely popular as things like Spring and Hibernate, but we're heading in the right direction which is great news.
The attendance was excellent for such a focused conference with close to 200 people in total all buzzing about Groovy & Grails. I delivered my "State of Grails" keynote on the Thursday evening which went into some analysis of where we are since the release of Grails 1.0 from a growth perspective, but also from a technology perspective.
I wasn't planning to, but a few people at the conference asked me to post my slides to help persuade managers etc. of the viability of Grails, not just from a technical perspective, but from a growth and community perspective. So if you're in the same position, check out my slides, the following is a summary of the contents.
When we released Grails 1.0, Codehaus' bandwith usage went up by a staggering 40gb. The downloads have been in the 10s of thousands since the release and luckily Contegix, the kind folks who host Codehaus, have freed up some extra bandwith for the servers.
The mailing list traffic on the Grails user mailing list has gone through the roof, averaging close to 140 messages a day in January and looking the same for Feb:
The traffic is contributing to make Grails one of the most vibrant communities around anyone one Java web framework according to Nabble:
Further evidence of the growing community is the Grails plug-in eco-system where Grails now has no less than 47 user contributed plug-ins in the plug-in repository representing nearly 2 million lines of user contributed code:
Blog traffic is also on the up, a year ago the blog traffic for Grails was merely a blip on the horizon (all probably posted by me ;-). Now according to technorati people are talking about Grails, a lot:
Clearly, we still have a long way to go to make Grails as hugely popular as things like Spring and Hibernate, but we're heading in the right direction which is great news.
Tuesday, February 12, 2008
See you at the Groovy/Grails Experience
Last time there was a major Groovy/Grails conference, we promised to get Grails 1.0 out in time for the conference, somehow we slipped a few months ;-)
This time there is no such slippage and the 2G - Groovy/Grails Experience is coming to Reston, Virginia on the 21-23 of Feb! Organised by the No Fluff crowd, it features an amazing amount of great Groovy & Grails talks from some great speakers (other than me of course ;-).
I'll be doing 3 talks on various aspects of Grails and can't wait, its going to be a great event. See you there!
This time there is no such slippage and the 2G - Groovy/Grails Experience is coming to Reston, Virginia on the 21-23 of Feb! Organised by the No Fluff crowd, it features an amazing amount of great Groovy & Grails talks from some great speakers (other than me of course ;-).
I'll be doing 3 talks on various aspects of Grails and can't wait, its going to be a great event. See you there!
Tuesday, February 05, 2008
Grails 1.0 is out the door!
We've put the finishing touches on Grails 1.0 and its out. Time to celebrate with some sleep.. enjoy!
Friday, January 18, 2008
RE: Groovy and JRuby: Enterprise-Ready?
There is a report that is being pushed around comments on blog posts with the aim of spreading FUD. The report can be found here:
http://www.huxili.com/index.php?cat=reports&id=ID000188
It is entitled "Groovy and JRuby: Enterprise Ready?" and its conclusion is that Groovy is not due to "memory leaks". The report is complete nonsense of course, and it put together by someone who doesn't understand the different language idioms.
The report provides no code examples, further bringing to question its validity, however it states that Groovy runs out of memory when running these steps:
shell = new GroovyShell()
while(true) {
shell.evaluate("x = 100")
sleep(2000)
System.gc()
}
So what is the problem with this code? And why would it result in a memory leak? The answer is that each GroovyShell instance has an internal class loader. Groovy is a compiled language. Even little scripts like this are compiled into classes so over time the class loader just gets bigger and bigger. The solution? Here we go:
while(true) {
new GroovyShell().evaluate("x = 100")
sleep(2000)
}
So what this does is allow the GroovyShell (and its class loader) to be garbage collected by the JVM. When the class loader is garbage collected so are the classes loaded within it. JRuby of course doesn't have this problem as its interpreted.
Judging whether a language is "enterprise-ready" without knowing the language idioms and basing it on a 4 line script is to be honest quite ridiculous, so remember beware of silly "official" looking reports without verifying the facts for yourself.
http://www.huxili.com/index.php?cat=reports&id=ID000188
It is entitled "Groovy and JRuby: Enterprise Ready?" and its conclusion is that Groovy is not due to "memory leaks". The report is complete nonsense of course, and it put together by someone who doesn't understand the different language idioms.
The report provides no code examples, further bringing to question its validity, however it states that Groovy runs out of memory when running these steps:
Call shell.evaluate("x = 100")
Call System.gc()
Thread.sleep(1000)
Record used memory
Repeating (1-4)
shell = new GroovyShell()
while(true) {
shell.evaluate("x = 100")
sleep(2000)
System.gc()
}
So what is the problem with this code? And why would it result in a memory leak? The answer is that each GroovyShell instance has an internal class loader. Groovy is a compiled language. Even little scripts like this are compiled into classes so over time the class loader just gets bigger and bigger. The solution? Here we go:
while(true) {
new GroovyShell().evaluate("x = 100")
sleep(2000)
}
So what this does is allow the GroovyShell (and its class loader) to be garbage collected by the JVM. When the class loader is garbage collected so are the classes loaded within it. JRuby of course doesn't have this problem as its interpreted.
Judging whether a language is "enterprise-ready" without knowing the language idioms and basing it on a 4 line script is to be honest quite ridiculous, so remember beware of silly "official" looking reports without verifying the facts for yourself.
The Great Language Backlash
Something interesting has been happening in the blogosphere over the last few days. It seemed to all kick-off with Rick Hightowers post on Why Syntax Matters. It seems a mini-backlash is brewing against the Ruby hype.
Rick feels (and this is his opinion) that Sun should ditch JRuby and support Groovy because the syntax and migration path is so much easier for Java developers. He and several commenters on his blog, feel that Ruby is too different to Java. The post was features on JavaLobby and InfoQ.
This is of course the main reason I was sold about Groovy as it eliminates the context switching between languages as they are so similar, but a blog post that got me thinking the most was Cedric's entitled I'm not Tired of Java Yet. And you know what? I agree with him.
Unlike Ola Bini (JRuby committer) who is repeatedly questioning Java, I love Java and still believe it is a great language for many common tasks. Its just not great for everything. In the past Java was seen as "the one language to rule them all". Now as alternative languages like Groovy start to mature, its about picking the right language to solve the problem at hand and that tool is often Java.
Things like processing strings, doing really dynamic stuff and heavy manipulating of collections can get painful in Java. However, its death is highly, highly exaggerated. One of the reasons I believe so strongly in Groovy and Grails is that it is not about ditching Java or the Java platform, it's about embracing it.
Groovy supports true polygot programming when combined with Java thanks to the seamless way they integrate with one another. I, and most Groovy programmers, still love programming in Java and have no plans to ditch it anytime soon. Use each language when it makes sense. It is about using the best tool for the job.
Rick feels (and this is his opinion) that Sun should ditch JRuby and support Groovy because the syntax and migration path is so much easier for Java developers. He and several commenters on his blog, feel that Ruby is too different to Java. The post was features on JavaLobby and InfoQ.
This is of course the main reason I was sold about Groovy as it eliminates the context switching between languages as they are so similar, but a blog post that got me thinking the most was Cedric's entitled I'm not Tired of Java Yet. And you know what? I agree with him.
Unlike Ola Bini (JRuby committer) who is repeatedly questioning Java, I love Java and still believe it is a great language for many common tasks. Its just not great for everything. In the past Java was seen as "the one language to rule them all". Now as alternative languages like Groovy start to mature, its about picking the right language to solve the problem at hand and that tool is often Java.
Things like processing strings, doing really dynamic stuff and heavy manipulating of collections can get painful in Java. However, its death is highly, highly exaggerated. One of the reasons I believe so strongly in Groovy and Grails is that it is not about ditching Java or the Java platform, it's about embracing it.
Groovy supports true polygot programming when combined with Java thanks to the seamless way they integrate with one another. I, and most Groovy programmers, still love programming in Java and have no plans to ditch it anytime soon. Use each language when it makes sense. It is about using the best tool for the job.
Wednesday, January 16, 2008
Why Grails doesn't use Maven
Update: As of Grails 1.1, Grails now provides Maven support. My personal feelings towards Maven haven't changed much, it is in my view basically the EJB2 of build tools. However, if you want to use Maven with Grails that is now a possiblity.
In his post entitled "Grails - The Good, The Bad and the Ugly", Jonas has some nice praise for Grails, his main beef is that it is not built on Maven.
So I wanted to clarify why exactly we chose not use Maven (by default) and the explanation is there for all to see in Jonas' first example of creating a Grails application vs creating a Maven project:
Instead of
could be just
For me Grails is all about dramatically simplifying, and reducing the cases where you have to RTFM. Grails wraps popular Java libraries like Spring, Hibernate, Sitemesh and Quartz and does a damn good job of hiding that complexity.
I'm not saying you never have to RTFM manual, but once you have learnt Grails the cases where you need to are few and far between and for simple things like creating an application, once you know how, you never need to go back. In other words Grails is all about simplifying Java EE.
Now Maven is the complete opposite of this. Why do I have to go and read their manual everytime I want to creating a project. I mean there is no way I will remember all that crap and their documentation is pretty appauling to begin with.
I think only Java people would be willing to accept a build system like Maven with all its complexities. Any other community would be like "what the hell is this?". For me Maven is the EJB2 of build systems: over complicated, over engineered and requiring an intelligent, code generating IDE just to work with it.
Having said all of that there are a good number of companies adopting Maven (god help them) and so I am not against having Maven support in Grails, but not by default. Arnaud from Octo has put together the excellent Maven Tools for Grails project, which allows you to create a POM for a Grails application and integrates Grails with the Maven lifecycle. Maybe one day we will include it in Grails core by default as an optional extra if Arnaud is interested in that.
However, I feel there is no use putting Maven in by default, because I strongly believe that in the long term it will be replaced by better tools like Gant, Raven, or Buildr.
In his post entitled "Grails - The Good, The Bad and the Ugly", Jonas has some nice praise for Grails, his main beef is that it is not built on Maven.
So I wanted to clarify why exactly we chose not use Maven (by default) and the explanation is there for all to see in Jonas' first example of creating a Grails application vs creating a Maven project:
Instead of
grails create-app name
could be just
mvn archetype:create -U \
-DarchetypeGroupId=net.liftweb \
-DarchetypeArtifactId=lift-archetype-blank \
-DarchetypeVersion=0.4 \
-DremoteRepositories=http://scala-tools.org/repo-releases \
-DgroupId=your.proj.gid -DartifactId=your-proj-id
For me Grails is all about dramatically simplifying, and reducing the cases where you have to RTFM. Grails wraps popular Java libraries like Spring, Hibernate, Sitemesh and Quartz and does a damn good job of hiding that complexity.
I'm not saying you never have to RTFM manual, but once you have learnt Grails the cases where you need to are few and far between and for simple things like creating an application, once you know how, you never need to go back. In other words Grails is all about simplifying Java EE.
Now Maven is the complete opposite of this. Why do I have to go and read their manual everytime I want to creating a project. I mean there is no way I will remember all that crap and their documentation is pretty appauling to begin with.
I think only Java people would be willing to accept a build system like Maven with all its complexities. Any other community would be like "what the hell is this?". For me Maven is the EJB2 of build systems: over complicated, over engineered and requiring an intelligent, code generating IDE just to work with it.
Having said all of that there are a good number of companies adopting Maven (god help them) and so I am not against having Maven support in Grails, but not by default. Arnaud from Octo has put together the excellent Maven Tools for Grails project, which allows you to create a POM for a Grails application and integrates Grails with the Maven lifecycle. Maybe one day we will include it in Grails core by default as an optional extra if Arnaud is interested in that.
However, I feel there is no use putting Maven in by default, because I strongly believe that in the long term it will be replaced by better tools like Gant, Raven, or Buildr.
Monday, January 14, 2008
Relevance on Grails vs Rails Architecture
Oh I love these back and forth posts, as a follow-up to their original thoughts on my last post, Relevance have put up one called "How to pick a platform". Unsurprising, they choose Rails over Grails for the case where there is no legacy "baggage".
Since they're a Rails company (althouth this may change given they've hired 2 guys from the Groovy/Grails community ;-) this isn't really surprising. The conclusions are that Rails' architecture is better because:
Stu's, second point is somewhat confusing and contradictory. He link's off to this post by Ola Bini where Ola says and I quote:
"The first layer is what I called the stable layer. It's not a very large part of the application in terms of functionality. But it's the part that everything else builds on top off, and is as such a very important part of it. This layer is the layer where static type safety will really help. Currently, Java is really the only choice for this layer. More about that later, though."
Later Ola goes on to say that Java is no good for the stable layer either and that another statically typed language like Scala would be better, but at no point does he say that a dynamically typed language is good for the stable layer.
Since Rails is 100% Ruby and, according to Ola Bini (JRuby committer) its not a good idea to build "the stable layer" in a dynamically typed language (Ruby) who has the better architecture?
Grails where the stable layer is built on powerful, stable and performant Spring or Rails where the stable layer is in Ruby, which is dog slow and problematic. I'll let you decide.
Personally, I don't buy into Ola's problems with Java for this so called stable layer nor do I believe that a dynamic language can't be used, at least in part, in the stable layer, because 25% of Grails' "stable" layer is written in Groovy. However, what I will say is Relevances' 2 conclusions are complete nonsense and fall into the "Crap" category of their original post.
What I advise anyone trying to make this decisions is download and try out both frameworks and use what suits you and your company. Every business is unique and not every framework is suitable for every business need. Don't buy into nonsense from either Stu or I that ones architecture is better than the other without comparing how it fits into your own existing architecture.
Since they're a Rails company (althouth this may change given they've hired 2 guys from the Groovy/Grails community ;-) this isn't really surprising. The conclusions are that Rails' architecture is better because:
- Ruby is a better language than Groovy.
- Spring does most of its heavy lifting in the stable layer, which is not the right place.
Stu's, second point is somewhat confusing and contradictory. He link's off to this post by Ola Bini where Ola says and I quote:
"The first layer is what I called the stable layer. It's not a very large part of the application in terms of functionality. But it's the part that everything else builds on top off, and is as such a very important part of it. This layer is the layer where static type safety will really help. Currently, Java is really the only choice for this layer. More about that later, though."
Later Ola goes on to say that Java is no good for the stable layer either and that another statically typed language like Scala would be better, but at no point does he say that a dynamically typed language is good for the stable layer.
Since Rails is 100% Ruby and, according to Ola Bini (JRuby committer) its not a good idea to build "the stable layer" in a dynamically typed language (Ruby) who has the better architecture?
Grails where the stable layer is built on powerful, stable and performant Spring or Rails where the stable layer is in Ruby, which is dog slow and problematic. I'll let you decide.
Personally, I don't buy into Ola's problems with Java for this so called stable layer nor do I believe that a dynamic language can't be used, at least in part, in the stable layer, because 25% of Grails' "stable" layer is written in Groovy. However, what I will say is Relevances' 2 conclusions are complete nonsense and fall into the "Crap" category of their original post.
What I advise anyone trying to make this decisions is download and try out both frameworks and use what suits you and your company. Every business is unique and not every framework is suitable for every business need. Don't buy into nonsense from either Stu or I that ones architecture is better than the other without comparing how it fits into your own existing architecture.
Thursday, January 10, 2008
Grails Making Java Developers Forget about Rails
In 10 reasons to switch from Rails to Grails
Here is another 10:
1. A view technology that doesn't suck
2. Mixed source development made easy with the Groovy joint compiler (no falling back to C to solve those performance problems ;-)
3. Built in support for rich conversations with Web Flow
4. Grails 1.0 coming out within the month
5. IntelliJ's JetGroovy Plug-in
6. A rich plug-in system that integrates Grails with technologies Java people care about like GWT, DWR, JMS etc.
7. A buzzing and growing community with a larger traffic mailing list as opposed to a stagnating one
8. Built on Spring, the ultimate Enterprise Application Integration technology
9. A Service layer with automatic transaction demarcation and support for scopes
10. More books coming and being adopted by enterprise organisations near you
Update:
The Relevance guys have chipped in! They've gone ahead and neatly organised my points, good job. Let's deal with the ones under the "Crap" section:
Grails 1.0 coming out -
Ok fair point not a reason to choose Rails over Grails, unless stable release numbers is an issue for you
Built on Spring -
To put this one under crap sadly misses the point by a million miles. Rails has zero enterprise penetration, let's put that out there right now. Grails on the other hand has enterprise penetration and is only growing. A large part of this is the Spring toolkit which solves more enteprise problems than you can shake a stick at.
The comments on the Relevance blog back this up. Rails' attitude of openly shirking the enterprise has left a big gaping whole that Grails is happily filling. And finally for a Rails guy to call Spring a leaky abstraction is a little rich.
A Buzzing and Growing Community -
I'm not arguing that Rails has a smaller community, merely that it has plateaud, whilst Grails has no where near reached that point and has the potential to go much much further. Watch this space.
More books coming -
See above, even though I don't regard Grails as second best now for those that think that we won't be second best for long trust me ;-)
Here is another 10:
1. A view technology that doesn't suck
2. Mixed source development made easy with the Groovy joint compiler (no falling back to C to solve those performance problems ;-)
3. Built in support for rich conversations with Web Flow
4. Grails 1.0 coming out within the month
5. IntelliJ's JetGroovy Plug-in
6. A rich plug-in system that integrates Grails with technologies Java people care about like GWT, DWR, JMS etc.
7. A buzzing and growing community with a larger traffic mailing list as opposed to a stagnating one
8. Built on Spring, the ultimate Enterprise Application Integration technology
9. A Service layer with automatic transaction demarcation and support for scopes
10. More books coming and being adopted by enterprise organisations near you
Update:
The Relevance guys have chipped in! They've gone ahead and neatly organised my points, good job. Let's deal with the ones under the "Crap" section:
Grails 1.0 coming out -
Ok fair point not a reason to choose Rails over Grails, unless stable release numbers is an issue for you
Built on Spring -
To put this one under crap sadly misses the point by a million miles. Rails has zero enterprise penetration, let's put that out there right now. Grails on the other hand has enterprise penetration and is only growing. A large part of this is the Spring toolkit which solves more enteprise problems than you can shake a stick at.
The comments on the Relevance blog back this up. Rails' attitude of openly shirking the enterprise has left a big gaping whole that Grails is happily filling. And finally for a Rails guy to call Spring a leaky abstraction is a little rich.
A Buzzing and Growing Community -
I'm not arguing that Rails has a smaller community, merely that it has plateaud, whilst Grails has no where near reached that point and has the potential to go much much further. Watch this space.
More books coming -
See above, even though I don't regard Grails as second best now for those that think that we won't be second best for long trust me ;-)
Tuesday, January 08, 2008
Groovy & Grails Happenings in the New Year
First let me say happy new year to all readers. I myself have just got back into the swing of things after spending some family time over in Spain.
It is nice to get back and see that even though with the holiday period the good stuff coming out of the Groovy and Grails community doesn't stop.
First up we have the announcement from the Pragmatic (almost mistyped that Programmatic!) Programmers that, shock/horror, they don't just do Ruby books, but have announced 2 new Groovy books: Groovy Recipes by Scott Davis and Programming Groovy by Venkat - thee of the unpronounceable surname ;-)
Next, for those of you who haven't been following Glen Smith's exploits in producing his Grails based blog called Gravl, checkout the latest screencast its looking really awesome. In the spirit of consuming ones own dog food, once he has done I may well migrate to Gravl!
Finally, the Grails user community continues to be busy with new plug-in releases and so on. The most significant of which is James' (who has also built his on Grails based blog) Google Chart API plug-in which looks really nice and Andreas' RichUI plug-in which adds a whole bunch of new tags to create rich components like tabbed panes, tag clouds, tree widgets to name just a few. Most of the components seem to take advantage of the Yahoo UI JavaScript library. Neat stuff.
As for the Grails 1.0 release we were supposed to ship that by the end of the year, but with the Groovy release coming a bit later and our aims to deliver a really high quality to release we decided to push it back a bit. The target is this month sometime so stay tuned.
It is nice to get back and see that even though with the holiday period the good stuff coming out of the Groovy and Grails community doesn't stop.
First up we have the announcement from the Pragmatic (almost mistyped that Programmatic!) Programmers that, shock/horror, they don't just do Ruby books, but have announced 2 new Groovy books: Groovy Recipes by Scott Davis and Programming Groovy by Venkat - thee of the unpronounceable surname ;-)
Next, for those of you who haven't been following Glen Smith's exploits in producing his Grails based blog called Gravl, checkout the latest screencast its looking really awesome. In the spirit of consuming ones own dog food, once he has done I may well migrate to Gravl!
Finally, the Grails user community continues to be busy with new plug-in releases and so on. The most significant of which is James' (who has also built his on Grails based blog) Google Chart API plug-in which looks really nice and Andreas' RichUI plug-in which adds a whole bunch of new tags to create rich components like tabbed panes, tag clouds, tree widgets to name just a few. Most of the components seem to take advantage of the Yahoo UI JavaScript library. Neat stuff.
As for the Grails 1.0 release we were supposed to ship that by the end of the year, but with the Groovy release coming a bit later and our aims to deliver a really high quality to release we decided to push it back a bit. The target is this month sometime so stay tuned.
Subscribe to:
Posts (Atom)