Stephen C, I'd like to question the assumption why tests must be their own module? Clearly tests are going to be their own artifact, but I am not sure they need the semantics of module boundaries. Placing on them classpath would be the best thing for them, I think. However, two requirements would still need to be met:
(a) Split packages need to be allowed so test classes can live in the same package as the main classes (b) Test classes can replace main classes The patch/override command line argument already satisfies (b). Regarding (a), although the classpath exports everything, code in an named module can't access types in the unnamed module. That will be necessary so existing code in "main" can access the replacement classes in "test". If there was a mechanism to allow classpath code to overlay with module code, existing Maven projects could function normally. Cheers, Paul On Mon, Mar 28, 2016 at 9:23 AM, Stephen Felts <stephen.fe...@oracle.com> wrote: > Having spent 3 years using OSGI, fragment bundles were a great feature > that we used to overcome this type of problem and others. > I like the idea but I don't think it will be popular in Jigsaw (and OSGI > is a four-letter word). > > > > -----Original Message----- > From: Ali Ebrahimi [mailto:ali.ebrahimi1...@gmail.com] > Sent: Monday, March 28, 2016 8:56 AM > To: Remi Forax > Cc: jigsaw-dev > Subject: Re: modulepath and classpath mixture > > I think we can adapt OSGI fragment bundle here and introduce module > fragments that is attached to a host module. > > So we would have test fragment that is embeded in main module. So we would > have one module. > What do you think? > > On Mon, Mar 28, 2016 at 2:43 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > > > Hi Stephen, Hi all, > > I think that delivering tests as a separated module is a bad idea. > > > > I see that from the point of a developer, seeing the code and the test > > as different modules can be attractive because everything seems to be > > put at the right place but there is a big drawback. Because modules > > are reified at runtime, it means that the runtime environment of the > > tests will be different from the production environment. > > > > So as Alan said, from the jigsaw point of view at runtime, the tests > > and the code should be in the same module. > > > > So the building tools have to come with a way to support to have 2 > > different module-info.java in two different folders and package them > > as one module, maybe javac should help by providing a way to merge 2 > > module-info at compile time. > > > > Rémi > > > > ----- Mail original ----- > > > De: "Alan Bateman" <alan.bate...@oracle.com> > > > À: "Stephen Colebourne" <scolebou...@joda.org>, "jigsaw-dev" < > > jigsaw-dev@openjdk.java.net> > > > Envoyé: Mercredi 23 Mars 2016 16:18:50 > > > Objet: Re: modulepath and classpath mixture > > > > > > > > > On 23/03/2016 14:42, Stephen Colebourne wrote: > > > > : > > > > > > > > I don't particularly care what the mechanism is for this, but at > > > > the requirements level: > > > > - there are two modules - main and test > > > > - each has its own source tree > > > > - each has its own dependencies > > > > - each is released separately > > > > - each could be hosted on a central repo > > > > - the test module needs to be able to contain the same packages as > > > > the main module > > > > - the test module needs to be able to invoke package-scoped code > > > > in the same package in the main module > > > > > > > > To clarify further consider 4 modules, A, B, A-test and B-test > > > > where B depends on A. Module A-test may have a method foo() that > > > > uses package scope to access something in A. Module B-test will > > > > depend on A-test and rely on foo() to get access to that internal > object. > > > To your list, I would add the ability to make use of testing > > > frameworks like TestNG and JUnit. > > > > > > In any case, and as things currently stand, you've got most of the > > > above. One differences is that the tests are not a separate module, > > > they are instead compiled and run in a way that patches the main > > > module. The second difference is that they don't have their own > > > module declaration, instead the compilation or run augments the > > > dependences with any additional dependences that the tests have. As > > > I said, if they tools makes it easy then I don't think it's too bad. > > > > > > > > > > > (Note that I view the thread discussion of references to test > > > > classes on the classpath as another hack. > > > > > > > Packages can't be split between modules and classpath so there is no > > > support for that. > > > > > > -Alan > > > > > > > > > -- > > Best Regards, > Ali Ebrahimi >
