Bug 63555 - embedded jar manifests missing automatic module names
Summary: embedded jar manifests missing automatic module names
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Packaging (show other bugs)
Version: 9.0.x
Hardware: All All
: P2 minor (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2019-07-08 17:21 UTC by Rob
Modified: 2019-07-26 15:24 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Rob 2019-07-08 17:21:52 UTC
I'm happy to report that Tomcat 9 has been working reliably embedded in a project using the Java 9+ module system over the past year. However, the embedded jars do not provide the Automatic-Module-Name entry in their MANIFEST.MF files. The result is that maven generates warnings -- and valid warnings -- that the module names are unstable. For example:

* Required filename-based automodules detected: [tomcat-embed-el-9.0.21.jar]. Please don't publish this project to a public artifact repository! *

This limits downstream open sources projects from using tomcat, which should heed this warning, and may create incompatibilities in future if the jar file names change.

The affected maven modules are those in the org.apache.tomcat.embed group which may be referenced from an embedded application, as well as some related jars such as tomcat-jdbc which can be used embedded:


An obvious solution would be to put Automatic-Module-Names in each of these jars at build time, to match maven's fallback filename-based automodule names. That is to say, replace the hyphens with periods:

Automatic-Module-Name: tomcat.embed.websocket

With this approach, the Maven warning is resolved, and the existing filename-based automatic module names become stable.

But there is a question of whether the embedded packaging should really include the word "embed", when some of these jars are a repackaging of the code from the tomcat webapp server packages. Alternative module names might make more sense, and provide better compatibility with the non-embedded version of tomcat if Tomcat is ever made fully modular. Example: tomcat-embed-websocket would perhaps be better as "tomcat.websocket", and tomcat-embed-el would be "apache.el" or "org.apache.el" as internally it doesn't reference tomcat... And so on.

If taking this approach, which I can entirely appreciate, then I think implementing it sooner rather than later would be wise. The long filename-based automatic modules are relied upon, the more projects may come to rely incorrectly upon the unstable filename-based naming, and break in future.

An example of a similar issue as resolved in other popular open source projects: https://github.com/FasterXML/jackson-core/issues/397
Comment 1 Mark Thomas 2019-07-25 16:16:22 UTC
I'm exploring if it is possible to get bnd to do this for us in the same way it generates OSGi metadata.
Comment 2 Mark Thomas 2019-07-26 13:31:14 UTC
The feature that implements this in bnd isn't in a released version yet. There are also a number of open questions:
- What requirements will Jakarta EE add around JPMS in future versions?
- If Tomcat provides a spec JAR (e.g. Servlet spec) should it use the same JPMS name as the Jakarta EE provide JAR or a different one?
- How to handle the fact that some Tomcat JARs - e.g. bootstrap.jar - break the packaging rules JPMS expects?

Given all of the above, I have added Automatic-Module-Name entries for all the Tomcat controlled JARs in the embedded distribution but have deliberately not added names for the other JARs to see how the above issues play out first.

This has been fixed in master for 9.0.23 onwards.
Comment 3 Raymond Augé 2019-07-26 15:24:18 UTC
When you get back to this let me know if I can help with bnd.