On 03/30/2016 02:45 PM, fo...@univ-mlv.fr wrote:
------------------------------------------------------------------------ *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.
-modulesourcepath can accept several source directories that together comprise the source for a single module. If nothing else, you can see this utilized in the JDK build, where the source structure for a module may contain subdirectories for platform-independent classes, platform-specific classes, and dynamically generated classes.
The primary constraints are that there is only one module-info.java file, and the mapping to a class output directory.
There is nothing to prevent you recompiling an entire module, including test code, to create a new version of the module, including the test code. If you so choose.
-- Jon
cheers, Rémi On Wed, Mar 30, 2016 at 6:42 PM, Remi Forax <fo...@univ-mlv.fr <mailto: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 <mailto:alan.bate...@oracle.com>> > À: "Russell Gold" <russell.g...@oracle.com <mailto:russell.g...@oracle.com>> > Cc: "jigsaw-dev" <jigsaw-dev@openjdk.java.net <mailto: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
