Hi Stephen, Why do you need any kind of friend access?
It seems to me that this is making things harder than they need to be. The tests can simply run with the production code on the class path, and then there are no module issues at all. I think a larger problem is that you can do what I just said with the jars, even a jar which has been designated as a module by virtue of having a module-info.class in it. That means that, when users are up taking jars, they are not prevented from accessing module internals. They can put the jars on the module path, of course, but they can still use them on the class path! - Russ > > 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. > > 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). > > 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. > > Stephen > (And to Paul Benedict, the classpath is going to die over time, so any > solution that uses that is flawed IMO). > > >> 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 >>>
