炒持续集成续集

  通过对炒持续集成这道菜的一些留言发现部分朋友没有真正理解这道菜的真谛。
  现在我将我对这道菜的理解进行一些总结.
  下面先看看一张简易关系图(Hudson+Maven+SVN)

在上面的图中可以看见得出几条路径
1. Maven ————> Hudson
2. SVN ————> Hudson
3. Maven ————> SVN

先从Maven到Hudson： Maven与Hudson的关系相当于显示层和控制层的关系。为什么怎么说呢！因为Hudson本质不对源码进行编译，测试打包等底层操作。这些底层的操作都是交给Maven去操作。Maven类似于Javac一样。在Dos界面对Java源码的编译。因此我通常将Hudson看做是类似界面显示（但是如果说Hudson是绝对的界面显示有点不妥，是因为Hudson也是有些插件可以进行一些操作的）。

在从SVN到Hudson：其实关系类SVN将它的源码路径和用户名注册到给Hudson。那么Hudson可以通过注册进行访问SVN，从SVN中取出源码。这里源码可以是任何的计算机语言。

在Maven 到SVN：其实关系就相当于直接用Maven的scm连接SVN然后进行源码的操作。不过这样学习成本将不小，界面也不是很友好。因此才会引入Hudson通过界面配置进行集成。如果不用Hudson其实也是可以通过Maven和SVN进行集成。

总结：
   因此将Maven+SVN+Hudson进行集成是一个学习和操作方便的组合。同时如果明白这些工具的主要作用。其实Maven也可以用ant替换，SVN也可以用CVS替换。至于怎么使用Hudson怎么使用Maven，怎么使用SVN等，我将根据留言看是否有必要写贴。

注意：整个这道菜的难点在于对Maven的理解

非常想学习一下，还望楼主继续写贴

小弟对这个不是很懂，不知道理解的对不对，还望多多指教。
按照楼主的介绍，
SVN是源码的来源，
MAVEN是每日构建，也就是持续集成的工具；但它缺少良好的界面，需要用命令操作；
Hudson是一个MAVEN命令的管理工具

Hudson并不能说是Maven命令的管理工具。因为他没有管理Maven。Maven只是一个构建工具。它和Hudson的关联在于Maven在Hudson的Config里面进行了配置。按照现在的分层思想，Hudson是前台，它只显示后端传来的数据。操作数据的就是Maven或者Ant。而提供数据则是SVN或者csv

我近期 正在开发一款持续集成工具。 不过是用于c++领域的。


后续可能集成java

Hudson类似于Cruise Control。楼主能否给一个小例子，大家来研究一下

Hudson--Cruise Control--luntbuild

ant--maven

svn--cvs--Visual Source Safe-clearcase--git

  我认为，“吐故纳新”没有说错。Hudson利用插件形式来扩张引用，它是一个很好的"命令"模式的体现。Hudson通过自己的协议，调用第三方的接口，比如Maven等。Hudson相当于一个大管家，简化（图形化）和统一了部署、发布等操作。

你好！如果有时间，我将发帖给出完整的一个项目使用Hudson+ Maven+SVN+Snoar的实例！如果中途有什么具体问题，也可以直接在该贴上进行讨论！

按你的理解角度来说Hudson是管理了Maven。不过我不是怎么理解的。