Hi Russel, part of the code i test use Layers and annotations on Modules, it just doesn't work with in a non module environment :(
regards, Rémi > De: "Russell Gold" <russell.g...@oracle.com> > À: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> > Cc: "Robert Scholte" <rfscho...@apache.org>, "Sander Mak" > <sander....@luminis.eu>, "Remi Forax" <fo...@univ-mlv.fr> > Envoyé: Vendredi 25 Novembre 2016 17:15:44 > Objet: Re: modules and tests > If you are doing unit testing, all you presumably care about is the classes > themselves; not the configuration. I would think that tests which care about > configuration - including what classes are accessible - is properly a > functional test. > So, why not simply handle unit tests, as you say, with everything on the class > path - and then also do functional tests with those tests in a separate > package > so that they are subject to the same access rules that any outside code would > experience? We want unit tests in the same package as the code they are > testing, not only to make the correspondences clear, but also so that we can > access package-private class members, but that isn’t the case for functional > tests. > Russ >> On Nov 25, 2016, at 5:48 AM, Robert Scholte < rfscho...@apache.org > wrote: >> On Thu, 24 Nov 2016 15:39:19 +0100, Remi Forax < fo...@univ-mlv.fr > wrote: >>> setting command line arguments or using a build tool to fiddle them for you >>> is >>> exactly what we do not want here! We want fidelity between the compile time >>> configuration and the runtime configuration. Having to play with -Xpatch at >>> runtime is conceptually exactly like setting the classpath. I don't want to >>> explain to the Java devs that we have fidelity between compile-time and >>> runtime >>> on source code but not on test code. >> I agree on this one. I've been thinking about this a lot and I'm wondering if >> this is a Java issue or test-tool issue. >> What I see with JUnit is that everything is added to the (class)path. I've >> been >> wondering if having separate arguments for the main classes and test classes >> would make it possible to prevent the patch argument while chaining >> classloaders. >> e.g. java -jar junit.jar -DmainPath=<arg> -DtestPath=<arg> ...<moreArgs> >> in Maven terms: mainPath will contain all compile-dependencies, testPath will >> contain all test-dependencies WITHOUT the compile-dependencies. >> However, is this enough to support split packages? >> Robert
