@@ -199,9 +199,131 @@ javafx {
199
199
}
200
200
</code ></pre >
201
201
202
- ## Issues and Contributions ##
202
+ ## Issues and Contributions
203
203
204
204
Issues can be reported to the [ Issue tracker] ( https://github.com/openjfx/javafx-gradle-plugin/issues/ ) .
205
205
206
206
Contributions can be submitted via [ Pull requests] ( https://github.com/openjfx/javafx-gradle-plugin/pulls/ ) ,
207
207
providing you have signed the [ Gluon Individual Contributor License Agreement (CLA)] ( https://cla.gluonhq.com/ ) .
208
+
209
+ ## Migrating from 0.0.14 to 0.1.0
210
+
211
+ Version ` 0.1.0 ` introduced several changes and improvements, including lazy dependency declaration,
212
+ variant-aware dependency management, and support for Gradle's built-in JPMS functionality. In the
213
+ previous version, the classpath/module path was rewritten. This is no longer the case. As a result,
214
+ your past builds might be affected when you upgrade the plugin. In the next section, there are a few
215
+ troubleshooting steps that might help with the transition if you encounter issues when upgrading.
216
+ These examples are provided on a best-effort basis, but feel free to open an issue if you believe
217
+ there's a migration scenario not covered here that should be included.
218
+
219
+ ### Troubleshooting
220
+
221
+ #### Gradle version
222
+
223
+ The plugin now requires ` Gradle 6.1 ` or higher. Consider updating your Gradle settings, wrapper,
224
+ and build to a more recent version of Gradle. Additionally, updating your plugins and dependencies
225
+ can help minimize issues with the plugin.
226
+
227
+ #### Mixed JavaFX jars
228
+
229
+ If you encounter mixed classified JavaFX jars or see errors like `Error initializing QuantumRenderer: no
230
+ suitable pipeline found` during executing task like ` build` , ` test` , ` assemble`, etc., it is likely one
231
+ or more of your dependencies have published metadata that includes JavaFX dependencies with classifiers.
232
+ The ideal solution is to reach out to library authors to update their JavaFX plugin and publish a patch
233
+ with fixed metadata. A fallback solution to this is to ` exclude group: 'org.openjfx' ` on the dependencies
234
+ causing the issue.
235
+
236
+ ``` groovy
237
+ implementation('com.example.fx:foo:1.0.0') {
238
+ exclude group: 'org.openjfx', module: '*'
239
+ }
240
+ ```
241
+
242
+ #### Variants
243
+
244
+ If you encounter errors such as ` Cannot choose between the following variants of org.openjfx... ` it is possible
245
+ that your build or another plugin is interacting with the classpath/module path in a way that "breaks" functionality
246
+ provided by this plugin. In such cases, you may need to re-declare the variants yourself as described in [ Gradle docs
247
+ on attribute matching/variants] ( https://docs.gradle.org/current/userguide/variant_attributes.html ) or reach out to
248
+ the plugin author in an attempt to remediate the situation.
249
+
250
+ ``` groovy
251
+ // Approach 1: Explicit Variant
252
+ // The following snippet will let you add attributes for linux and x86_64 to a configuration
253
+ configurations.someConfiguration {
254
+ attributes {
255
+ attribute(Usage.USAGE_ATTRIBUTE, objects.named(Usage, Usage.JAVA_RUNTIME))
256
+ attribute(OperatingSystemFamily.OPERATING_SYSTEM_ATTRIBUTE, objects.named(OperatingSystemFamily, "linux"))
257
+ attribute(MachineArchitecture.ARCHITECTURE_ATTRIBUTE, objects.named(MachineArchitecture, "x86-64"))
258
+ }
259
+ }
260
+
261
+ // Approach 2: Copy existing configuration into another configuration
262
+ configurations.someConfiguration {
263
+ def runtimeAttributes = configurations.runtimeClasspath.attributes
264
+ runtimeAttributes.keySet().each { key ->
265
+ attributes.attribute(key, runtimeAttributes.getAttribute(key))
266
+ }
267
+ }
268
+ ```
269
+
270
+ #### Extra plugins
271
+
272
+ In versions ` 0.0.14 ` and below, there was a transitive dependency on ` org.javamodularity.moduleplugin ` .
273
+ If your ** modular** project stops working after updating to ` 0.1.0 ` or above, it is likely that you need to
274
+ explicitly add the [ org.javamodularity.moduleplugin] ( https://plugins.gradle.org/plugin/org.javamodularity.moduleplugin )
275
+ back to your build and set ` java.modularity.inferModulePath.set(false) ` to keep things working as they were.
276
+ This plugin helped with transitive dependencies on legacy jars that haven't been modularized yet, but now you
277
+ have to option choose which approach to take. This change should not be required for non-modular projects.
278
+
279
+ ** Before**
280
+
281
+ ```` groovy
282
+ plugins {
283
+ id 'org.openjfx.javafxplugin' version '0.0.14'
284
+ }
285
+ ````
286
+
287
+ ** After**
288
+
289
+ ```` groovy
290
+ plugins {
291
+ id 'org.openjfx.javafxplugin' version '0.1.0'
292
+ id 'org.javamodularity.moduleplugin' version '1.8.12'
293
+ }
294
+
295
+ java {
296
+ modularity.inferModulePath.set(false)
297
+ }
298
+ ````
299
+
300
+ ** Note** : There are other recommended alternatives over ` org.javamodularity.moduleplugin ` for modular projects such as
301
+ [ extra-java-module-info] ( https://github.com/gradlex-org/extra-java-module-info ) that would allow you to keep
302
+ ` inferModulePath ` set to ** true** by declaring missing module information from legacy jars. More details on how to
303
+ accomplish can be found on the plugin's source code repository.
304
+
305
+ #### Dependency hierarchy
306
+
307
+ Version ` 0.1.0 ` now relies on JavaFX modules defining their transitive modules rather than flattening them.
308
+ This change allows you to publish metadata declaring only the JavaFX modules you need, meaning it does not
309
+ include transitive JavaFX modules as part of your published metadata.
310
+
311
+ Some plugins rely on having all modules (transitive included) declared as "top-level" modules such as the
312
+ ` badass-runtime-plugin ` on ** non-modular** projects. In this particular case, it is necessary to declare
313
+ all modules to restore previous functionality from ` 0.0.14 ` and below.
314
+
315
+ ** Before**
316
+
317
+ ```` groovy
318
+ javafx {
319
+ modules = ['javafx.controls']
320
+ }
321
+ ````
322
+
323
+ ** After**
324
+
325
+ ```` groovy
326
+ javafx {
327
+ modules = ['javafx.base', 'javafx.graphics', 'javafx.controls']
328
+ }
329
+ ````
0 commit comments