> See Josiah’s email and my response to him. So if app module A uses Y it will have:
requires y. If app module A uses X and Y it will have: requires x; requires y; requires y.inject; We now need everyone using x and y together to explicitly know that y also provides a plugin and that they ALSO must remember to add the requires x.inject; (and x.inject has no exports, it only has the provides). Have I understood correctly? Cheers, Rob. On Sun, 23 Apr 2023, 8:46 pm Ron Pressler, <ron.press...@oracle.com> wrote: > > > > On 22 Apr 2023, at 23:05, Rob Bygrave <robin.bygr...@gmail.com> wrote: > > > > > > > Ron: I’m guessing that what’s bothering you isn’t so much the number > of *modules* but the number of JARs. So I think a more general solution > than adding a way to describe “this service is conditional on the presence > of X” would be to allow multiple modules in a single JAR that would contain > both Y and the X-Y-plugin. > > > > How would this solve the issue? I can't see how having a second module > on the same jar/artifact would work for this case. > > See Josiah’s email and my response to him. > > > > > Bearing in mind this library needs to support both classpath and > module-path. > > Since we don’t yet have multi-module JARs, the question of how it would be > used on the classpath is TBD. However, one possible approach is to treat a > multi-module JAR on the classpath as if each module was in its own JAR, and > all of them were placed on the classpath. > > — Ron
