开发者

non-jar SVN dependency management

开发者 https://www.devze.com 2023-03-25 08:23 出处:网络
Hypothetically there were two software companies, A & B. Both companies have about a couple of hundred Eclipse projects. Both have a few application end-produc开发者_高级运维ts. Each end-product p

Hypothetically there were two software companies, A & B. Both companies have about a couple of hundred Eclipse projects. Both have a few application end-produc开发者_高级运维ts. Each end-product project has a dependency different from the others.

A relies on maven for dependency management. It practices code freezing and therefore decouples projects from each other and hence is able to mavenize dependencies.

B relies on Eclipse Subversive plugin. For any particular end-product project, all projects it depends on will be checked out of SVN and included in the Eclipse project build path. If a project has dependencies on 50 projects, all 50 projects will be subject to source code modification and that is why they do not use Maven.

The two companies merged into AB. The desire is to have a maven like dependency management that would also work on SVN repositories. That is, the hypothetical POM should be able to specify either jar dependency (company A style) or SVN source-code dependency (company B style). If the dependency is a jar, it should pull the dependency from the repository into the developer's workstation's maven cache. If the dependency is source code in SVN, it should check it out into the SVN working directory.

How should company AB proceed with their vision unifying the two build attitudes, technologically? I specify "technologically" to avert answers that would deal with micromanaging or modifying the philosophical attitudes of developers of the merged company.

Would Gradle be of any help? If so, how and why? What other alternatives?


Presumably the projects that company B created create packaged (jar) products as part of their delivery/build. If this is the case, then company AB could create their own artifact repository (my company uses Artifactory) and the projects from company B could be manually (or automatically) added to that repository as versioned releases or as snapshots. Then company A projects could specify their dependencies as jar dependencies and pull from artifactory.

For projects that are deeply dependent and frequently edited concurrently I'd suggest making them sub-projects of one root project.

None of my suggestions above require the use of Gradle, but Gradle makes much of this easy to implement.


svn:externals are a technical solution. Then educate the developers abusing svn that Maven dependencies are less worse.

0

精彩评论

暂无评论...
验证码 换一张
取 消