Skip to content

Commit bdf717a

Browse files
authored
Migration notes from 0.0.14 to 0.1.0 (#154)
* Migration notes from 0.0.14 to 0.1.0 * docs: suggestion improvements * docs: remove trailing ## * docs: mention new classpath/module path behavior * docs: expand migration docs on variant problems * docs: split migration into sub sections * docs: move before/after to before note on extra-java-module-info plugin * docs: incorporating suggestions * docs: incorporating suggestions * docs: add notes on dependency hierarchy changes * docs: typo fix
1 parent 1500398 commit bdf717a

File tree

1 file changed

+123
-1
lines changed

1 file changed

+123
-1
lines changed

README.md

+123-1
Original file line numberDiff line numberDiff line change
@@ -199,9 +199,131 @@ javafx {
199199
}
200200
</code></pre>
201201

202-
## Issues and Contributions ##
202+
## Issues and Contributions
203203

204204
Issues can be reported to the [Issue tracker](https://github.com/openjfx/javafx-gradle-plugin/issues/).
205205

206206
Contributions can be submitted via [Pull requests](https://github.com/openjfx/javafx-gradle-plugin/pulls/),
207207
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

Comments
 (0)