So, do you suggest partial modules or module fragments? Why we make things so complex for writing single test method. I think testing is an essential part of development, so modular java should have first class support for that. I don't see command line options as developer friendly solution, even things gets worse when have dozen of modules.
On Wed, Mar 30, 2016 at 6:42 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > 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 > > > > > > > -- Best Regards, Ali Ebrahimi
