Export same package to two modules errors

[koppor]

I am experimenting with this plugin to replace java9-modularity plugin.

I tried:

    module("org.openjfx:javafx-controls", "org.jabref") {
        exports("com.sun.javafx.scene.control")
        opens("javafx.scene.control", "com.sun.javafx.scene.control", "javafx.scene.control.skin")
        patchRealModule()
        preserveExisting()
    }
    module("org.openjfx:javafx-controls", "org.controlsfx.controls") {
        exports("com.sun.javafx.scene.control") // already done for org.jabref
        exports("com.sun.javafx.scene.control.behavior")
        exports("com.sun.javafx.scene.control.inputmap")
        opens("javafx.scene")
        patchRealModule()
        preserveExisting()
    }

I get

Error occurred during initialization of boot layer
java.lang.module.FindException: Error reading module: C:\Users\koppor\.gradle\caches\8.14\transforms\80abc631dd58aa95aae8dfa0745697fd\transformed\javafx-controls-24-win-module.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Exported package com.sun.javafx.scene.control already declared

Could not write standard input to Gradle Test Executor 9.
java.io.IOException: The pipe is being closed

It seems, I cannot export a package to different modules?

[jjohannes]

I think there is a misunderstanding in how use the plugin DSL. It is primarily designed to patch JARs that do not have a Module Name yet. Hence you have to give it the Group-Name-Coordinates (first argument) and the Module Name (second argument) for the module to patch. For a JAR that already is a Module, you should stick to the existing Name. For example:

// 'javafx.controls' already is a module, but we need to expose some more internals; hence we patch it here
module("org.openjfx:javafx-controls", "javafx.controls") {
  preserveExisting() // implies  patchRealModule()
  exports("com.sun.javafx.scene.control")
  opens("javafx.scene.control", "com.sun.javafx.scene.control", "javafx.scene.control.skin")    
}

You normally do not mention modules from your own code base in the patching rules (such as org.jabref in your case).

[koppor]

Not sure how to use the DSL:

---

Variant 1

    module("org.controlsfx:controlsfx", "controlsfx") {
        preserveExisting()
        opens("impl.org.controlsfx.skin")
        // exports("impl.org.controlsfx.skin")
    }

 C:\git-repositories\jabref-all\jabref\jabgui\src\main\java\org\jabref\gui\search\GlobalSearchBar.java:68: error: package impl.org.controlsfx.skin is not visible
  import impl.org.controlsfx.skin.AutoCompletePopup;
                            ^
    (package impl.org.controlsfx.skin is declared in module org.controlsfx.controls, which does not export it to module org.jabref)

---

Variant 2

    module("org.controlsfx:controlsfx", "controlsfx") {
        preserveExisting()
        opens("impl.org.controlsfx.skin")
        exports("impl.org.controlsfx.skin")
    }

Error occurred during initialization of boot layer
java.lang.module.FindException: Error reading module: C:\Users\koppor\.gradle\caches\8.14\transforms\8ebdeec005bbf648e42b9722750bbd99\transformed\controlsfx-11.2.2-module.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Exported package impl.org.controlsfx.skin already declared

---

Not sure, how to proceed.

[jjohannes]

This is a missing feature (or a bug...). At the moment, you can't do preserveExisting() and then change an existing exports entry. It is a feature we can add.

Right now what you can do is rewrite the complete module-info.

// Based on module-info.class in https://repo1.maven.org/maven2/org/controlsfx/controlsfx/11.2.2/
module("org.openjfx:javafx-controls", "org.controlsfx.controls") {
    patchRealModule()

    exportAllPackages() // shortcut to just export everything, can be replaced with a dedicated list
    
    opens("org.controlsfx.control", "org.controlsfx.fxsampler")
    opens("org.controlsfx.control.tableview2", "org.controlsfx.fxsampler");

    uses("org.controlsfx.glyphfont.GlyphFont");

    // Automatically reconstructed from META-INF
    // provides org.controlsfx.glyphfont.GlyphFont with org.controlsfx.glyphfont.FontAwesome;
}

[koppor]

The new issue #179 is more precise. And there is a workaround...