----- Mail original ----- > De: "Ali Ebrahimi" <ali.ebrahimi1...@gmail.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Alan Bateman" <alan.bate...@oracle.com>, "Jonathan Gibbons" > <jonathan.gibb...@oracle.com>, "jigsaw-dev" <jigsaw-dev@openjdk.java.net> > Envoyé: Mercredi 30 Mars 2016 17:12:22 > Objet: Re: modulepath and classpath mixture
> So, do you suggest partial modules or module fragments? A kind of exploded module with sources available in more than one directory. Classes are still in one modular jar with one module-info.class (so at runtime, there is only one module). > 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. That's another question, i think we first need to agree that we just want to have the main code and the test code into different directory and then we can see if javac -Xmodule is the best syntax or if by example -modulesourcepath can accept to have several directories that describe the same module. cheers, Rémi > 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
