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
