Java为什么不能动态部署，为什么没有PHP/RoR简单

这个问题讨论起来没有定论,用什么顺手用什么吧, 我们公司还用一个叫pike的语言呢,  这个语言一万年都无法升为主流. 呵呵

把rake与ant放在一起，是指他们的理念是类似的。也就是在这个意义上说，maven要更加ROR一点，而且有一个更加抽象、内洽的构建模型。rake只是和ant一样，不过是make在ruby上的一个异化，本质上还是diy的。ant也一样，但maven就完全不同，其区别类似于控制反转。

ruby在一定位面的成功是可以预期的，就如lua在游戏脚本领域独领风骚一样(我对lua的兴趣远远大于ruby),也像php在90年代末的大肆风行之后仍然占据着web位面的重要位置。但是能够动摇java平台的，现在看来仍然只是.net一个而已。

以前玩过perl,python，但是现在只要是有java虚拟机的地方，我都会装一个groovy包，太简单顺手了。

其实，有时间去玩ruby，为什么不花1/5的时间去看看groovy.

我是不用Maven的，太复杂了，学不会

Rake的意义在于
1)它是一种面向构造领域的工具，很自然
2)它本身就是Ruby程序，可以按Ruby语言的方式来编写任务的内容
3)如果ANT或者Maven没有提供这样的功能，你可以当时就编写程序，根本不需要这些查检，那个插件的

我不能想象XML文本能做这些事情。

相比于rake或者ant,maven的复杂在于假如前两者是"一种面向构造领域的工具"，那么maven就是已经建成的构造领域机器。其复杂性只是因为它为开发者提供了一套运作规则和完整的默认实现，如同ROR一样。
从插件的角度来看，maven是比较弱的，虽然它的目标是能够用其他的脚本语言来搞定插件，但是现在没看到(也许只是我没看到？)....hehe.
只是，自己手工编写maven插件的机会基本上很少，毕竟构建是一个很狭窄的领域，而maven本身是一个相对完整的模型，内置了众多常见的插件，并能够方便的集成ant的插件。更多的是在配置这些插件起作用的阶段。
其实，要说到diy,groovy其实也有一个AntBuilder，可以满足一下diy的乐趣。但是，我觉得maven已经足够好，不需要为构建费更多的心思了。

始终觉得xml做为构建文件不是很好的选择,简单情况下还好,复杂了就会变的很难看,绝对没有脚本语言来的清晰.ant,maven做的是脚本的工作,用的不是脚本语言.

我现在越来越反感用XML来作为Java web项目的配置文件了，尤其是Spring的XML配置文件和Webwork的XML配置文件。项目一旦变得比较大的时候，想要重构，是非常困难的。所以我认为，必须消除XML配置文件，而且必须让配置信息可以有重构支持，所以这种配置信息必须以Java代码的方式来编写，也就是说应该用annotation去写，而不是XML。所以Hibernate的映射文件非常适合使用annotation，而spring和webwork这种全局性的配置文件，用annotation则太分散了，用Jacn就很不错，考虑给Jacn增加webwork支持。

jacn这个项目也太小众了吧。而且去年7-8月一个月内发布了3个小版本，之后一直就没动静了，这样也敢用？
xml配置确实很烦，以前我有一个项目用groovy脚本来作spring的配置，不过也没有重构的支持。

我觉得配置烦琐到不可怕，真正可怕的是没有编译器检查和IDE的重构支持。我现在持有这样一种观点，配置信息用脚本还是XML没有本质上的差别(虽然脚本的可读性更好)，对于一种编译语言来说，就应该充分利用编译检查这个优点，否则的话，就干脆全部使用脚本语言编程得了。特别是当我看到RoR使用ruby来写yaml配置，就更加确定这一点，那就是Java项目的配置信息就应该写在Java代码里面，这样才能充分发挥Java的优势，用脚本还是XML配置的路子都不对。

jacn的源代码味道很不好，不过实现原理非常简单，就是用Java去编写配置，然后程序运行的时候读取class文件的bytecode，转换为框架XML配置需要的XML DOM送给框架。实现的要点就是能够通过bytecode读取配置信息，可以把这一功能做成一个基础平台，然后各种框架需要的DOM信息分别写插件实现，其实就是另外一种形式的XDoclet，只不过XDoclet读取的是Java源代码中间的注释信息，而Jacn读取的是Java源代码编译的class bytecode的信息而已，但是显然Jacn这种方式的好处就是编译器可以进行检查，IDE也可以提供重构支持，另外用Java代码写配置，很容易实现一些XML配置很难配置好的功能，例如AOP，事务支持什么的，用Jacn就是一行代码搞定，很直观。

目前对我来说，就是急需给Jacn增加webwork配置文件的功能支持，我准备在有空闲时间的时候做一点这方面的工作，因为一般项目的action数量是很多的，重构Action的时候，对xwork.xml同步修改能力极差，这个缺陷严重影响了对项目的重构质量。

虽然spring和webwork都开始提供annotation支持，但是这种全局性的配置文件不同于Hibernate，他们需要提供一种概览性质的东西，这个时候Jacn比annotation要合适。最后我觉得Jacn这种在Java代码里面写配置的创意很棒。

其实脚本语言也可以有编译期检查的，即搞一点静态类型的东西。
groovy的邮件列表里面有这个需求(从性能角度提出来的)，但是还没做出来，hehe.
而且，groovy留了一个很有意思的口子，和一般动态语言不同的是，它并不介意你声明一个对象的类型。因此，如果在脚本代码中坚持使用类型声明，对于重构的支持还是有可能的。而且，对于有特定类型声明的对象而言，编译期的验证也是有可能实现的。

这种混合结构的类型检查是不彻底的，还不如没有。