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 >
