> On Apr 23, 2023, at 3:46 AM, 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.
It seems “bad” to somehow impose an order by taking a “package” (jar) and
turning it into a list (classpath). Again, I really think that order of
reference and use should be explicit. If there is manifest data describing an
ordering that is explicit there, that might work, but we still have the problem
that if I need a different ordering to use a service or other interface
implementation as an override of what the multi-module jar contains, we need to
control that somehow very explicitly. Stacking so many “orderings” to implicit
details will be more problematic than a simplifying detail it seems to me.
Gregg Wonderly
