我正在将一个应用程序移出一个svn存储库,它将一堆其他东西分享到它自己的全新的存储库中。所以,我有机会重新开始布局。
应用程序本身有两个组件 - 一个合理标准的Java webapp,与数据库对话;后端组件,也是Java,用于轮询数据库,并根据它发现的内容启动长时间运行的处理任务 - 基本上,DB被用作队列。代码分为三个包:
org.blah.common
- 在网络应用和后端之间共享的代码,例如DAO org.blah.webapp
- 网络应用;这取决于org.blah.common
,并构建为.war
文件。org.blah.backend
- 后端流程;这取决于org.blah.common
,并构建到包含jar和一些脚本的tar文件。我也想将其他一些tomcat和apache配置到svn中。
现在,所有三个软件包都在src
目录下的svn中,并且有一个ant脚本,其中包含构建不同部分的不同目标。它有点杂乱 - svn:ignore属性已经变得非常大了,并且一个目录中的脚本与src
下的某个包中的代码相关,而另一个中的脚本与启动相关并不是很明显。并停止tomcat。
我被maven standard directory layout吸引,但我以前没用过它。我想出了这个:
common/
src/
main/
java/
resources/
test/
java/
resources/
target/ # Not checked in
common.jar
webapp/
src/
main/
java/
resources/
webapp/
test/
java/
resources/
target/ # Not checked in
webapp.war
backend/
src/
main/
java/
perl/
resources/
test/
java/
resources/
target/ # Not checked in
backend.tar
infra/
tomcat/
bin/
conf/
apache/
bin/
conf/
db/
tables/
procs/
triggers/
请注意,现在,我不打算迁移到maven - 我会调整现有的ant脚本,因为它们有效。我想在将来的某个时候继续选择移动到maven(或像buildr这样使用maven布局的东西)。
所以:
答案 0 :(得分:1)
- 这似乎是布局存储库的合理方式吗?还有什么东西可以让我更进一步吗?
嗯,Maven捕获了行业最佳实践,包括布局,所以即使你现在没有使用Maven,这似乎也是一个非常好的选择。实际上,从其他技术迁移到Maven时,这是推荐的迁移策略:首先,转移到Maven布局并更新现有的构建脚本,然后介绍Maven。在你的情况下,如果所有项目具有相同的生命周期(如果它们全部一起发布),我没有任何特别的评论,除了可能没有用Maven以这种方式管理的infra项目,但是现在没有任何阻止。
- 对于刚接触该应用的人来说,这是否会显而易见?
我觉得非常清楚,老实说,如果有人遇到问题,如果他们无法适应,也许是他们需要修复的问题:)
- 如果我决定使用它,这会与maven兼容吗? (我知道理论上,你可以让maven使用任何布局,但我相信他们推荐一个标准是有原因的。)
它似乎与Maven几乎完全兼容(除了我所说的infra部分,但这确实不是问题)。是的,如果您不必修改Maven的配置并使用默认约定,那么它显然更简单。请注意,您可以与Ant构建并行设置Maven构建以无缝移动。
- IDE会遇到任何问题吗? (根据我所使用的计算机,我使用intellij或eclipse。我团队中的其他人 - 对此有帮助的人 - 使用netbeans。)
很长一段时间以来我没有将Ant项目导入到这些IDE之一,但我认为他们都应该能够处理这种布局(使用Maven时100%确定)。回答这个问题的最好方法是做一些测试当然:)
答案 1 :(得分:0)
我唯一的问题是我希望src
目录直接包含源代码,而不是上面的布局。但是我认为这是一种思考方式,我可以很快克服,特别是在Eclipse中。
答案 2 :(得分:0)
为什么存储库中的目标目录?我喜欢不检查构建结果,因为它们可以轻松复制。如果它们不能轻易复制,则应该解决这个问题,而不是检查二进制文件。
除此之外,我没有看到这种布局有任何问题。除了tomcat目录,它是标准的maven布局。