Just add these to Paul's response, what about multi-module apps? Do we coming back to non-modular world?
On Wed, Mar 30, 2016 at 11:43 PM, Paul Benedict <pbened...@apache.org> wrote: > 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 > >>> >>> > >>> > >> > > > -- Best Regards, Ali Ebrahimi
