The best way to fix duplicate packages?

[stewue]

Thanks for providing such a great plugin to support Java Modules for libraries which do not properly support Java Modules. I have a question on that is the best solution for an issue which I already had serveral times.

In my project I have two (transitive) dependencies to org.apache.tomcat.embed:tomcat-embed-el and jakarta.el:jakarta.el-api. Both export the package jakarta.el. At the application startup I get errors such as module XXXXXXX reads package jakarta.el from both org.apache.tomcat.embed.el and jakarta.el. My current solution is to substitute the dependency jakarta.el:jakarta.el-api with org.apache.tomcat.embed:tomcat-embed-el. Additionally I must redefine the module definition for some other dependencies. I just simply copy the existing module info definition and replace requires jakarta.el with requires org.apache.tomcat.embed.el. It works but is a bit ugly as many lines are copied.

I also tried the removePackage(...) feature. If I use preserveExisting() and removePackage("jakarta.el") for org.apache.tomcat.embed.el, the package was removed but the export still exists. I still get the error above at the application startup.

Is there a better option which I missed?

[jjohannes]

Hey @stewue. Yes, this is a confusing topic. There are two topics involved here IMO, due to some (probably not so good) decisions in Jakarta and Tomcat wrt. naming and packaging things. I think you already figured things out, but to be sure we talk about the same things, here is what I think the issues are and what I would do:

Issue one: Two overlapping JARs

Essentially, the tomcat-embed-el.jar is a superset of the jakarta.el-api.jar. It includes all the API classes. So if you need tomcat-embed-el.jar for the additional classes, only that one should be added to the casspath or module path. jakarta.el-api.jar can be discarded. This is a problem that also exists without the Module System. I's just that Java does not complain about the duplication, but silently ignores class files, when running on the classpath.

Gradle is able to detect such conflicts and resolve them for you, if it has sufficient metadata for the libraries. In this case, metadata is insufficient, but you can use our other plugin jvm-dependency-conflict-resolution which enriches the metadata of many Maven Central libraries. It is missing the data for your case (it has data for javax.el:el-api vs jakarta.el:jakarta.el-api but not yet for tomcat-embed). I created and issue.

Still, you could use the plugin like this right now:

plugins {
    /*...*/
    id("org.gradlex.jvm-dependency-conflict-resolution")
}

jvmDependencyConflicts {
    // Enhance metadata of 'tomcat-embed-el' to express that it contains 'jakarta.el-api'
    // and thus is in conflict with it.
    // This patch rule qualifies to be added as general rule to a future release of
    // 'jvm-dependency-conflict-resolution' and can then be removed from the individual build setup.
    patch {
        module("org.apache.tomcat.embed:tomcat-embed-el") {
            addCapability("jakarta.el:jakarta.el-api")
        }
    }

    // If conflict occurs, select 'org.apache.tomcat.embed:tomcat-embed-el'.
    // (This is an individual conflict resolution decision that stays in your build.)
    conflictResolution {
        select("jakarta.el:jakarta.el-api", "org.apache.tomcat.embed:tomcat-embed-el")
    }
}

You wrote that you "substitute the dependency", which I assume is the above done by another Gradle mechanism. You can keep your current setup if it works. I just wanted to mention this as explanation.

Issue two: same package in two modules with different names

The approach of Tomcat ere to repackage the jakrata.el package directly clashes with the Module System and can cause further issues on top. If you follow the above suggestion, you probably get:

error: module not found: jakarta.el

This is, because some module has a requires jakarta.el; statement, which is now "wrong". With this plugin, you can rewrite the requires. I tried to find an example, but couldn't. The modules I found do requires static jakarta.el which then does not lead to the above error. Which modules do cause the error for you? In any case, the patching would look something like this:

extraJavaModuleInfo {
    module("group:artifact", "module.name") {
        patchRealModule()
        // preserveExisting() <- Can't use this, as it adds everything that is defined
        exportAllPackages()
        requires("...") // repeat all requires from real module-info and adjust what is needed
    }
}

Maybe this is what you are already doing. If you have a full example that shows a valid real-world uses case, we can think about adding some options to preserveExisting() that would allow you to use it, but exclude certain things from it. Feel free to open a separate issue for that with the example.

Alternative: make the two Jars no longer overlap

The removePackage may be a way to go, instead of doing the two things above, this would allow both Jars to stay on the module path. If it does not break functionality. But you are right, it does not remove the export so you would need to do this:

extraJavaModuleInfo {
    module("org.apache.tomcat.embed:tomcat-embed-el", "org.apache.tomcat.embed.el") {
        patchRealModule()
        // preserveExisting() // not possible because we need to remove export
        removePackage("jakarta.el") // <-- does not remove export

        // === COPIED FROM REAL module-info.class ===
        requires("java.desktop")
        // exports jakarta.el; <-- remove
        exports("org.apache.el")
        exports("org.apache.el.lang")
        exports("org.apache.el.parser")

        uses("jakarta.el.ExpressionFactory")

        // service providers are recreated from META-INF...
    }
}

I think we can consider that a bug. It makes no sense to remove the classes but keep the export: #219