This can totally be fixed in configuration. There is no problem. I just wanted to make sure that in doing so we wouldn't just be pushing some dirt under the rug so to speak.
:) - Ray On Thu, Jun 11, 2020 at 3:25 PM Raymond Auge <raymond.a...@liferay.com> wrote: > To be clear, it's not necessarily having _all of a package_. It's more > about all the reachable class references. For instance jdeps looks at > classes and finds any reachable references. So does bnd for calculating > OSGi metadata. > > So the issue is not really about packages, it's about having missing class > references and whether those should be elided in configuration, or simple > fixed in packaging (which again does not necessarily mean full packages :) > > - Ray > > On Thu, Jun 11, 2020 at 3:20 PM Rémy Maucherat <r...@apache.org> wrote: > >> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas <ma...@apache.org> wrote: >> >>> Hi, >>> >>> As discussed in PR#298 [1], properly/fully/correctly supporting JPMS / >>> OSGi gets trickier than necessary with the bootstrap JAR because of the >>> way we currently package it with the minimum that it needs and duplicate >>> some classes. >>> >>> My simplistic understanding is that having all of a Java package in a >>> single JAR makes JPMS and OSGi a lot simpler. Further, our current >>> approach may not be 100% compatible with one or both of them. >>> >>> The trade-offs involved here are: >>> - having all of a package in a JAR simplifies JPMS and OSGi >>> - We want to keep the bootstrap JAR small (is this much of a concern?) >>> - We don't want duplicate code (maintenance overhead) >>> - Bootstrap uses various utility functions from the Tomcat code base >>> >>> I'm wondering if there is a better approach we could adopt that makes >>> JPMS / OSGi simpler without compromising too much on the other >>> trade-offs. >>> >>> The sort of thing I have in mind is: >>> - move everything out of o.a.c.startup that doesn't need to be there to >>> either some new package (name TBD) or an existing package >>> >> >> That means way too many risky changes IMO, the listeners in the startup >> package are often extended to add features so they need to remain in the >> catalina.startup package. >> >> >>> - create an o.a.c.startup.util package and, during the build process, >>> copy and package rename any utility classes the remaining classes in >>> o.a.c.startup depend on >>> >> >> Good idea, when I read your requirements, I thought about package >> renaming. So I think we could use package renaming for everything that >> bootstrap.jar has to a tomcat.bootstrap or catalina.bootstrap package. >> >> Rémy >> >> >>> >>> The end result should be a nice clean mapping of packages to JARs. >>> >>> Thoughts? >>> >>> Mark >>> >>> >>> >>> [1] https://github.com/apache/tomcat/pull/298 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >>> > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
