Hi Paul, Could you explain? What kind of code do you mean cannot access it? And what do you mean by “a split package situation”?
From a conversation I had with Alan, earlier in this thread: > On Mar 23, 2016, at 11:42 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 23/03/2016 14:15, Russell Gold wrote: >> Here are my assumptions, which you can correct. >> >> 1. A jar or classes directory placed on a class path are treated as part of >> the unnamed module > Yes So if the tests and main code are both in directories, which they have been up to now in Maven, why would there be a problem? Both would be in the unnamed module and able to access one another. - Russ > On Mar 29, 2016, at 10:47 PM, Paul Benedict <pbened...@apache.org> wrote: > > Russell, when you drop a jar on the classpath, module code will not be able > to access it in a split package situation. That's the big barrier here. Maven > test projects are typically written with the same package shared with the > "main" code. > > Cheers, > Paul > > On Tue, Mar 29, 2016 at 11:33 AM, Russell Gold <russell.g...@oracle.com > <mailto:russell.g...@oracle.com>> wrote: > 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 > > <mailto: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 > >>> <mailto:alan.bate...@oracle.com>> > >>> À: "Stephen Colebourne" <scolebou...@joda.org > >>> <mailto:scolebou...@joda.org>>, "jigsaw-dev" <jigsaw-dev@openjdk.java.net > >>> <mailto: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 > >>> > >
