modulepath and classpath mixture

[forax at univ-mlv.fr]

----- Mail original -----

> De: "Ali Ebrahimi" <ali.ebrahimi1781 at gmail.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Alan Bateman" <Alan.Bateman at oracle.com>, "Jonathan Gibbons"
> <jonathan.gibbons at oracle.com>, "jigsaw-dev" <jigsaw-dev at 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 < forax at 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.Bateman at oracle.com >
> 
> > > À: "Russell Gold" < russell.gold at oracle.com >
> 
> > > Cc: "jigsaw-dev" < jigsaw-dev at 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