Best practice to mange multiple projects with a (maven) repository and Maven/Gradle?

Question

This is not an exactly Gradle problem. But a more general build question. We have some projects structured as the following:

-- A  (by team 1)
  -- build.gradle
  -- settings.gradle
-- B (by team 1,3)
  --build.gradle
-- C (by team 2)
-- D (by team 3)

They are separate CVS modules. A, B and D are java projects and managed by two teams (team 1,3). C is an C++ project managed by another team (2). B use C via JNI. (The fact that C is C++ is not that important, the key is that it is developed and managed by another team.) There are two applications, A is the entrance of the application 1, A->B->C; while D is the entry point of the application 2, D->B->C. The development often involves change in all three levels. All three teams sit together and communicate constantly. In practice, we (team 1) might need some changes for application 1 in C; team 2 works on C and gives us a temporary copy; we might need some further changes after integration. We will go back and forth for several rounds for one problem. Similarly for application 2.

Currently, A,B and D are managed by various ant scripts and C by make. We started to explore new tools, in particular, Gradle. In our first cut, A includes B as a sub-project (in the Gradle sense) and they always are built and published together. We also always use the head of C (compiled ourselves from source in windows or grabed the latest Jenkin build) and when we are happy with the build, we tag all three projects. We recently adopt an internal Artifactory repository. We are thinking about how to mange the dependency and versioning. Once we finished, we will introduce it to team 3 for module D as well.

1. We can try to include C as a subproject for A and then always build from the scratch for all three. Similarly include C and B as subprojects for D. The application name can be in the version name for example.
2. alternatively we can always depends on a fixed version of C in the repository.

In 2, we cannot totally depends on the head/snapshot of C because that might involve their development and might be unstable. But we need their change so frequent that it seems inpractical to put a new version for every C changes.

We are wondering what is the best practice for such a setup? A quick search in internet does not yield much results. Can anyone give us some advices or point me to some books or documents?

Thank you so much.

Answer 1

As I can read from the whole description it seems that during development time (and in production also I suppose) all 3 projects are really tight coupled. So I'll use the first scenario for convenience of work. I'll also build all the projects together, tagged them together and keep same versioning pattern - in general even if it's separated this is a single project.

The first scenario can be carried on till no 3rd party (external) application/library/team uses any of the projects (I suppose it could only be C project). Then backward compatibility issues/pull requests and other may happen and the mentioned projects should be separated. If there's no chance that such situation takes place You shouldn't bother too much. But remember about good (semantic) versioning, and tagging the repository to be always sure which version is deployed to which environment.

UPDATE

After question update.

If You've dependency paths like A->B->C and D->B->C I'll reorganize the project structure. B should become a subproject of both A and D or maybe not a subproject but an external library that is added to these projects. B and C should be a separate project with B dependent on C.

All three projects (A,D, B with C) should be separately versioned (especially B with C) because this is a common part for clients (A and D).

Now, for a convenient development You can add to A and D snapshot libs that will be built often on CI server and then update to artifactory. This will allow You to introduce changes to B and have them visible fast in the projects A and D. But stable release of B (and hence C) should be maintained totally separately.

I hope I understood the problem well and helped You a bit.

P.S. Please consider also using gitflow - a branching model. Then You can used SNAPSHOT versions in dev branch and a stable version of B in release.