On 05/11/2015 09:30, Ali Ebrahimi wrote:
Hi alan,
So far quite disappointing!
But I think Alex's last response on this topic says opposite of this:
"We'll have to think about the implication of com.baz in layer1
sometimes offering a 'requires public' on com.bar in layer1, and
sometimes offering a 'requires public' on com.bar in layer2, depending
on who is reading com.baz in layer1."
In this case adding 'requires public' on com.bar in layer2 does not
mean we should pick com.bar@2 for com,foo?
In this example then com.baz in layer1 doesn't know anything about
com.bar@2 or other modules that comes into existence in future "child"
layers, at least not statically.
com.baz does read com.bar@1 and as it declares "requires public com.bar"
then I assume com.baz's exported API must have com.bar@1 types in its
method signatories. This will usually be good for other modules in
layer1 or modules in descendants of layer1 that use the com.baz API.
Creating a new layer2 does not change modules in other layers. This
means that creating layer2 will not change com.baz (in layer1) to read
com.bar@2 (in layer2). It is of course possible for com.baz to opt-in
and reflectively to read com.bar@2 but great care is required (static
references in code in com.baz will presumably resolve to types in
com.bar@1).
This scenario would have many usages in future when world would filled
with modules and developers would have to use newer versions of
modules to fix bugs.
What if com.foo compiled against com.bar@2? adding redundant
requirescom.bar in com.foo does not help and my app will fail.
Assuming com.bar@1 and com.bar@2 export the same packages then it should
fail when you attempt to create the Configuration for layer2 as com.foo
cannot read both.
In this example then you might consider a new instance of module com.baz
in layer2. That way, layer2 would have com.foo, com.baz and com.bar@2.
-Alan.
