We started working on gradle multi project. We have our codebase like this:
MyService
|
– Module1
-----build.gradle
– Module2
-----build.gradle
settings.gradle
build.gradle
gradle.properties
settings.gradle
rootProject.name=MyService
include ‘Module1’, ‘Module2’
where i want to use these props in child module’s build.gradle files like below:
dependencies {
“mygroup:log4j2:$log4j2.version”
“mygroup:spring-core:$spring.version”
}
When building from root level, these variables are getting resolved and build is happening fine. But if we run at child module level by opening cmd prompt, it fails , as gradle unable to resolve those variables.
If i want to build only child module, i’m able to build like this in my local which resolves those variables:
gradle :Module1:build
But the problem i’m facing now is with Jenkins configuration where we configured each sub-project individually and whenever changes happens on child module, build is failing as it unable to find out those variables.
How to build the each sub-project individually in jenkins by resolving the properties? Or is there specific convention we need to follow for jenkins configuration for these kind of projects ?
Please note that we have various services like this and i cannot put gradle.properties at USER_HOME directory or gradle installation directories as dependencies might vary service to service. So it must be at service’s root level.
Can someone share experience how they configured multi-project builds in jenkins? i’m not able to figure out a way to do that especially when we have root gradle.properties with all the variables defined to be shared across sub-projects.
You would need to elaborate a bit more.
Even if you run the build with the submodule as working directory, they would still be part of the overall build and the properties would also be available.
So you probably do something non-standard or evil when configuing your Jenkins pipelines, but that is just guesswork without you providing more information.
Also this should not be Jenkins releated. I greatly prefer TeamCity which is like Jenkins just in good. But it shouldn’t really matter with which pipeline tool you run the build.
Thanks for the reply. Good to know that someone noticed my query. Anyways, below is my problem:
Till now though we have source code structure as shown in problem description, but we never used gradle mult-project build feature. We maintain and build modules individually, dependencies defined at each module level. This is causing dependencies inconsistency for a service which comprises of many modules. So i want to centralize the dependencies definition at service root level itself, which ultimately used by the child-modules (a.k.a sub-projects). Also, till now we have SVN post commit hook which triggers build in jenkins server whenver changes committed to respective modules and jars will be uploaded to artifactory which will be later used for deployment. We have multiple jenkins agents which take care of those builds, cannot guarantee same module will be picked up by same agent.
But with the gradle mult-project build settings, i’m unable to do that because 3p library versions defined at root service’s gradle.properties file and so while building only sub-project (when changes committed), gradle unable to find the variables used in individual sub-projects.
So with the multi-project build settings, is there a way to build sub-projects individually without checking out root’s gradle files.
Or in what way, we need to tweak jenkins build configuration, to achieve what i said ie., should be able to build modules individually without having complete service’s source code structure with all settings/gradle files at root. Because some services i have around 20 to 30 modules. So for every module commit i dont want to checkout whole service code to build my module.
In real world scenario, how this is handled ? What we are doing wrong here? What can be improved?
I cannot move to teamcity bcoz its not individual decision but at orgnization wide decision. Meanwhile, will explore on “version catalog” and im not sure whether it really solves my problem.
If your modules are individual, you should not combine them in a multi-project build.
A multi-project build is for a project that is always at least checked out together.
You should instead make the modules individual Gradle builds and then combine them to your services using composite builds feature.
To centralize the versions, you should have a look at version catalogs and / or platforms: Sharing dependency versions between projects. Those can also be published and then used in multiple builds, where “publishing” does not mean you really have to publish, but can also include them using composite build feature.
Thanks a lot for the inputs. I checked composite builds and version catalog. Version catalog is very much useful and moving towards using that feature. But composite builds is not i wanted.
Will make changes at jenkins configuration to checkout all the the sub-projects together even if i commit changes in one sub-project but will build only that sub-project. I guess this is much useful from both CI and Dev perspectives and also achieves in centralizing the dependencies using version-catalog.