非jar SVN依赖管理

时间:2011-08-04 03:21:05

标签: eclipse svn maven-2 gradle

假设有两家软件公司,A& B.两家公司都有大约一百个Eclipse项目。两者都有一些应用程序最终产品。每个最终产品项目的依赖性都与其他项目不同。

A依靠maven进行依赖管理。它实现了代码冻结,因此将项目彼此分离,因此能够使依赖关系变得无比。

B依赖于Eclipse Subversive插件。对于任何特定的最终产品项目,它所依赖的所有项目都将从SVN中检出并包含在Eclipse项目构建路径中。如果一个项目依赖于50个项目,那么所有50个项目都将受到源代码修改的影响,这就是他们不使用Maven的原因。

两家公司合并为AB公司。希望有一个类似于依赖关系管理的maven,它也适用于SVN存储库。也就是说,假设的POM应该能够指定jar依赖(公司A样式)或SVN源代码依赖(公司B样式)。如果依赖项是一个jar,它应该将依赖项从存储库拉到开发人员工作站的maven缓存中。如果依赖项是SVN中的源代码,则应将其检入SVN工作目录。

AB公司应如何在技术上统一两种建构态度?我指定“技术上”以避免回答那些涉及微观管理或修改合并公司开发人员的哲学态度的答案。

Gradle会有什么帮助吗?如果是这样,怎么样和为什么?还有什么其他选择?

2 个答案:

答案 0 :(得分:3)

据推测,B公司创建的项目创建了打包(jar)产品,作为其交付/构建的一部分。如果是这种情况,那么公司AB可以创建他们自己的工件库(我的公司使用Artifactory),并且公司B的项目可以手动(或自动)添加到该存储库作为版本化版本或快照。然后,公司A项目可以将它们的依赖项指定为jar依赖项,并从artifactory中提取。

对于深度依赖并经常同时编辑的项目,我建议将它们作为一个根项目的子项目。

我的上述建议都不需要使用Gradle,但Gradle可以很容易地实现这一点。

答案 1 :(得分:2)

svn:externals是一种技术解决方案。然后教育开发人员滥用svn Maven依赖关系不那么糟糕。