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
