Paul, you can give a different version to your module but you don't have to. Test can use the very same module name along with the same version.
Rémi ----- Mail original ----- > De: "Paul Benedict" <pbened...@apache.org> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Stephen Colebourne" <scolebou...@joda.org>, "jigsaw-dev" > <jigsaw-dev@openjdk.java.net> > Envoyé: Mardi 29 Mars 2016 17:55:10 > Objet: Re: modulepath and classpath mixture > Remi, it's really untenable to give tests a different version. Tests are > currently built under the same version as the main project under one master > parent project. Split packages are still going to be a necessary because > that's the world of thousands of existing projects. So that might be against > jigsaw canon but hopefully a compromise can be found. > Cheers, > Paul > On Tue, Mar 29, 2016 at 10:41 AM, Remi Forax < fo...@univ-mlv.fr > wrote: > > ----- 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 > > > > >> > > > > >
