今天Pair遇到的问题是，我跟我的Pair在某一个问题上纠结太久，没能找到解决的方案。这是一个很典型的问题。
浏览器兼容的问题，历来让前端开发头疼。再加上是遗留系统，页面上引入了太多了三方和自己的js导致IE下页面无法显示。
看得出，我的Pair对前端开发经验不多，而我又不能一下子指出问题所在（可恶的IE），Pair自信心比较高，会很坚持用自己的方式来解决，他试图修改一些JS的内容来减少业务逻辑的涉入，以测试能否在IE下显示完整。而根据我的经验，这种IE特有的问题多半是某些JS语法的（不兼容）问题，但办法只有从上到下一个一个JS的排除，直到找到问题JS。Pair的做法引入了业务逻辑变化的不确定性，背离问题本身，反而容易引入更复杂的变化。
可惜我对Pair时所应有的态度和精神体会不深，尝试过说服Pair，但见他坚持，不忍冲突，结果是时间白白浪费。
回家路上跟彦辉君聊到此事，他的建议是：
1. 寻求技术帮助
2. 正义提出自己的想法
3. 如果2不可行，寻找更具说服力的力量
还是需要一种Open的态度。
敏捷、Scrum和XP实践里面，到处体现着小步前进。
比如代码重构，这在Martin Fowler的书里面处处谈到，在没有IDE的refactoring功能的帮助下，唯有手头的小步前进，才能保持信心。
持续集成，每次checkin触发一次集成过程，快速的反馈和修复，同样保持信心。
每个Sprint给客户showcase，让实现和需求不偏离太远，才会进入下个迭代，这仍然是个增进信心的过程。
真是欢乐啊！
今天跟凡哥pair，遭遇CXF的蹂躏。客户遗留系统糅杂了JAXB，CXF诸多Java EE和web service“高端”特性，调试很难，好不容易找到负责（反）序列化的XmlAdapter实现，才看到遗留系统工程师编写的奇怪正则表达式，过滤了本不该过滤的字符串，导致web service接收端接收数据不完整。
一边pair，一边感叹，Java的企业应用现在如此复杂，Java技术发展已经背离了最初解决问题的初衷。Java出路在哪里呢？
1. 首先，请您介绍你自己，从什么时候开始你从事Maven的推广工作，以及你现在在做些有什么有趣的事情呢？
我从07年开始接触Maven，慢慢学习并在实际项目中推广使用，然后慢慢喜欢上了这个技术。1年之后我开始编写Maven中文博客并翻译《Maven权威指南》，并且维护了一个Google Group，我想这些事情对于Maven在国内的推广起到了一定的作用。也正是由于这些工作的关系，我有机会熟悉Maven的方方面面，并加入了Sonatype —— Maven之父Jason Van Zyl创建的公司。
目前我主要做两方面的工作，其一是维护Maven中央库和Sonatype OSS仓库托管服务，该服务为开源项目提供免费的Maven仓库并帮助他们同步自己的构件至中央仓库。目前有超过600个项目在使用该服务，包括知名的JUnit、TestNG、Ehcache等等。除此之外我也参与Nexus的开发，开源的、商业的都有。
2. Maven 3刚刚推出不久，据说这个新版本在性能上有很大的提高。相比较以前的版本，你觉得最大的变化、最重要的新特性是哪些呢？
Maven 3发布的第一时间我就写了篇博客进行介绍，其实从性能上来说，抛开并行构建不谈，用户不会感受到很明显的提高，这是因为Maven本质上是将构建工作给其他工具来做的，例如编译用javac，测试用JUnit，因此给Maven的改进余地不多。使用Guice代替Plexus从一定程度上能改进性能，但不是很明显。我个人认为Maven 3最重要的改进是清理，包括代码清理和不良特性的清理，例如在Maven 3中，你使用插件不声明版本不会引入快照，而Maven 2就因为快照插件的问题被很多人诟病。此外，Maven 3的并行构建特性也让人眼前一亮，只要模块组织合理，多个模块能够得以同时构建，充分利用多核资源。
3. 在今年2月份，InfoQ有篇新闻是关于Maven 3即将采用Guice来作为新的DI层，请问这在Maven 3里面实现的如何？这对那些采用Maven的开发者来说，有着什么样的好处呢？
采用Guice作为DI容器最大好处在于标准化，Maven之前使用的Plexus历史也很久，但发展得很差，文档也很缺乏，转到Guice后，由于大家更熟悉，就可以吸引更多的贡献者。Maven团队也不再需要花时间去维护，有了问题，可以得到Guice社区的帮助。
Maven 3在采用Guice的同时还必须支持Plexus风格DI标注或XML配置，以兼容现有的数以百计的Maven插件。为此Maven团队基于Guice 2.0所支持的自定义注入器，开发了一个中间层模块，该模块包含一个匹配器来识别你的标注配置是Plexus风格还是Guice支持的JSR300风格，如果是Plexus风格则再应用额外的集成逻辑。实现的细节在这两篇博客中有介绍：The Guice/Plexus Bridge and Custom Bean Injection，Create a Guice Bean Extension Layer。
4. 在InfoQ的这篇关于Maven 3的新闻里，出现了很多开发者对于Maven的评价，可谓毁誉参半。作为Maven的推广者，你怎么来评价这样争论的存在呢？
关于Maven的争论从来没有休止过，类似的争论还可以找到很多。但有目共睹的是，越来越多的开源项目在使用Maven作为他们的构建工具。我想那些人反对Maven主要是以下三个个因素：
- Maven提倡约定优于配置，例如目录结构的约定，很多习惯高度自定义的用户受不了，于是当然就排斥。其实约定有很多好处，例如当你从一个项目转到另外一个项目的时候，你不需要学习另外一套结构。
- Maven的学习曲线陡峭，一些人花了时间去学习，但没体验到快乐就学不下去了，因此完善的文档很重要。
- 与IDE的集成，这方面m2eclipse的质量确实比不过其他集成如Ant，问题也有一些，但这些都在改善。IDEA对Maven的集成就相当不错。
争论还会继续，只要反对者能提出合理的需求，那就是Maven改进的空间。
5. 谈一谈你编写的即将出版的那本新书吧，名字叫《Maven实战》？为什么我需要这样一本新的Maven书呢？
由于种种原因，我翻译的《Maven权威指南》没有能够在国内出版，这是一个遗憾，很多人告诉我他们自己打印了那本书看，这让我很感动。我很希望国内能有一本印刷上市的关于Maven的书，这是我写《Maven实战》的最原始动机，后来我发现借助这个机会，我能将书写得更接近国人，包括语言的组织，以及内容的安排。例如在《Maven实战》一书中，我介绍了使用Maven进行自动化部署，以及结合Hudson进行持续集成等内容，这些内容都是我实际体会到大家迫切需要的。前面说过，Maven的学习曲线比较陡峭，这是他的天生问题，弥补的办法就是提供完善的文档，对于初学者来说，这样一本书无疑能帮他们少走弯路，节省时间。
6. 请您给那些不甚熟悉Maven的开发者们一点建议，怎样才能又快又好的掌握Maven呢？
首先不要排斥它，很多人因为Maven有很多约定而受不了，其实Maven这样做能帮助你更规范的管理项目。其次，如果不要太依赖于IDE，IDE能做很多事，但在自动化构建以及持续集成这些方面他不擅长，试着多用用命令行，熟悉Maven命令的同时，也能更深刻地体会一些Maven的概念。还有要耐下心来读读文档，你买我的书看当然最好，想省点可以看《Maven权威指南》。最后就是实践啦，可以看看开源项目怎么用Maven的，然后在实际的项目中尝试，并使用Nexus建立自己的Maven私服。
需求总是奇怪的，但好在有这么一个还算顺手的工具。
我有一份code base的两个不同版本库，这两个版本库所在的server是不一样的，然后对应本地有两个不同的Working Copy。我需要把一个版本库里面做的部分变化，merge到另外一个版本库。一开始想过用SVN命令行diff，但似乎那是服务于同一个版本库的不同branch的，也就是要host在一个server上的。
幸好在小乌龟里面发现了Merge revisions to…这个功能，具体做法是：
小乌龟干活有两个问题：
