Home/ Questions/Q 7800587
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T00:41:09+00:00

Hypothetically there were two software companies, A & B. Both companies have about a

  • 0

Hypothetically there were two software companies, A & B. Both companies have about a couple of hundred Eclipse projects. Both have a few application end-products. 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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0