GRAILS IDE

作为一个非牛非鸟还算普普通通的开发人员而言，如果离开IDE，就会觉得生活变得很枯燥。
GRAILS有着很好的IDE支持，这一点在GRAILS的官方网站上有详细的记载。这里我就我用过的两种IDE发表一下个人意见。
[list]
[*]Eclipse作为当前java社区使用最为广泛的IDE却在Groovy和Grails的支持中作的很一般。在我们使用Grails 0.6的过程中，Eclipse虽然可以通过扩展命令实现对Grails命令的支持，却在命令结束的时候没有办法自动关闭JVM，结果是比手工启动Grails更为麻烦。不过，IDE由于对出错的信息有高亮显示，所以在出错的时候进行错误分析还是比控制台更有优势。就Groovy的插件而言，codehaus官方的Eclipse插件并不好用，而且对Grails几乎没有任何支持，从而造成了我这种懒人们对Eclipse的背叛。在Grails进入到1.0版本后，对Eclipse的支持比以往有所提高，比如run-app已经成为默认的run操作，不再需要通过复杂的command line配置来达到同样操作。但由于我已经习惯使用IntelliJ了，所以依然将Eclipse弃用。但是对于纯粹的Groovy应用开发而言，因为IBM的Project Zero的插件的存在，我有可能会选择回归Eclipse的阵营。
[*]再回头来看看Grails官方开发使用的IntelliJ。说句良心话，如果不是因为要用Grails做开发，估计这一辈子我也不会使用IntelliJ。按照某些权威人士的话，IntelliJ由于在运行前执行过多的文件扫描，从根本意义上就不能称之为现代的IDE。但是我们不能否认IntellJ对于Grails开发的集成比Eclipse和Netbeans都优秀。另外，虽然这个东东有免费的社区版本，但是对商业开发它还是收费的，这对于那些对版权相当尊重的公司而言是个硬伤。不过对于我们这种相信共产主义的普通大众而言，这种资本主义的问题根本就不是问题。另外，对于从Eclipse投奔过来的开发者而言，IntelliJ的配置和使用方式还需要一定的时间来适应。比如说，关于多国语言资源文件的编辑，我是搞了半天才知道IntelliJ默认的支持就可以搞定，害得我还自己手写ant任务去转换。（注：IDE Settings/General/Properties Files中将Transparent native-to-ascii conversion）。
[/list]
尽管这两款IDE都有Groovy程序的debug功能，但是基本上很少用。原因很简单，没有必要。由于Grails本身的出错信息已经相当的明确，所以基本上我们除了log已经不需要其它复杂的工具来作为辅助了。
从效率上来说，如果能有一种工具能够提供很好的语法编辑和格式化错误信息出力，我觉得大可以抛弃上述的两种IDE。毕竟Grails在development环境下运行还是很吃内存的。