Russell, if you have a module with package X and a classpath jar with package X, the module can't see package X from the classpath.
In the last several posts, there's been discussion on putting tests on the classpath; keeping the "main" code in the module. So given what I stated above, that's what I've been referring to. Cheers, Paul On Wed, Mar 30, 2016 at 7:28 AM, Russell Gold <russell.g...@oracle.com> wrote: > 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> > 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> 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 >> >>> >> >> > >
