Thanks Alex, So this is currently not fully implemented. I think this would have many use cases in EE land where we would need override some modules.
On Tue, Nov 3, 2015 at 5:57 AM, Alex Buckley <alex.buck...@oracle.com> wrote: > On 11/2/2015 3:32 PM, Ali Ebrahimi wrote: > >> On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman <alan.bate...@oracle.com> >> wrote: >> >> On 02/11/2015 20:02, Ali Ebrahimi wrote: >>> Thanks, I see the issue. The reason it didn't duplicate for me is because >>> I hadn't dropped the requires com.bar. >>> >>> So the bug is implied readability across layers when the same named >>> module >>> exists in multiple layers. In this case com.foo should read com.bar@1. >>> The com.bar (@2) is the same configuration as com.foo is confusing the >>> code. We'll need to fix this. >>> >>> So, you say com.foo can not read com.bar(@2) and why? >>> >> Based on implied readability module com.foo implicitly reads com.bar, in >> other word have requires com.bar; >> and because com.bar(@2) is co-layer with com.foo, so >> module com.foo should reads com.bar(@2). >> com.bar(@2) override com.bar(@1) for com.foo. >> How this specified in spec? >> > > It's currently underspecified in Configuration::resolve as "A readability > graph is then constructed to take account of implicitly declared > dependences (requires public)." > > 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. > > Alex > -- Best Regards, Ali Ebrahimi
