Also, we should look for solutions not workaround( or hacks) in remaining time. I think classpath was that problem we trying avoid (or solve) with jigsaw.
On Wed, Mar 30, 2016 at 1:56 PM, Stephen Colebourne <scolebou...@joda.org> wrote: > On 29 March 2016 at 17:33, 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. > > The underlying message of Jigsaw is that the classpath is going away. > An approach that requires use of the classpath is therefore not really > a solution to the real problem. > > Stephen > > > > 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
