When performing a jdeps analysis on bootstrap.jar in master we can see that there are two classes missing. > tomcat]$ jdeps -v -cp output/build/bin/tomcat-juli.jar output/build/bin/bootstrap.jar | grep "not found" > bootstrap.jar -> not found > org.apache.catalina.startup.Bootstrap -> org.apache.catalina.Globals not found > org.apache.catalina.startup.Tool -> org.apache.catalina.Globals not found > org.apache.catalina.startup.Tool -> org.apache.tomcat.util.ExceptionUtils not found The effective result of this is that when calculating either the OSGi or JPMS metadata these packages want to be imported. Since several other classes are cherry-picked into the jar it stands to reason that the assembly should be logically complete as to never encounter any hard to diagnose errors.
https://github.com/apache/tomcat/pull/296
This issue was discussed on list and determined that if the missing parts being small and benign enough to copy into bootstrap, that might be the best solution as proposed by @markt: > If we created o.a.c.startup.Constants, defined the constants required by > the bootstrap classes there and then referenced those from o.a.c.Globals > would that help? It did! > Is it Tool's use of ExceptionUtils that is causing that class to be > needed? If so would making Bootstrap.handleThrowable() package private > and using that instead help? It does! I've tested these changed and they solve the packaging issue for both OSGi and JPMS. PR update coming.
The outcome is essentially that both in usage and now in terms of real java dependencies, bootstrap has no dependencies outside of java.base and tomcat-juli.jar
Thanks for the PRs. Fixed in: - master for 10.0.0-M7 onwards - 9.0.x for 9.0.37 onwards - 8.5.x for 8.5.57 onwards Note that I back-ported this to 8.5.x even though 8.5.x doesn't use bnd to keep the code in sync for easier back-ports of future fixes.