Commons libraries are generally self-contained to the point where modularity isn’t a problem. Things get complicated once you start involving split up modules like APIs, SPIs, alternate implementations, and reflection-heavy design patterns that otherwise bypass language rules around member access.
Perhaps this could be worth discussing with the bndtools maintainers to see what they’ve done or if they even know this is a problem. > On Aug 9, 2024, at 13:22, Gary Gregory <garydgreg...@gmail.com> wrote: > > We do not test the module path. > > "Among the problems that tools like BND or Moditect might" > > So? Then we or others report and fix those tools. If moditect does not work > 100% it's no reason to do all this JPMS junk manually. These are all open > source tools, so we can all play nicely together and report and fix issues. > > Since I've not heard of problems from people asking for JPMS with our new > jars, i can only assume it works for them. > > Gary > > > On Fri, Aug 9, 2024, 2:00 PM Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > >> Hi Gary, >> >> On Fri, 9 Aug 2024 at 15:24, Gary Gregory <garydgreg...@gmail.com> wrote: >>> I've had many requests to support JPMS in Commons and none that I recall >>> since I've been releasing jars using Moditect, so I can only assume it >>> works well enough. My impression is that people only care to get rid of >>> warnings or errors to run an app. >> >> Is there any Commons project that runs tests on the modulepath? >> >> Among the problems that tools like BND or Moditect might miss are: >> >> * missing `uses` directives, >> * optional dependencies that are `transitive`, >> * reflective access from some third-party library that doesn't have >> the right permissions. >> >> Piotr >>
