----- Mail original ----- > De: "Stephen Colebourne" <scolebou...@joda.org> > À: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> > Envoyé: Mardi 29 Mars 2016 15:24:15 > Objet: Re: modulepath and classpath mixture > > On 28 March 2016 at 11:13, 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. > > This last sentence doesn't make sense to me - tests are not run in a > production environment.
yes, you just want your tests to run in a runtime which is as close as possible to the runtime of the production environment. It's like when a test fails because JUnit calls the test concurrently when in production the code always run under a giant lock. > > Tests have all the qualities of modules - code, dependencies, > compilation phase, deployment. The only special part is the need for > special "friend-like" access, which Jigsaw already has for other cases > (the export...to clause). You also need to support split packages or a kind of export...to that allows to export package private method as public. These are two major deviations from the jigsaw canon. Instead of considering tests as a separated module, i prefer to consider them as a separated version (1.0 vs 1.0-test), the test version includes the code, the tests, and have several more dependencies on JUnit like modules. > > Put simply, I consider that module = > deployment-artifact-with-dependencies. With that mental model, putting > tests inside the module is just not acceptable, because tests should > not be deployed with the main application and they have different > dependencies. If we disagree that module = > deployment-artifact-with-dependencies, then perhaps we have bigger > problems to solve here. We agree that a module = deployment-artifact-with-dependencies, but we disagree because for me the test should be a module with the same name but a different version (by example with a test suffix) while you think it should be a different module. > > Stephen > (And to Paul Benedict, the classpath is going to die over time, so any > solution that uses that is flawed IMO). I don't think the classpath will die but if you want to use things like jlink, it will not work if you have jars in the a classpath. Rémi > > > > 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 > >> >
