This message was deleted.

Also looked at the module metadata spec and it mentions these values should be optional, so maybe there's a way to remove them? I'd be okay with fully removing

thirdPartyCompatibility

if it makes sense.

Imho this is a side-effect of that horrible publishing strategy that was chosen by JavaFX maintainers. It is for example also very hard to do cross-OS builds with JavaFX. At work we repackaged the whole JavaFX dependencies to make more sense. There is no official way I'm aware of to manipulate the Gradle module metadata like the

withXml

hack for POMs, but instead the modeling of the project should be fixed to produce the intended result, which should then also produce the correct POM without manipulation ..... in almost all cases. With JavaFX the problem is, that the JavaFX Gradle plugin you probably use - which also is not configuration-cache compatible -, configures those classified dependencies as dependencies, and so they end up in the GMM. Besides making JavaFX rething their publication strategy, which I would greatly welcome, I guess in that case you have to hook into the task that generates the GMM and add a

doLast

action to it, that does the manipulation you need.

@Vampire Thanks for your response, I don't know if I'll be able to change upstream JavaFX any time soon 😆. In regards to:

the JavaFX Gradle plugin you probably use - which also is not configuration-cache compatible

Are the alternatives here if I don't use the plugin? Let's say purely

implementation "org.openjfx:javafx-base:${javafxVersion}"
    implementation "org.openjfx:javafx-graphics:${javafxVersion}"
    implementation "org.openjfx:javafx-controls:${javafxVersion}"
    implementation "org.openjfx:javafx-swing:${javafxVersion}"

That's basically what I have on my build.gradle For your suggestion

hook into the task that generates the GMM and add a

doLast

action to it, that does the manipulation you need.

Is something like this what you had in mind (e.g. modify the json output)? Or are there other more official approaches I should follow here?

tasks.withType(GenerateModuleMetadata).configureEach {
    doLast { _ ->
        def gmmFile = it.outputFile.get().asFile
        def inJson = new JsonSlurper().parseText(gmmFile.text)
        def filteredVariant = inJson.variants.findAll { it.name == configurations.runtimeElements.name }
        // remove "thirdPartyCompatibility" from GMM
        filteredVariant.dependencies.first().each {
            if (it.group == 'org.openjfx') {
                it.remove('thirdPartyCompatibility')
            }
        }
        def outJson = JsonOutput.toJson(inJson)
        gmmFile.write(JsonOutput.prettyPrint(outJson))
    }
}

Are the alternatives here if I don't use the plugin?

Well, the JARs in those non-classified coordinates is empty, so you cannot compile or run against them if you are actually using JavaFX. You could maybe have those as

implementation

dependencies and manually add the classified dependency as

compileOnly

dependency so that your compilation works and manually add them to classpaths of any tasks that need them at runtime.

Is something like this what you had in mind (e.g. modify the json output)?

Without looking in-depth, yes.

Or are there other more official approaches I should follow here?

No, as far as I know there is not official "manipulate the GMM" facility as official stanza is to fix the modelling of the build so that the correct result is produced. You could open a feature request ticket to add such a facility with your use-case. Maybe they then add it or come up with some different way how to properly model it.

thank you so much