On 03/12/2015 19:49, Robert Scholte wrote:
After reading the specs it seems like I can only refer to a directory containing modules. For a dependency specified in the pom.xml I could refer to the directory (within the local repository) containing that specific artifact. However, such directory contains more files, so I can't be certain the correct file is picked up (e.g. cooomons-lang3-3.4[2]. Both commons-lang3-3.4.jar and commons-lang3-3.4-tests.jar might contain a module-info.class, but it is uncertain if this was the file specified as dependency).
As Mark said, this has come up a few times and good to support this (it's easy, the only question might be whether it should allow exploded modules too).
Just on the example, then I assume that commons-lang3-3.4-sources.jar and commons-lang3-3.4-javadoc.jar won't have a module declaration and so would be treated as automatic modules. This isn't going to work of course because the module name derived for both will be "commons-lang3" and we can't have 2+ modules with the same name in the same directory.
I think *-tests.jar brings many discussion points and maybe something for another thread. In brief, if the tests are in their own package hierarchy, not overlapping with the packages in the library that they test, then the tests could be another module with their own module declaration. If the tests are in the same packages as the APIs that they are testing (this is typical, also necessary when testing package private types or methods) then they won't be their own module but will instead need to be grafted onto the module that they are testing. We've worked through several examples and I think we have all the options in place, we'll just need to make sure that it is easy to use and having Maven plugins supporting those options would be a great help.
-Alan. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
