我想使用maven作为构建/发布管理/管理我们的Web应用程序的依赖项工具。
我们的Web应用程序项目目录结构如下
-WebContext
------ | SRC
-------- | com.company
------ | WEB-INF
------ |页
根据maven，目录结构应如下所示
-WebContext
------ | SRC
-------- |主
------------ | java的
------------ |测试
------------ |资源
------------ | web应用
因为代码（旧目录结构）由SCM（CVS）维护，如果我们转换为新的maven目录结构以下是问题
如果我改变了目录结构，那么文件需要在CVS中重新发送？如果是，则无法提交所有文件，因为项目规模很大，并且SCM中存在许多标签，并且存在客户端版本。
在不影响现有结构的情况下，有没有最佳方式转换为maven项目？
目前资源位于根目录下，让它们保持原样，而不是转移到src / main / resources
我认为这对所有人来说都是常见的问题，并希望有一个解决方案，任何人都可以指导我使用maven作为构建/发布管理工具。
由于 Dhorrairaajj
答案 0 :(得分：0)
可以将Maven配置为在src而不是src/main/java中查找您的代码。但是，如果您想遵循推荐的Maven项目布局并将代码放在src/main/java中，我建议您首先从CVS（到Git或SVN）切换。
CVS独立跟踪每个文件的修订，由文件路径标识。如果您移动或重命名文件（更改其路径），CVS认为您删除了它并创建了一个新文件，这意味着如果您查看（新）文件的修订历史记录，您就不会查看移动或重命名之前所做的任何更改。就CVS而言，旧路径和新路径是完全不同的，无关的文件。
一些CVS用户通过移动或重命名保存修订历史记录的关联,v文件来解决此限制，但这会有效地更改历史记录：如果您查看项目的早期版本，则该文件将是在新的位置，好像它从一开始就在那里。如果您有基于旧版本的分支，则文件的位置也会在这些分支上发生更改。这可能导致旧版本或分支的构建失败，因为该文件不在构建系统期望它在这些版本中的位置。除了构建问题之外，如果SCM存储库的项目历史记录不准确，则其用途有限。
像Git和SVN这样的新型SCM系统能够正确处理移动/重命名，并提供比CVS更多的其他改进。这是一个很好的机会，可以将您的项目转移到一个不太古老的系统。