采用Rail的理念设计一个Java开源框架（GreenTea），希望有人感兴趣，能够协作开发

Question

没人顶啊，虽然已有grails(构建于Spring、Hibernate和SiteMesh 之上)了，还是先支持一下，有时间下载来试试。ruby on rails真是让人惊奇的东东，不过说实话，太自动了也未免让人不那么放心....另外，楼主的大部分理由我并不太赞成....

Answer 1

我没实际使用过ror，单凭自己的一点了解来发表我的看法，
ror适合实现自主的需求， 因为这种约定只能是自己内部的约定，没有语法或者其它的强制规范。
而当面对实际客户的千奇百怪的需求时，依赖默认的约定来实现新的需求就有些束手束脚了。www.javaeye.com 现在改为ror实现，但是论坛用户反映的大量bug，到现在也没修复完，
固然robbin的时间有限，但是有些看上去普通情况下几分钟就可以修改好的东西，不能简单地以时间不足来作为理由吧？
喜欢ror的人总是说配置文件的繁琐，但是配置文件也可以采取约定的方式阿比如我的一张表为： userinfo,那么我就可以借助代码生成器生成有关的约定文件，
实现增删查改，国际化，表单校验，分页多条件查询，查询结果的导出，全文检索等等。
然后再次基础上灵活的修改去实现定制的业务逻辑即可。
代码风格模板随时可由自己定制更新，约定编程不应该局限于ror，任何场景都可以进行约定。以上是个人意见。

Answer 2

首先谢谢各位提供的意见。    我相信任何或者绝大部分框架都是可以通过代码生成工具来处理的；而且，基本上都是生成出来就可以运行。但是，我关注的重点不在这里，绝大部分工程都是修改多于编写，需求变化往往会超过预期。    在Struts、Hibernate和Spring这些配置文件中，存在的一个问题是“耦合点”的问题。比如，一个Hibernate的Bean里面的属性是通过配置文件中的某个标签与数据库中的字段进行“耦合”的。如果一个耦合点在程序里，目前的各种IDE所拥有的良好的“重构”功能可以很好的解决这个问题。即便没有使用这个功能，也可以通过编辑器很快找到因为修改相关耦合点而带来的错误。配置文件的致命的弱点恰恰出现在这里，IDE无法将这些耦合点关联起来，我们只有手工的修改这些“耦合点”，如果忘记了，只能在运行时才能检查到这些错误。这样的耦合很容易引起修改的不便和调试的繁琐！如果增加了一个字段，你的框架有多少个地方需要修改（手工和自动）就有多少个“耦合点”了。    Hibernate的持久化还是非常好的，如果有时间，我会将其提供为框架的持久化机制一个候选方式。但是也不是说他已经很完美了，足够了。下面是从网路上引述的一段话：“最近一年，业界也在反思，到底 ORM 给我们带来的是便利还是麻烦。矛头指向大名鼎鼎的 Hibernate ，纷纷议论其性能问题，大家似乎要达成这样的共识：在业务逻辑复杂的地方用SP，而一般的CRUD还是 Hibernate，就连全球知名的 BearingPoint 也有类似看法。下面一个简单的例子，说明了传统 ORM 工具的弊端。”。如果你做过报表，那么你肯定就不会在这个时候采用Hibernate了。    据我经验，目前很多配置文件是重复的、多余的，可以通过“约定”得到。当然，有些违背“规则”的文件是需要通过配置文件处理。这种情况需要采用典型的“80/20原则”，因此，我希望能够减少这80％的配置文件的维护的工作量。    坦率地说，采用Struts+Hibernate+Spring框架的程序编写起来真的是不轻松，维护起来也是让人头大！