Hi Paul,
no, I'm not talking about multiple versions of the same module, that
subject is clear to me.
Alan described quite precise my issue (it's the first described usecase,
although the others are interesting as well). So it seems that if two
different modules export the same package, there will be a compilation
error. No chance of class collisions within a moduled system. That's a
very tight safety belt! For me it is too early to jump to conclusions, but
this might have bigger impact than the module separation itself.
thanks,
Robert
Op Fri, 15 Jan 2016 20:33:32 +0100 schreef Paul Benedict
<pbened...@apache.org>:
Robert, in the SOTM document, it explicitly calls out that Module systems
are not required to support multiple versions of a module. Correct me if
wrong, but I think you're hinting at that?
Cheers,
Paul
On Fri, Jan 15, 2016 at 3:06 AM, Robert Scholte <rfscho...@apache.org>
wrote:
Op Thu, 14 Jan 2016 23:45:32 +0100 schreef Jonathan Gibbons <
jonathan.gibb...@oracle.com>:
On 01/14/2016 12:25 PM, e...@zusammenkunft.net wrote:
Hello,
If I understood it correctly the modules on the MP must be unique and
are not merged, thats why the order inside the directory does not
matter
for the named modules.
Bernd
Let me refine that for you ...
The modules in each directory on the module path must be unique. A
module with a specific name in a directory on the module path will
shadow
(hide) any other module with the same name in a later directory on the
path.
So, the order of directories on the module path matters (just like the
order of entries on a class path matters), but the "order" of entries
within any specific directory on the module path does not matter.
-- Jon
Suppose there's a logging module and a fat module, which also contains
the
classes of the logging module, but older.
In my module-info I have
requires logging;
requires fat;
These modules are in the same directory. Which class is loaded first and
why? If it is the order in the module-info, then I would also like to
see
an example of the strategy with "requires public".
thanks,
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
