The mogodb-driver-legacy jar is not intended to include an Automatic-Module-Name in its MANIFEST.MF, but it does. The reason it should not is because it is not a valid Java module. One of the rules for modules is that the classes in any given package can not be split among multiple modules, and due to the way that packages were structured since the beginning of the driver, we had no choice but to split the "com.mongodb" package between mongodb-driver-core and mongodb-driver-legacy. That's because many of the classes that are used by the non-legacy API, e.g. com.mongodb.ReadPreference, are in the core mongodb-driver-core, while many of the legacy API classes, like com.mongodb.DBCollection are in the mongodb-driver-legacy jar.
See section 2.3 of The State of the Module System for a more rigorous explanation of the restrictions on splitting packages across multiple modules:
The module system ensures that every dependence is fulfilled by precisely one other module, that the module graph is acyclic, that every module reads at most one module defining a given package, and that modules defining identically-named packages do not interfere with each other.
That's why the build.gradle for driver-legacy doesn't specify an automatic module name. Compare that, for example to the build.gradle for driver-sync, which does.
However, in publish.gradle we incorrectly specify a default Automatic-Module-Name for all jar files, and that's why mongdb-driver-legacy is ending up with one in its MANIFEST. And to add insult to injury, it's using the archiveBaseName as the name, and the archiveBaseName is not even a valid module name (since it contains dashes).
We should remove this configuration from publish.gradle and rely on each jar to specify its own Automatic-Module-Name, and in the case of the legacy jar, not specify one at all.
- related to
-
JAVA-3566 Resolve difference in META-INF/MANIFEST.MF files between 3.x and 4.x
- Closed