Alan, Jon, i think javac -Xmodule should merge the module-info.java from the existing module and the one declared in the directory, with the current semantics of the module-info, merging of modules is easy and with no corner cases, so for testing, the test will be able to declare their own dependencies inside their own module-info.java.
Proposed semantics for merging, - do the union of the required modules - if one required module is required publicly, it will be required publicly. - do the union of the exported packages - if one exported package is restricted, do the union of the restriction - do the union of the uses. - do the union of the provides. so merging two modules is symmetric and will always succeed. Rémi ----- Mail original ----- > De: "Alan Bateman" <alan.bate...@oracle.com> > À: "Russell Gold" <russell.g...@oracle.com> > Cc: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> > Envoyé: Mercredi 30 Mars 2016 15:45:03 > Objet: Re: modulepath and classpath mixture > > On 30/03/2016 13:28, Russell Gold wrote: > > : > > > > > > So if the tests and main code are both in directories, which they have been > > up to now in Maven, why would there be a problem? Both would be in the > > unnamed module and able to access one another. > > > There shouldn't any issue there, it should just work as it has always done. > > The thread here has meandered a bit but I think the scenario under > discussion is tests for a module that need to nestmate with the module > under test. The tests are in their own test tree. The tests are compiled > separately from the module they test and may have additional dependences > (such as on TestNG or JUnit for example). When compiling or running then > the tests need to access public types in non-exported packages and maybe > package private members too. The support for this has been in jake for a > long time but involves command line options that many developers or > build environments won't immediately grok. In particular the tests have > to be compiled "as if" they augment the already compiled module - that > is what javac -Xmodule is about. There is no need to co-locate source > files or class files of course. When run then the -Xpatch option is what > brings the tests and the module classes together. If we get the tools > right then most developers won't ever see this of course. > > One other thing to say that we've already been through some of this with > the JDK tests. The jtreg test harness that we use for the JDK tests has > been updated (thanks to Jon Gibbons) with useful support for modules > [1]. It's enough for us to write tests that use JDK-internal APIs or > write tests that nestmate with types in system modules so that they get > access to package private type or public types in non-exported packages. > It has rudimentary support for user modules too. Additional dependences > are still an issue but our tests don't require additional dependences > beyond TestNG. The test harness employs a bit of hackery to get things > done, important when starting out, but I expect will go away in time. > > -Alan. > > [1] > http://hg.openjdk.java.net/code-tools/jtreg/raw-file/tip/src/share/doc/javatest/regtest/tag-spec.html > > >
