I think the last option is maybe the target: modularize tomcat properly. The people willing to have as few as possible modules would just use a new "bundle" module (this is what we do at openjpa, tomee, meecrowave etc) which provides a bundle way of building apps but is not flexible. So regarding JPMS I think it is either being really modular or not being modular since the in between state leads to unsatisfied people and the biggest constraints come from JPMS. Is it something targettable or do you think it is too much work?
side note: fine for me if it targets only 10.1. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 15 sept. 2021 à 11:17, Mark Thomas <ma...@apache.org> a écrit : > On 15/09/2021 08:34, Romain Manni-Bucau wrote: > > Hi all, > > > > I was trying to strim down a JDK, all was smooth until I started to work > > with Tomcat. > > I am assuming this is with embedded. > > > The issues I hit: > > > > - Tomcat is designed to be fully used with JPMS whereas I would like to > be > > able to use it in the CP if a jlink custom distro (without > forking/patching > > tomcat jar indeed) > > - module-info use "requires" and no optional dependent modules which lead > > to way too much dependencies (open the module-info from tomcat-catalina > for > > ex) > > > > Indeed there are always workaround and way to achieve what I wanted but I > > think the JPMS deliveries of Tomat are not friendly so think it is worth > > thinking about: > > > > 1. dropping it > > Not an option as we have users that have requested it. > > > 2. making it optional (I assume it can be released in jars with > classifiers > > only) > > Maybe, but it adds a bunch of artefacts. > > > 3. making it more accurate - but this highly depends how the user > consumes > > it (in particular for tomcat embed flavor) > > I think a variation of this is the way to go. > > Looking at the list of dependencies, I suspect most of them can be made > optional. That involves fine-tuning the bnd configuration files. > > That does raise the question what we do when a user tries to use the > optional features. I think we need to: > - identify those Tomcat features that depend on optional modules > - add a check for the presence of the module before using the feature > and log an appropriate error message if the module is missing. > > Splitting embedded into lots of little modules where all the > dependencies are correctly declared is another solution but we have > users that have requested we provide Tomcat in as few JARs as possible. > > I think we are approaching "can't please all of the people, all of the > time" territory here. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
