Russell, you ask a good question. If an artifact is meant to be a module, wouldn't it make sense for it to run as a module during testing too? Those boundaries should be activated like they are in production to get good confidence in the code. Those are my two cents. I'd like to hear opposing opinions though why the boundaries shouldn't be there.
Cheers, Paul On Wed, Mar 30, 2016 at 2:07 PM, Russell Gold <russell.g...@oracle.com> wrote: > Hi Paul, > > Why would you put your main code on the module path *during a unit test*? > It seems to me that unit tests are explicitly about making sure that the > code works, not the packaging. So you put both main and test code on the > classpath, and there is no problem. The unit test can be done before the > main code is packaged into a module. > > - Russ > > On Mar 30, 2016, at 10:47 AM, Paul Benedict <pbened...@apache.org> wrote: > > 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 >>> >>> >>> >> >
