Groovy On Grails足迹拾缀

 

Groovy On Grails足迹拾缀

 

10 个对于Grails的误解

通常情况下所谓“新”的东西出现总是会伴随着许许多多的流言与困惑，Grails也不例外，许多人也许会因为这个而放弃继续使用它。以下是一个简要的Grails流言列表：

“Grails只是一个Rails的拷贝罢了。”Grails确确实实引进并统一了一些Ruby On Rails不错的创意，Grails将它们中的一部分应用到了Groovy/Java世界里，但更添加了许许多多Ruby中根本不存在的新特性与新概念，而这一切所作所为对Groovy/Java程序员而言都是充满意义的。

“Grails对我来说并不成熟。”我想日益增长活跃的社区站点是对这一说法最好的驳斥了。Grails本身就封装了Hibernate、Spring和SiteMesh等几个早已扬名远播的技术框架，当然更别提那个已经熟透了的Java JDK了，还有别忘了，Groovy已经三岁了。

“Grails使用了一种解释型语言（Groovy）。”Groovy是在运行阶段被Java虚拟机编译成字节码的，它绝对不是解释执行的——从来都不是，并且以后永远也决不会是。我说了“永远”吗？是的，毫无疑问！

“Grails需要它特有的运行环境。”不！你只需要使用“grails war”命令将应用打包成一个WAR文件，并将其部署到你最喜欢的应用程序容器中即可。当然，在开发的过程你大可使用Grails绑定的Jetty容器，这样完全可以做到开发的零配置与无需容器重启的动态载入功能。

“我的经理是不会让我用Grails的，因为它不是Java。”你真该敲他脑袋几下（注）！Grails源码是由大约85%的Java语言完成的，它运行于Java虚拟机上，部署在你的servlet容器里。Groovy实为一个Java强大的扩充，并在开发效率上比Java强出几倍。你当然也可以写一些简单的Java类并将其对象持久化在数据库里，也可以像在Java中一样将源文件或JAR包引入应用程序，例如EJB、Spring bean等等。一般说来一种新的技术总会因为其代码生涩性而难以推销出售，但无论什么也无法比“嘿，我刚趁午餐时间花了一个小时搞定发布了我们的新应用——喏，这是网址。”这样一个有趣的场景更有说服力了。（注：看起来我是有些过于喜形于色和小孩子气了，其实我不是这样的。）

“Grails只适用于常规的增删改应用程序。”有很多注重于Grails增删改的应用脚手架的例子，但那些只能体现这一小部分功能而已。Grails是适用于各种方向web应用的框架。

“脚手架功能需要我在每次改变后生成。”“脚手架”即是可以自动生成控制器和视图之增删改代码的样板控制器。对控制器和视图的显式重建通常毫无必要，除非你不愿应用动态脚手架的功能。“def scaffold = Classname”就可以是你所需要的全部，它可以变戏法般地创建其它一切东西并在开发模式中自动重载。接下去，当然，如果你愿意的话，你可以生成个性化的控制器和视图代码。

“Grails和其它框架一样，最终总有局限性。”所有的Grails应用程序都有一个Spring bean上下文，你可以自由添加任意Java bean进去，并在你的应用程序中访问它们。Grails有一个精巧的插件架构，用户标签库可以轻而易举地由JSP标签库导入并改变而来。

“我没法找到Grails程序员。”任何一个Java开发者都可以很容易发展成一个Grails人员。开发Grails应用使用比标准Java少得多得多代码，让他们有更多时间休息吧，从此程序员清早起床的速度将会大大加快了。

“Grails会令你在女性中更受欢迎。”很抱歉，事实是截然相反的。你会更加热衷于编码而不再乐于时不时地去拈花惹草。是的，我们将把许多类似的忠告写入读我文件中，当然除了一个由于连续数小时泡在Grails里而导致离婚的潜在可能的案例。

为什么不来听听其他用户对于免FUD编程和双倍的web应用开发速度的谈论呢，Grails2007交流大会即将开始，门票正火热销售中。

[ 来自：

http://www.anyware.co.uk/2005/2007/07/02/10-common-misconceptions-about-grails/]

 

Groovy On Rails 这一名字并不被 Ruby On Rails 的创建者所认可

今天 Graeme Rocher —— Grails 项目的带头人，收到了一封来自 David Heinemeier Hansson —— Ruby On Rails 项目带头人的邮件，邮件中他对 Grails 第一版的发布表示祝贺，但也希望我们不要使用 Groovy On Rails 这个名字。

我们团队一致决定不再用 Groovy On Rails 这个名字了，但我对于这个请求依然抱有相当的疑问。我认为这个请求有些过分，特别在 Ruby On Rails 这个名字并未注册商标专利的情况下。我完全可以理解 Ruby On Rails 的支持者们想要保护他们的商标，但他们应该选择一种合法手段，而不是主动疏远别人。

再次申明，以上是我们团队的意见，也是我的意见。我们与 Ruby On Rails 社区依旧保持良好的交流关系，即便是在今天这样看起来有些气焰盛起的时候。我们将公布 Grails 邮件发送清单并通知大家官方名字的变更。

[ 来自： http://www.jroller.com/sdevijver/]

 

棒极了！ Grails1.0 发布

2008 年 2 月 5 日

现在你登陆 Grails 网站的话你就可以下载到 Grails1.0 版本了，它是目前可获得的最好的版本，而且，正如你看到的那样，它已经率先在 Codehaus 服务器上应用了！ Codehaus 程序员们只用了很少的时间就让整个系统流畅运转起来，显然它在服务器上的负载表现很优异。

大多数人心理上能够理解 1.0 版本发布的重要性，它设定了一个东西的对未来发展进步的基准和起点。 Grails 1.0 版本拥有难以置信的极其丰富的核心特色，并且有一组正在日益壮大的开源插件来不断增强功能。

现在 Grails 1.0 有一个强大的 ORM DSL 来完成 Hibernate 幕后做的许多工作，包括索引生成，这里我们可以找到 Hibernate 的二级缓存。不必将自动编集功能吹嘘得多天花乱坠，但它确确实实能将 JSON/xml 请求以一种经得起讨论评估的形式将有效载荷分布到 bean 中去。

我们也将自动运行功能的网站测试框架作为一个 SVN 支持的范例放到 Grails 的持续一体化中去了。在服务器环境中确实也出现了一些初始困难，但是整个进程却在本地开展了，我们只是将一些简单的优秀测试应用加入了 SVN ，但重要的是，其中的某些网页测试脚本已经得到应用。

这将有效地形成一系列的“ TCK ”以确保 Grails 在 1.0 基础上的稳定性，此外，一组大量的 Grails 单元测试为持续整合平台的构建而稳定执行。我们要感谢这些广泛的单元网络测试所做出的不平凡的贡献。

Graeme 所做的一切让 Groovy SVN HEAD 和 Grails SVN HEAD 握起手来，不断的集成确保了 Groovy 中任何的特性变化都能到 Grails 中尽早地有所体现，除此以外，他还给了 Groovy 团队一大笔股票以支持他们去进行改变的尝试。

我们无比无比兴奋地与 Grails 新用户谈论 1.0 版发布的消息！

[ 来自： http://www.anyware.co.uk/2005/]

 

初涉 Groovy

人超越一切动物进化之根本乃源于强烈的好奇心与求知欲。

—— Alfred North Whitehead

欢迎来到 Groovy 的世界。

也许你已经在博客或邮件中听说过 Groovy 了，甚至你都已有所了解。如果你的某一位同事指出，你写的满满一页代码可以用短短几行 Groovy 语句完成，那么你翻起这本书的原因就不该仅仅是因为它上口的名字。好，到底为什么要学 Groovy 呢，你又能从中获得些什么呢？

Groovy 会让你很快就获得短期回报的，它令你将代码写得更简捷，替你自动地完成某些任务，甚至生成一些特别的脚本帮助你日常程序员式生活。当然，它也会令你获得长效的回报，它让你的代码从未有过地清晰易读，更重要的是，对它的使用一直是充满快乐的。

学习 Groovy 是一项睿智的创新工程。它带来了强有力的语言特性，比如闭包，动态载入，还有 Java 平台的元类型对象。在这一切过程中，你的 Java 技能却永不过时，因为 Groovy 正是建立在对 Java 平台的体验与熟知的基础上的。你可以选择这两套语言工具中的任一款，也可以将它们完美地契合起来。

如果你还在对 Ruby 阵营鼓吹可以在一下午时间内轻易完成一整套 web 应用的逻辑感到惊奇， Python 支持者和 Perl 迷们却早已通过敲打几个按键搞定了一套服务器集群，或者是干脆把他们一系列项目代码重写了一遍，正慢慢回味这整个过程中语言特性的使用呢。而另一方面， Groovy 创造的目的也正是为了在遵循 Java 对象模型和顺从 Java 程序员惯性思维的基础上扩展该语言的能力。

第一章将带你领略 Groovy 的背景并且为你准备一下必要的知识。而一切都是从这个 Groovy 的故事开始的：为什么要创造 Groovy ，它的设计是怎样的，它在语言大家族里面又处于怎样的地位呢？第二章将带你领略更多 Groovy 的才华，让你切切实实体会到它是可以令你的生活轻松不少的，无论你是 Java 程序员、脚本狂，还是敏捷开发者。

我们坚信，学好一门语言的必经之路是：实践。在出现一些可以被 IDE 广泛使用的插件，以及 Groovy 的最新信息发布之前，你可以用我们提供给你的一系列脚本来模拟编译、解释，界面化运行。

到这一章的最后，你就会对 Groovy 有一个基本了解，并且知道可以用它来搞什么东西了。

我们作者和评论家，包括整个编辑团队，衷心祝愿你在使用这本书学习实践 Groovy 的时候，能真正享受快乐。

在 Groovy 的处子年—— 2004 年，一群 Groovy 的开发者聚集到了伦敦， James Strachan 组织了一次中心演说，告诉了大家这个让 Groovy 诞生的创意。

就在几年前， Strachan 夫妇还习惯性地等迟来的航班。一次，当 Strachan 夫人去购物， Strachan 先生来到网上冲浪，他还是习惯性地访问了 Python 站点，并且继续尝试对 Python 的学习。在这期间，他萌发了一个想法：作为一个老练的 Java 程序员，他意识到几乎快成为他母语的 Java 实在是太缺少 Python 独具的活泼和有用的特性了，例如表达文法对普通类型的本地语言支持，还有一些动态行为。于是新想法产生了，他要为 Java 添加特性。

以上也引出了 Groovy 开发的最主要原则：特性丰富多样，与 Java 契合友好，将动态语言吸引人的优势与强支持平台的健壮性结合起来。

我们不想诋毁任何一种语言，因为每一门语言都是有其特定的适用场合和应用能力的，但我们对 Groovy 在语言家族中的发展充满信心。

也许有些语言会比 Groovy 具有更多的特性，也许有些语言能与 Java 更好地结合，但到目前为止，能将这两方面几乎完美地结合起来的，唯有 Groovy ：是的，没有一门语言可以向它那样提供与 Java 那么好的契合性却又同时具有如此多的现代语言之特性。

既然你已经知道了一些创造 Groovy 的意图，那现在就让我们来看看它具体是什么样的吧。

[ 出处：《 Groovy In Action 》 作者： Dierk Konig]

 

2GX: 概要——Grails令人讶异的增长速度

呃，我正从2GX——Groovy/Grails体验大会回来， Jay Zimmerman 和一群热心的工作人员将其办的完美无暇。还有一个好消息，如果你错过了它，那么在秋季的加拿大San Jose还将举办一届。

参加这次令人瞩目的大会的共计约两百人，都无比热闹地讨论Groovy和Grails。我将“Grails现状”作为周四晚上的主题，从Grails1.0发布以来不断发展和技术的双重角度进行了分析。

我本不打算发布幻灯片，但一些与会人士向我索取幻灯片，以便于能从不单单的从技术角度，更能谈到发展和社区的角度，去说服经理们对Grails的使用。如果你也有相同的志趣，看看我的幻灯片吧，它的大意如下：

当我们发布了Grails1.0版本，Codehaus的访问带宽总量难以置信地上涨了40GB。面对新版本发布后每10秒钟数以千计的下载量，Codehaus好心的组织者Contegix决定再为我们提供增加额外带宽的服务器。

请看Grails邮件列表统计，这已经突破了先前的记录，在一月达到平均140条每日的数量，看来在二月，这个情况也会差不多。

根据Nabble的这个统计，Grails成为了Java web框架中最醒目的社区，并做出了巨大贡献：

更有进一步的Grails插件和生态系统社区的增长迹象表明，如今，Grails插件库中已有了超过47组用户贡献的插件，其中包含二百万行代码：

博客统计也说明了用户迅速的增长，一年前Grails的博客统计还几乎为零（搞不好仅有的那几篇就是我写的，呵呵），不像现在，技术专家们会经常讨论Grails。

显而易见的，要让Grails像Spring和Hibernate一样具有巨大的普及性，还有很长的路要走，但这些好消息都无一例外地说明我们正走在正确的道路上。

[来自： http://graemerocher.blogspot.com/ ]

 

大型Grails商业应用启动

全美最大并且是新闻公司（Rupert Murdoch等）旗下的卫星广播天空（商业上称BSkyB）公司，新发布了采用Grails完成的网站。

这个站点的完成需要充满热情工作，需要坚实的商议，干得好，伙计们！

这体现了一个大型Grails商业应用（至少我们在G2One公司可以谈论这个事情了，呵呵）的成功发布，此时已经有每月约186百万页的访问量了。非常高兴看到有那么多公司转而关注和使用起Grails来，但愿这个势头能维持下去！

[来自：http://graemerocher.blogspot.com/]

原文：

A collection of specimens: Groovy on Grails

 

10 Common Misconceptions about Grails

As is usually the case with anything "new" there’s a lot of FUD and confusion out there with people who have not used Grails yet, that may be stopping them using it. Here’s a quick list of some of the more common falsehoods being bandied about:

"Grails is just a clone of Rails". Ruby On Rails introduced and unified some great ideas. Grails applies some of them to the Groovy/Java world but adds many features and concepts that don’t exist in Ruby, all in a way that makes sense to Groovy/Java programmers.

"Grails is not mature enough for me". The increasing number of live commercial sites is the best answer to that. Its also built on Hibernate, Spring and SiteMesh which are well-established technologies, not to mention the Java JDK which is as old as the hills. Groovy is over three years old.

"Grails uses an interpreted language (Groovy)". Groovy compiles to Java VM bytecode at runtime. It is never, ever, ever interpreted. Period. Never. Did I say never ever? Really.

"Grails needs its own runtime environment". Nope, you produce good old WAR files with "grails war" and deploy on your favourite app container. During development Grails uses the bundled Jetty just so you have zero configuration and dynamic reloading without container restarts.

"My manager won’t let me use Grails because it isn’t Java". Smack him/her upside the head then!** Grails code is approximately 85% Java. It runs on the Java VM. It runs in your existing servlet container. Groovy is the greatest complement to Java, and many times more productive. You can also write POJOs for persistence to databases in Java and include Java src and any JARs you like in a Grails application, including EJBs, Spring beans etc. Any new tech can be a hard sell in a cold grey institution, but there’s rarely a more convincing argument than "Hey Jim, I knocked up our new application prototype in 1hr in my lunch break with Grails - here’s the URL". [** comedy violence kids, not the real kind]

"Grails is only for CRUD applications". Many demos focus on CRUD scaffolding, but that is purely because of the instant gratification factor. Grails is an all purpose web framework.

"Scaffolding needs to be regenerated after every change". Scaffolding is what we call the automatically generated boilerplate controller and view code for CRUD operations. Explicit regeneration is never required unless you are not using dynamic scaffolding. "def scaffold = Classname" is all you need in a controller and Grails will magic everything else and handle reloads during development. You can then, if you want, generate the controller and view code prior to release for full customisation.

"Grails is like other frameworks, ultimately limiting". All Grails applications have a Spring bean context to which you can add absolutely any Java beans you like and access them from your application. Grails also has a sophisticated plugin architecture, and eminently flexible custom taglibs that are a refreshing change from JSP taglib.

"I can’t find Grails programmers". Any Java developer is easily a Grails developer. Plus there are far fewer lines of code in a Grails application than a standard Java web application, so getting up to speed will be much quicker.

"Grails will make you popular with women". Sorry quite the opposite, you will be enjoying coding so much you won’t be chasing any women for a while. We should put this as a warning in the README actually, along with a disclaimer about any potential divorce that might result from hours spent playing with your Grails webapps.

Why not come and hear other people talk non-FUD about how they are building web applications in double quick time at Grails Exchange 2007, tickets available now.

[from:http://www.anyware.co.uk/2005/2007/07/02/10-common-misconceptions-about-grails/]

 

Slides for my Grails Exchange 2007 talk

January 31st, 2008

So I talked at Grails Exchange 2007 about how we used Grails 0.4 through 0.5.6 to deploy five commercial branded websites in 2007.Skills Matter asked for all the slides up front, like most conferences do, but I "refused" because if you are doing a presentation that is not death by powerpoint, printed/pre-available material ruins the experience and stops people paying attention.

Finally I have put the slides into a PDF (24MB) so they can be viewed alongside watching the video of the talk. There’s also an HTML version here so you don’t need to download it all first. The video of the talk rarely includes the slides so following it is a bit of a tricky endeavor. Please note that these slides are not complete because the "Render slide for every stage of build" option in Keynote doesn’t do what it says. It doesn’t render build items that are part of smart builds… so when you get to the "Build scripts" slide, you have to imagine the other text coming up one by one: Bean/Spring configuration, ORM mapping, deployment descriptor, log configuration, test database, servlet container, and then "bang". I’m new to presenting and it shows, but I had a good time doing it. I’m a big fan of Presentation Zen and I really dislike bullet point presentations. The Presentation Zen book rocks - I only wish it was out before I did my talk! Your talks will be changed forever for the better if you buy it and read it. Garr Reynolds, the author, has a great blog.

However people laughed at the right points which were good fun circa slides 14-16. You end up with a lot more slides with this kind of approach, and its hard work to put it together, but its more fun.

It is hard to apply these principles to the "this is how you code it" part of technical talks… I’ll continue experimenting with it. I find large chunks of code in presentations hard to follow, and quite boring frankly. I’m more impressed by the results of the code and a little info about how, for the rest I’ll use docs / a book.

Thanks for everyone who came to my talk at the end of the day back in October - like I said on the day it wasn’t exactly going to tax people mentally, a bit of light entertainment Grails propaganda. Sorry it took so long to get the slides up, but you’ll see why I had to wait for the video to be live before I did it.

[from: http://www.anyware.co.uk/2005/]

 

Groovy On Rails is not accepted by Ruby On Rails creator

Today Graeme Rocher - project lead of Grails - received a mail from David Heinemeier Hansson - creator and project lead of Ruby on Rails to congratulate us with the first release of Grails and to ask us to not use the name Groovy On Rails.

We've decided - as a team - to no longer use the Groovy On Rails name but I have some questions about this request that I would like to see answered. For me the demand is a over the top, especially since the name "Ruby On Rails" is not protected by a trademark. I can understand the Ruby On Rails people want to protect their brand but they should really choose the correct legal ways to accomplish this instead of alienating people.

Again, we made this decision as a team and valued a good relationship with the Ruby On Rails community over a flame war which is also my personal choice. See the message on the Grails mailing list to announce the official name change.

[from: http://www.jroller.com/sdevijver/]

 

Rejoice! Grails 1.0 is here

February 5th, 2008

Now, if you can reach the Grails website you will be able to download Grails Version 1.0, which has finally "gone gold" and has brought the Codehaus server to its knees already it seems! Give the Codehaus guys some time to rig up something that will oil the wheels a bit, as there’s a definite overload situation going on with the site.

Most people understand that psychologically a 1.0 release is important. It sets the baseline and foundation for what is to come in the future. Grails 1.0 is incredibly rich in terms of core features, and has a growing list of free plugins that add all manner of powerful functionality.

Grails 1.0 has a powerful ORM DSL now for tweaking what Hibernate does behind the scenes in an intuitive way, including index generation. We’ve also now got Hibernate’s second-level caching in there. Not to mention the frankly pretty twisted auto unmarshalling of JSON/xml request payloads into beans, and the withFormat content negotiation stuff.

We have also put together a framework for automatically running functional web tests on "specimen" applications held in SVN as part of the Grails continuous integration builds. There are some teething troubles with the server environment but the whole process is working locally, and we just need to fill SVN with some good test apps with, more importantly, some comprehensive webtest scripts.

This will effectively form a kind of "TCK" for Grails and will ensure stability against the 1.0 baseline functionality - in addition to the large number of unit tests that Grails undergoes constantly as part of the continuous integration build platform (the rather excellent Bamboo as it happens). Contributions of non-trivial applications with comprehensive unit and webtests would be appreciated.

This is in addition to the work Graeme did to tie together Groovy SVN HEAD and Grails SVN HEAD in continuous integration to ensure that we spot any changes to Groovy that break Grails as early as possible, as well as giving the Groovy team a great stock of code to run their changes against.

We’re looking forward to talking to all the new Grails users that this 1.0 release will bring!

[from: http://www.anyware.co.uk/2005/]

 

Your way to Groovy

One main factor in the upward trend of animal life has been the power of wandering.

—Alfred North Whitehead

Welcome to the world of Groovy.

You’ve heard of Groovy on blogs and mailing lists. Maybe you’ve seen a snippet here and there. Perhaps a colleague has pointed out a page of your code and claimed the same work could be done in just a few lines of Groovy. Maybe you only picked up this book because the name is catchy. Why should you learn Groovy? What payback can you expect?

Groovy will give you some quick wins, whether it’s by making your Java code simpler to write, by automating recurring tasks, or by supporting ad-hoc scripting for your daily work as a programmer. It will give you longer-term wins by making your code simpler to read. Perhaps most important, it’s fun to use.

Learning Groovy is a wise investment. Groovy brings the power of advanced language features such as closures, dynamic typing, and the meta object protocol to the Java platform. Your Java knowledge will not become obsolete by walking the Groovy path. Groovy will build on your existing experience and familiarity with the Java platform, allowing you to pick and choose when you use which tool—and when to combine the two seamlessly.

If you have ever marveled at the Ruby folks who can implement a full-blown web application in the afternoon, the Python guys juggling collections, the Perl hackers managing a server farm with a few keystrokes, or Lisp gurus turning their whole codebase upside-down with a tiny change, then think about the language features they have at their disposal. The goal of Groovy is to provide language capabilities of comparable impact on the Java platform, while obeying the Java object model and keeping the perspective of a Java programmer.

This first chapter provides background information about Groovy and everything you need to know to get started. It starts with the Groovy story: why Groovy was created, what considerations drive its design, and how it positions itself in the landscape of languages and technologies. The next section expands on Groovy’s merits and how they can make life easier for you, whether you’re a Java programmer, a script aficionado, or an agile developer.

We strongly believe that there is only one way to learn a programming language: by trying it. We present a variety of scripts to demonstrate the compiler, interpreter, and shells, before listing some plug-ins available for widely used IDEs and where to find the latest information about Groovy.

By the end of this chapter, you will have a basic understanding of what Groovy is and how you can experiment with it.

We-the authors, the reviewers, and the editing team—wish you a great time programming Groovy and using this book for guidance and reference.

At GroovyOne 2004—a gathering of Groovy developers in London—James Strachan gave a keynote address telling the story of how he arrived at the idea of inventing Groovy.

Some time ago, he and his wife were waiting for a late plane. While she went shopping, he visited an Internet café and spontaneously decided to go to the Python web site and study the language. In the course of this activity, he became more and more intrigued. Being a seasoned Java programmer, he recognized that his home language lacked many of the interesting and useful features Python had invented, such as native language support for common datatypes in an expressive syntax and, more important, dynamic behavior. The idea was born to bring such features to Java.

This led to the main principles that guide Groovy’s development: to be a feature rich and Java friendly language, bringing the attractive benefits of dynamic languages to a robust and well-supported platform.

We don’t want to offend anyone by specifying exactly where we believe any particular other language might fit in the figure, but we’re confident of Groovy’s position.

Some languages may have a few more features than Groovy. Some languages may claim to integrate better with Java. None can currently touch Groovy when you consider both aspects together: Nothing provides a better combination of Java friendliness and a complete range of modern language features.

Knowing some of the aims of Groovy, let’s look at what it is.

[from: Groovy In Action by Dierk Konig]

 

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.

[from: http://graemerocher.blogspot.com/]

 

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 energized work, 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!

[from: http://graemerocher.blogspot.com/ ]