You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
*[#31](https://github.com/gradlex-org/java-module-dependencies/issues/31) DSL for module dependencies that cannot be defined in module-info
5
+
3
6
## Version 1.3.1
4
7
5
8
* Fix integration with analysis plugin if root projects are involved
Copy file name to clipboardExpand all lines: README.MD
+46-24Lines changed: 46 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -84,6 +84,32 @@ module org.example.mymodule {
84
84
85
85
Note that `requires /*runtime*/` is a directive specifically supported by this plugin to allow the specification of _runtime only_ dependencies.
86
86
87
+
## Define additional module dependencies in build files
88
+
89
+
With this plugin you move dependency definitions into `module-info.java` files and no longer use the `dependencies {}` block in build files.
90
+
However, there are certain dependency "scopes" not supported by the `module-info.java` syntax.
91
+
For this, the plugin offers an extension of Gradle's DSL to be used in `build.gradle(.kts)` files.
92
+
93
+
```
94
+
mainModuleInfo {
95
+
runtimeOnly("org.slf4j.simple") // runtime only dependency for the 'main' module
96
+
annotationProcessor("dagger.compiler") // annotation processor dependency for the 'main' module
97
+
}
98
+
```
99
+
100
+
For modules in other source sets, there are corresponding blocks to define dependencies if needed – e.g. `testFixturesModuleInfo {}`.
101
+
102
+
In case a source set does **not** contain a `module-info.java`, all dependencies can be defined in the `build.gradle(.kts)` files.
103
+
The only case where this should be used is for whitebox testing activated via the [org.gradlex.java-module-testing](https://github.com/gradlex-org/java-module-testing) plugin.
104
+
105
+
```
106
+
testModuleInfo {
107
+
requires("org.assertj.core")
108
+
requires("org.hamcrest")
109
+
requires("org.junit.jupiter.api")
110
+
}
111
+
```
112
+
87
113
## Add Module Name mapping information (if needed)
88
114
89
115
You may define additional mappings from _Module Name_ to _group:name (GA) coordinates_.
@@ -98,7 +124,6 @@ You can define additional entries (or overwrite entries from the plugin) as foll
@@ -124,7 +149,8 @@ If you have a `prefixOfYourChoice`, all your Modules **need to have the same pre
124
149
## Define Module versions in a Platform project as Dependency Constraints
125
150
126
151
Use Gradle's dependency constraints and/or platforms to define versions for the modules you depend on.
127
-
Inside a `javaModuleDependencies { }` block, you can use the `gav("module.name", "1.0")` notation to define a version by Module Name instead of coordinates.
152
+
For that the plugin offers a `moduleInfo { }` block in `java-platform` projects.
153
+
In that block, you have the `version("module.name", "1.0")` notation to define a version by Module Name instead of coordinates.
128
154
For libraries that consist of multiple components and have a BOM for version management, you might prefer to include the BOM, which you need to do by coordinates, because a BOM does not have a Module Name.
129
155
130
156
```
@@ -134,12 +160,10 @@ plugins {
134
160
}
135
161
136
162
// Define versions for Modules via the Module Name
137
-
dependencies.constraints {
138
-
javaModuleDependencies {
139
-
api(gav("org.apache.xmlbeans", "5.0.1"))
140
-
api(gav("org.slf4j", "1.7.28"))
141
-
api(gav("org.slf4j.simple", "1.7.28"))
142
-
}
163
+
moduleInfo {
164
+
version("org.apache.xmlbeans", "5.0.1")
165
+
version("org.slf4j", "2.0.7")
166
+
version("org.slf4j.simple", "2.0.7")
143
167
}
144
168
145
169
// Use BOMs for Modules that are part of a library of multiple Modules
0 commit comments