About questions of building sub modules separately for multiple modules

Help/Discuss
1

I have a project with a main module and several sub-modules managed using git submodules. I want to use continuous integration and deployment (CI/CD) to build an image of one of the sub-modules. However, I’m unsure how to access the properties and plugins from the main module’s build.gradle file for the sub-projects, even though I have the main module’s Maven coordinates.

After simplifying my project structure, it looks like this:

parent
│  .gitignore
│  .gitmodules
│  build.gradle
│  gradlew
│  gradlew.bat
│  HELP.md
│  settings.gradle
└─server
    │  .gitignore
    │  build.gradle
    │  Dockerfile
    │  gradlew
    │  gradlew.bat
    │  HELP.md
    │
    ├─gradle
    │  └─wrapper
    │          gradle-wrapper.jar
    │          gradle-wrapper.properties
    │
    └─src

In the build.gradle of my parent, the dependencies and plugins of the child project are defined as follows:

subprojects {
    apply plugin: 'java'
    ...
    dependencies {
        implementation 'org.springframework.boot:spring-boot-starter-web'
        ...
    }
}

Using the gitmodules method, the parent and server are stored in different git repositories:

.gitmodules

[submodule "server"]
    path = server
    url = <https://gitee.com/xxxxx>
    branch = master

Now the problem is that there is no problem running locally because they are in the same directory and can find each other through relative paths, but when you want to use CI/CD, relative paths no longer work. For example, if there is this property in the build.gradle of the server project:

sourceCompatibility = '17'

This is a very simple property used to set the compilation version. If locally, when compiling in server through the parent’s subproject, there will be no errors. But in general, when submitted to your own repository, an error will occur because the plugin ‘java’ cannot be found since the parent cannot be obtained (because both parent and server have their own repositories). This leads to inconsistent results between local builds and CI/CD environments. If you are using Maven, server can obtain this pom file through the parent’s coordinates and then inherit it, so there is no impact. But in Gradle, what should be done?

3

Sorry, I may not have expressed my point clearly. I have made some modifications to the content.

4

If server is to be built standalone, it should not be part of the parent build.
One project should never ever ever ever be part of multiple builds.
You should model server as a standalone build that you then include as a whole using composite builds.

If you don’t want that, because server is an integral part of parent and cannot live without it, but still don’t want to model it as an independent build, but as such a sub-project, then you have to make sure in CI/CD to also have the parent project there and build it like you build it locally, because if you build server standalone on CI/CD, that is then exactly “a different build” you use the project in, which you really shouldn’t do and for which composite builds are there.

The cross-project configuration you do in parent is bad practice anyway. Practically any subprojects { ... } or allprojects { ... } is a code smell and should be avoided. Instead you should use convention plugins to share build logic across multiple projects. These can be implemented using precompiled script plugins, or any other way to write a plugin.

5

Okay, I understand. Maybe you’re right that inheritance isn’t a good way to do it. I’ll try a different approach to implement it. Thanks a million.