从迁移一个不寻常的SVN目录结构到Maven？(Migrating to maven from an

相反，一个“正常”的svn的目录结构，我使用的结构如下：

trunk/
  project1/
  project2/
  project3/
  ...
branches/
  project1-branch/
    project1/
    project2/
    ...
  project2-branch/
    project1/
    project2/
    ...
tags/
  project1/
    V1
    V2
    ...

正如你看到的，我没有为每个项目单独的三元组（主干/分支/标签）。

对于开发我做主干包含我需要的所有项目结账（有时稀疏结账）（有项目，有些项目之间的依赖关系简单地库）。

我在这看到的好处是：

更新和签入是容易的，因为我有所有项目的一个共同的根目录下（干线）。一个简单svn update或svn commit做这一切。
标签或分支的创建很简单，因为它是唯一的，我有到主干svn copy这一点。（分行和标签实际上包含比需要更多的项目，而是一个svn copy是便宜，如果需要，我仍然可以在一个分支或标记做稀疏检出）。
从一个项目的资源移动到另一个是容易的，因为他们都住在同一个存储库中。
全球重构（例如改变常用类的包）是很容易当我工作的树干全结账，因为我可以肯定我不会错过的项目。
合并是容易的，因为我可以随时即使有从一个项目到另一个重构举动立刻合并整个分支。

我打算迁移到Maven和拆分都从主干到Maven项目的项目。我想（我现在正在用巨大的定制Ant文件）从Maven的依赖管理，并从可用的插件受益。

现在，我的问题是：

我一定要改变SVN目录结构来给每个项目自身的三重（主干/分支/标签）？我想答案是肯定的。
如果我改变了结构，其中的好处上面提到的我松（我的意思是将更加复杂与Maven这样做）？
什么是等价的方式与Maven做呢？

Answer 1:

有没有这样的事，“正常” SVN目录结构。有在讨论不同的方法被称为“规划你的版本库组织”一节中的版本控制使用Subversion的书（连/trunk ， /tags ， /branches的名称只是约定，有一个标签与分支没有区别，除了在你对他们的看法）。

我一定要改变SVN目录结构来给每个项目自身的三重（主干/分支/标签）？我想答案是肯定的。

不，你不必。见例如Apache的ServiceMix的源代码树：这是一个多模块Maven项目，但这些模块在一个trunk 。在另一方面，XWiki实现它不是一个单一的产品，而是在其详细的产品和项目的生态系统 源代码库页上，有许多主干/分支/标签。你可以浏览它的仓库在这里拿到布局的想法。

但是，选择一种方法或另一种不只是一个品味的问题，它实际上取决于你的发布周期（更多mvn release后）。如果从您的项目共享相同的版本（一拉ServiceMix的）部件，我只用一个行李箱。如果他们有一个独立的发布周期（一拉XWiki实现），我会使用多个“主干/标签/分支”就像在描述一个结构这个线程：

 myrepo + .links (2) + trunks + pom.xml + parent-pom (1) + trunk + pom.xml + project-A + trunk + pom.xml + project-B + trunk + pom.xml 
1）该项目的父POM拥有自己的发布周期。每个组件的POM将使用它作为母公司（有简单提及groupId和artifactId ，没有relativePath ）。对于一个版本中，您必须先释放父POM。
2）这是一个建设，使项目的具体分支的易签出即通常指主干。一个颠覆用户签出myrepo / .links /树干得到的所有来源的最新修订版。诀窍是，该目录包含外部链接（即与svn:externals属性）这个项目（父POM，项目A，项目B）的所有其它模块的树干。这个目录在pom.xml永远不会释放，它只是包含了三个模块，使多模块构建一个模块部分。有了这个结构你能够轻松设置分支机构，例如：
 myrepo + .links + branch-2.x + pom.xml 

我用这个设置很多次，它工作得很好。

如果我改变了结构，其中的好处上面提到的我松（我的意思是将更加复杂与Maven这样做）？

我来回答每一个点一个接一个。

更新和签入是容易由于使用svn的外部。一个简单svn update或svn commit做这一切。
标签或分支的创建很简单，因为Maven的版本插件会处理这件事情（和标签和分支将清洁剂）。
从一个项目的资源移动到另一个看起来并不复杂。
全球重构（例如改变常用类的包）是容易的，因为你仍然可以在行李箱的一个完整的结账工作。
合并可能不太容易。但你真的移动从一个项目中的类到另一个频繁？

什么是等价的方式与Maven做呢？

如果需要使用svn的外部使用建议布局的Maven插件发布，一个。

Answer 2:

如果你想使用Maven 只为依赖管理，你认为你的项目结构已经足够好/非常适用于你，这里是一个有用的提示： 忘记Maven的。

Maven是不仅仅是一个依赖管理工具多了不少，它自称为“ 软件项目管理和综合工具 ”，这显然包括依赖关系还很多其他的基地了。既然你只希望有依赖关系管理，你至少应该看看，如工具Ant的常春藤，而纯粹的依赖管理的目的存在。

常春藤的真正的好处是，你可以解决依赖管理有很多比Maven的更好和更细粒度的同时保持现有的项目结构，构建脚本和公正的东西，你已经建立在它之上。常春藤不加固任何项目结构或配置模式，它允许您定义要从依赖管理工具可以得到什么，然后将其添加到您的项目，而不是强迫你的项目成为结构性的东西被一些人在象牙塔里说的。

为了进一步帮助你决定，这里的双方相互之间的比较：