Multi-module Gradle project - selectively managing dependencies in child modules - kotlin

Lets say I have a multi-module Gradle Kotlin project. The structure is as follows:
main - app runner + gluing everything together
modules
users
users-adapters
users-domain
orders
orders-adapters
orders-domain
Now - I wanted to be able to manage dependencies selectively. My intentions are:
3rd party libraries like Web library, SQL library, etc. are declared in their versions once, centrally (all modules use same versions of given library).
All domain modules are completely 3rd party agnostic. No 3rd party library should be available on classpath here.
All adapters modules should be able to receive all or choose selectively the 3rd party dependencies declared somewhere centrally.
I was thinking about subprojects {} declaration in root build.gradle.kts but this would impact all modules, while I want to leave domain ones untouched.
Is there a way so that I can have like:
one "global" dependencies list
one "for adapters" dependencies list
one "for domains" dependencies list
How to achieve this?

I have been experimenting with the hexagonal architecture with Gradle myself and
I have found the following setup working quite well for me.
(Please excuse for using the Kotlin DSL as I only have one repo to demo while
time of writing this answer).
To start off, here is the package structure I follow:
<project root>
| build.gradle.kts
| ...
└─── apps
| └─── <putting everything together>
| | build.gradle.kts
| | ...
└─── core
| └─── <business logic>
| | build.gradle.kts
| | ...
└─── libs
└─── <some common lib>
| build.gradle.kts
| ...
Let's focus on build.gradle.kts in project root:
plugins {
id("io.spring.dependency-management") version "1.0.12.RELEASE"
}
subprojects {
apply(plugin = "io.spring.dependency-management")
dependencyManagement {
dependencies {
dependency("ch.qos.logback:logback-classic:1.2.11")
dependency("org.javamoney:moneta:1.4.2")
dependency("nl.hiddewieringa:money-kotlin:1.0.1")
dependencySet("io.jsonwebtoken:0.11.5") {
entry("jjwt-api")
entry("jjwt-impl")
}
}
}
}
configure(subprojects) {
dependencies {
implementation("ch.qos.logback:logback-classic")
testImplementation(kotlin("test"))
}
tasks.test {
useJUnitPlatform()
}
}
Quick explanation,
I am using Spring IO's Gradle plugin which enables
declaration of packages and their version across projects in one place.
If you observe, I only apply this plugin across subprojects.
Now in the configuration, I keep common configs applicable to all the subprojects.
Let's jump to core -> build.gradle.kts:
dependencies {
api("nl.hiddewieringa:money-kotlin")
}
Here you can see the core only uses money-kotlin (Kotlin extensions for javax.money)
which is api only.
Note that since logger is defined in the configuration for the subproject, I can use that in core logic to define logs.
Also, versions are acquired from the ones mentioned in the main Gradle file.
Something similar would go for libs -> build.gradle.kts.
Finally apps -> build.gradle.kts looks like:
dependencies {
api("io.jsonwebtoken:jjwt-api")
api("nl.hiddewieringa:money-kotlin")
implementation("org.javamoney:moneta")
runtimeOnly("io.jsonwebtoken:jjwt-impl")
}
Here, I am applying the actual implementation of java-money using moneta (separating logic and api from actual impl).
Similarly, jjwt is only applied here.
This way, all the versions are controlled in a single place. Logic gets separated out of impl details.
As I see, this covers most things needed for hexagonal pattern.
Hope it helps.

Related

How do I encapsulate version management for gradle plugins?

Problem
I have a setup of various distinct repos/projects (i.e. app1, app2, app3) that all depend on shared functionality in my base package.
The projects also use various other third-party dependencies (i.e. app1 and app3 use spring, all of them use kotlinx-serialization).
I want to synchronise the versions of all third-party dependencies, so that any project using my base package uses the same version of every third-party dependency. However, I don't want to introduce new dependencies to projects that do not use them (i.e. app2 does not use spring)
Solution attempts
For libraries, I have been able to solve this with the help of a gradle platform, which does exactly what I want - I specify the versions in my base package, then add the platform as a dependency to my projects and can then simply add dependencies by name (i.e. implementation("org.springframework.boot:some-package")) without having to specify a version number, because it uses the provided value from my platform.
However, for plugins, I have not been able to do this. Many libraries come with plugins and naturally the plugin should be at the same version as the library. I have tried various approaches, including writing a standalone plugin, but none have worked.
Current best idea
I added implementation("org.springframework.boot:spring-boot-gradle-plugin:3.0.2") to the dependencies of my standalone plugin. Then, I added the following code to my standalone plugin:
class BasePlugin : Plugin<Project> {
override fun apply(target: Project) {
target.plugins.apply("org.springframework.boot")
}
}
This works and applies the plugin to my main project at the correct version. However, there are 2 major problems with this:
a) Now every project applies the spring plugin, including app2 (which does not use spring).
b) I have many plugins to manage and no idea how to get the long implementation-string for most of them. I found the "org.springframework.boot:spring-boot-gradle-plugin:3.0.2" by looking up the plugin-id on https://plugins.gradle.org/ and then looking at the legacy plugin application section, which sounds like I am on the wrong track.
I just want to manage the versions of plugins and libraries of multiple projects/repos in a central place - this feels like a fairly basic use case - why is this so hard?
There are some great and detailed answers about dependency management, but unfortunately none worked to perform cross-project version management for plugins.
It seems that there is no gradle functionality to do this, but I got it working with a bit of a workaround. Here is my (working) approach, in hope that it helps someone else with this:
Create a Standalone gradle Plugin
In the build.gradle.kts of the plugin, include the maven coordinates (not its ID) of every other plugin whose version you want to manage in any of your projects in the dependency block with the api keyword. i.e. api("org.springframework:spring-web:6.0.2")
In the main projects, remove every other plugin from the plugins block, so that your custom standalone plugin is the only one remaining.
Create a file (i.e. a plugins.json or whatever you want) in the project root directory of all main projects and in there supply the plugin IDs of the plugins that you actually intend to use in that project. Just the IDs, no version numbers, i.e. "org.springframework.boot" for Spring's plugin. (Keep in mind that for plugins declared as kotlin("abc") you will have to add the prefix "org.jetbrains.com.", as the kotlin method is just syntactic sugar for that)
In your plugin source code, in the overriden apply method, look for. a file named plugins.json (or whatever you chose) in the project.buildFile.parent directory (which will be the directory of the project using this plugin, NOT of the plugin itself). From this file, read the plugin IDs
for every pluginID in the file, call project.plugins.apply(id)
How/Why it works:
The main project build.gradle.kts is executed, looks at the plugin block and applies your standalone plugin (which is the only one), which calls its apply method.
This plugin then applies other plugins based on their ID from the file.
Normally, this will throw an error because these plugins are not found, but because we defined them as dependencies with the api keyword in our standalone plugin, they are now available on the classpath and in exactly the version of that import statement.
Hope it helps someone!
I use version numbers in a gradle.properties file for this purpose. Since the introduction of Gradle version catalogs, my approach is probably a bit out of date, but I'll share it here anyway. It's based on the fact that plugin versions can be managed in settings.gradle.kts by reading values from the properties file.
In gradle.properties:
springBootVersion=3.0.2
In settings.gradle.kts:
pluginManagement {
val springBootVersion: String by settings
plugins {
id("org.springframework.boot") version springBootVersion
}
}
And finally in build.gradle.kts:
plugins {
id("org.springframework.boot")
}
dependencies {
val springBootVersion: String by project
implementation(platform("org.springframework.boot:spring-boot-dependencies:$springBootVersion"))
}
Notice that the plugin version is omitted in the build script because it is already specified in the settings file.
And note also that the method for accessing the property in the settings script is slightly different from that in the build script.
a) Now every project applies the spring plugin, including app2 (which does not use spring).
It is indeed better to avoid applying too many plugins - and that's why Gradle encourages reacting to plugins.
import org.gradle.api.Plugin
import org.gradle.api.Project
import org.gradle.kotlin.dsl.*
import org.springframework.boot.gradle.plugin.SpringBootPlugin
class BasePlugin : Plugin<Project> {
override fun apply(target: Project) {
// don't apply
//target.plugins.apply("org.springframework.boot")
// instead, react!
target.plugins.withType<SpringBootPlugin>().configureEach {
// this configuration will only trigger if the project applies both
// BasePlugin *and* the Spring Boot pluging
}
// you can also react based on the plugin ID
target.pluginManager.withPlugin("org.springframework.boot") {
}
}
}
Using the class is convenient if you want to access the plugin, or the plugin's extension, in a typesafe manner.
You can find the Plugin's class by
looking in the source code for the class that implements Plugin<Project>,
in the plugin's build config for the implementationClass,
or in the published plugin JAR - in the META-INF/gradle-plugins directory there will be a file that has the implementationClass.
This doesn't help your version alignment problem - but I thought it was worth mentioning!
b) I have many plugins to manage and no idea how to get the long implementation-string for most of them. I found the "org.springframework.boot:spring-boot-gradle-plugin:3.0.2" by looking up the plugin-id on https://plugins.gradle.org/ and then looking at the legacy plugin application section, which sounds like I am on the wrong track.
You're on the right track with the "long implementation string" as you call it. I'll refer to those as the 'Maven coordinates' of the plugin.
Gradle Plugin Maven Coordinates
The plugin id of the Kotlin JVM plugin is org.jetbrains.kotlin.jvm, but the Maven coordinates are org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.0 .
The 'legacy' part refers to how the plugins are applied, using the apply(plugin = "...") syntax. The new way uses the plugin {} block, but under the hood, both methods still use the Maven coordinates of the plugin.
If you add those Maven coordinates (with versions) to your Java Platform, then you can import the platform into your project. But where?
Defining plugin versions
There are a lot of ways to define plugins, so I'll only describe one, and coincidentally it will be compatible with defining the version using a Java Platform.
If you're familiar with buildSrc convention plugins, you'll know that they can apply plugins, but they can't define versions.
// ./buildSrc/src/main/kotlin/kotlin-jvm-convention.gradle.kts
plugins {
kotlin("jvm") version "1.8.0" // error: pre-compiled script plugins can't set plugin versions!
}
Instead, plugin versions must be defined in the build config for buildSrc
// ./buildSrc/build.gradle.kts
plugins {
`kotlin-dsl`
}
dependencies {
// the Maven coordinates of the Kotlin JVM plugin - including the version
implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.0")
}
This looks a lot more traditional, and so I hope the next step is clean: use your Java Platform!
Applying a Java Platform to buildSrc
// ./buildSrc/build.gradle.kts
plugins {
`kotlin-dsl`
}
dependencies {
// import your Java Platform
implementation(platform("my.group:my-platform:1.2.3"))
// no version necessary - it will be supplied by my.group:my-platform
implementation("org.jetbrains.kotlin:kotlin-gradle-plugin")
}
Note that this same method will also apply if your projects an 'included build' instead of buildSrc.
Once the plugin versions are defined in ./buildSrc/build.gradle.kts, you can use them throughout your project (whether in convention plugins, or in subprojects), they will be aligned.
// ./subproject-alpha/build.gradle.kts
plugins {
kotlin("jvm") // no version here - it's defined in buildSrc/build.gradle.kts
}

Multi-project Gradle+Kotlin: How to create Jar containing all sub-projects using Kotlin DSL?

I have a Gradle project with two subprojects. The parent does not contain any code; all the Kotlin code is in the two subprojects. All Gradle build files are defined in the Kotlin DSL.
Upon building, Gradle generates two JAR files, one in the build subfolder of each subproject. I believe this is the intended default behavior of Gradle. But this is not what I want.
I want to publish the JAR file of the parent project as a Maven artifact. Therefore, I need both subprojects to be included in one JAR file. How can I achieve this?
Note: On this web page, the author seems to achieve pretty much what I would need in this code snippet:
apply plugin: "java"
subprojects.each { subproject -> evaluationDependsOn(subproject.path)}
task allJar(type: Jar, dependsOn: subprojects.jar) {
baseName = 'multiproject-test'
subprojects.each { subproject ->
from subproject.configurations.archives.allArtifacts.files.collect {
zipTree(it)
}
}
}
artifacts {
archives allJar
}
However, this is defined in Gradle's native Groovy DSL. And I find myself unable to translate it into the Kotlin DSL. I tried to put a Groovy build file (*.gradle) besides the Kotlin build file (*.gradle.kts), but this led to a strange build error. I'm not sure if mixed build file languages are supported. Besides, I would consider it bad practice too. Better only define all build files in just one language.
Also, the example above pertains to the Java programming language. But I do not expect this to be a big problem, as both Java and Kotlin produce JVM bytecode as compile output.
More clarification:
I am not talking about a "fat JAR". Dependencies and the Kotlin library are not supposed to be included in the JAR.
I do not care if the JAR files for the subprojects are still getting built or not. I'm only interested in the integrated JAR that contains both subprojects.
The main point is getting the combined JAR for the binaries. Combined JARs for the sources and JavaDoc would be a nice-to-have, but are not strictly required.
I would use the Gradle guide Creating "uber" or "fat" JARs from the Gradle documentation as a basis. What you want is essentially the same thing. It's also much better than the Groovy example you found, as it doesn't use the discouraged subprojects util, or 'simple sharing' that requires knowing how the other projects are configured.
Create a configuration for resolving other projects.
// build.gradle.kts
val mergedJar by configurations.creating<Configuration> {
// we're going to resolve this config here, in this project
isCanBeResolved = true
// this configuration will not be consumed by other projects
isCanBeConsumed = false
// don't make this visible to other projects
isVisible = false
}
Use the new configuration to add dependencies on the projects we want to add into our combined Jar
dependencies {
mergedJar(project(":my-subproject-alpha"))
mergedJar(project(":my-subproject-beta"))
}
Now copy the guide from the docs, except instead of using configurations.runtimeClasspath we can use the mergedJar configuration, which will only create the subprojects we specified.
However we need to make some modifications.
I've adjusted the example to edit the existing Jar task rather than creating a new 'fatJar' task.
for some reason, setting isTransitive = false causes Gradle to fail resolution. Instead I've added a filter (it.path.contains(rootDir.path)) to make sure the Jars we're consuming are inside the project.
tasks.jar {
dependsOn(mergedJar)
from({
mergedJar
.filter {
it.name.endsWith("jar") && it.path.contains(rootDir.path)
}
.map {
logger.lifecycle("depending on $it")
zipTree(it)
}
})
}

Skeleton for Kotlin/native multiproject with dll library for backend and frontend app using it

I'm trying to create a multiproject using Kotlin/native and gradle in IDEA that consists of:
A backend subproject library. I want to use this library in frontend Kotlin app and also produce a native DLL that can be later used in other software. I doubt I'll need any platform specific behavior -- the most I'll interact with the system is read, write and watch a file for changes.
A frontend jvm app in Kotlin using this library as required dependency. To be more precise I'm going to write a glfw app in Kotlin that will use this lib, but that's a detail you don't have to bother with.
I want to be able to:
build DLL on it's own
build an app that depends on library and rebuilds if needed when the lib changed.
I made a hyperlink trip over gradle docs, JetBrains examples and repos but I don't quite understand how to make a multiproject like that. Can someone provide a minimal working example of such a Hello World project?
Right now this works for me in the initial stage of the project:
Use gradle init with basic type and kotlin DSL to generate a wrapper project
Add 2 modules with New > Module > Gradle > Kotlin/Multiplatform and Kotlin/JVM. That should add include("...") entries to root settings.gradle.kts At this point those modules will be empty with a single build.gradle.kts scripts
Root build.gradle.kts can be deleted - both library and app use their own
In the Multiplatform library setup at least one target for example like that:
// rootProject/library/build.gradle.kts
// ...
kotlin {
jvm() // used by jvm app
sourceSets { /*...*/ }
}
Now there should be no gradle errors and IDEA will detect the project properly - refresh gradle configuration (CTRL+SHIFT+O)
Create source directories for each module (because the modules rn): IDEA should hint the names of corresponding source sets (src/<target>/<kotlin|resources> etc.)
So now just to link the app and library together in the the app's buildscript add the implementation(project(":library")) dependency
Of course don't forget to configure the library target for example using linuxX64("native") { binaries { sharedLib {/*...*/ } } } block in kotlin plugin when trying to generate a DLL
Now it should mostly work. The structure of a project I'm working on rn looks like that:

How configure a gradle multi-module project?

I have a 3 microservices and now i need to create a docker-compose for all of it. So when i trying to fellow all my microservices in one project i get this issue
Project directory 'C:\Users\Dany\IdeaProjects\target-root\target-discovery\app' is not part of the build defined by settings file 'C:\Users\Dany\IdeaProjects\target-root\settings.gradle.kts'. If this is an unrelated build, it must have its own settings file.
What i have to read for fix it?
setting.gradle.kts
project structure
The include in settings.gradle.kts should look like:
include(
":target-discovery"
)
in case there are more sub-folders (e.g. target-discovery/app, target-discovery/app2):
include(
":target-discovery:app",
":target-discovery:app2"
)
When defining a module it should always start with : and sub-folders should be delimited by :
Also make sure your root build.gradle.kts define all relevant plugins or define them in each sub-module. You can also create conventions (https://docs.gradle.org/current/samples/sample_convention_plugins.html)
If you just define plugins in the root it wont affect your sub-projects, one way to achive it (altough i prefer convention plugins) is:
build.gradle.kts
plugins {
kotlin("jvm") version ...
}
subprojects {
apply(plugin = "kotlin")
}
As Tom said, what you need to include isn't target-discovery but target-discovery/app
However, projects included in settings.gradle (or settings.gradle.kts) don't start with the colon symbol, so you should have:
settings.gradle.kts
rootProject.name = "target-root"
include("target-discovery:app")

Is There A Way To Create A Joint Intellij Project Spanning Multiple Gradle Projects As Modules

So it actually seems to mostly work, with both projects as sub-modules of the overall project. But the major annoyance is that when I debug in one of the modules, if code calls something in the other module it picks up the dependency from the Gradle cache instead of the other project/module's code and steps into a decompiled .class file from its cache instead of the actual source code.
I'd like to find a way so Intellij recognizes one module is using the other and uses the source code from the module itself which is of course checked out and available in the local filesystem.
See gradle documentation here about setting up multiple projects as "sub-modules", though gradle lingo usually refers to them as sub-projects.
Basically, if you have some projects that are sub projects of a root project, you would setup the folder structure like this:
root
├───build.gradle
├───settings.gradle
│
├───subA
│ └───build.gradle
├───subB
│ └───build.gradle
└───subC
└───build.gradle
In your root settings.gradle, you include your sub projects by adding:
include 'subA', 'subB', 'subC'
From this point on, you can refer to any project in your setup from any other project by its name: project(':subB')
so If you want to add subC as a compile time dependency of subA, in subA's build.gradle, you would have:
dependencies{
compile project(':subC')
}
Declared this way, the dependency is on the current files of subC instead of the last built/installed binaries from the repository. You could also have root project just a holder project with no code of its own.
I've had some success using dependency substitution in a development mode kinda like this:
if (project.has("devMode")) {
configurations.all {
resolutionStrategy.dependencySubstitution {
substitute module("foo.group:bar") with project(":bar")
}
}
}
Hopefully something like that may work for you, too.
EDIT: note that you'll also have to conditionally add the :bar project in settings.gradle as well