Hi Tibor, My offer to help stands; I sincerely hope that the suggested command line is not the way things go; in my regular projects, we have been working very hard to avoid the use of various —add-* switches, as they are stopgaps. Of course, one of my real hopes is to have all of this work with multi-release jars, with such builds rerunning tests with both the old and new versions :)
Regards, Russ > On Aug 28, 2017, at 6:24 AM, Robert Scholte <rfscho...@apache.org> wrote: > > Hi Russ, > > All maven-compiler-plugin 3.6.x are already based on this idea. So if you use > maven-compiler-plugin 3.6.2 (current) it'll work as explained. > > And yes, surefire needs some help on this, but I like to leave Tibor in the > lead for this. JUnit5 and Java9 both have impact, but the focus has been > mainly on JUnit 5 for now. > > The main missing feature it to run surefire with the modulepath[1]. > Tibor can explain it better, but this is my understanding: > surefire creates an executable jar with a manifest file containing the > classpath to ensure it all fits on the cmdline. > With Java 9 this has to be transformed an @args file, so the way to call this > jar will change as well. > > I got some feedback from Alan Bateman as well (and he's willing to help as > well): > "I assumed the challenge for test execute would be getting the CLI options > right. I would expect it will end up like this: > > -p > <target-classes>:<target-test-classes>:<dependences>:<test-scope-dependences> > --add-modules <project-module> > --patch-module <project-module>=<target-test-classes> > --add-reads <project-module>=junit > --add-exports <project-module>/<package>=junit > -m junit/org.junit.runner.JUnitCore <test-class> > > which is complicated. The `--add-reads` option will depend on which test > framework is used. The `--add-exports` options will be repeated for each > package contains tests invoked by the test framework." > > So there's enough to improve to make it all work. > I would say "any help is appreciated", but I'll leave it up to Tibor. > > thanks > Robert > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1262 > > On Mon, 28 Aug 2017 04:16:21 +0200, Russell Gold <russell.g...@oracle.com> > wrote: > >> Hi Robert, >> >> That sounds great. Any idea on timing of the release? What about the >> surefire plugin? Is there something I can do to help? I am actively working >> on Java 9 issues in a few projects, including both the module system and >> multi-release jars, so I am very motivated to do what I can to help maven >> get there. >> >> Thanks, >> Russ >> >>> On Aug 27, 2017, at 8:38 AM, Robert Scholte <rfscho...@apache.org> wrote: >>> >>> Hi Russ, >>> >>> this is how it works: >>> in case there's a module descriptor, the module-path with be used. With the >>> help of plexus-java it is possible to divide all jars over the module-path >>> and classpath. This mechanism is implemented in the maven-compiler-plugin >>> (will do an official release soon with the latest improvements), other >>> plugins can/should use this too. >>> >>> This means that you actually don't need to change anything in your pom.xml. >>> With the module descriptor and all the dependencies there's enough >>> information to decide which jars belong on the modulepath and which on the >>> classpath. So in the end there's no need for new scopes anymore, although >>> that was my first thought as well. >>> >>> To create an installer, I think you're referring to JLink. Karl Heinz is >>> preparing the maven-jlink-plugin. >>> >>> thanks, >>> Robert >>> >>> On Sun, 27 Aug 2017 13:50:46 +0200, Russell Gold <russell.g...@oracle.com> >>> wrote: >>> >>>> I’m sure this must have been described somewhere; is there an overall >>>> direction document for supporting the java platform module system? >>>> >>>> case 1) >>>> >>>> I want to compile against another project on the module path rather than >>>> the class path. I do this in order to ensure compile-time checking for >>>> attempts to compile against non-exported packages. >>>> >>>> case 2) >>>> >>>> I want to test against another project on the module path. This would >>>> allow me to catch reflective access attempts against that module’s >>>> internals >>>> >>>> case 3) >>>> >>>> I want to use the module dependencies to create an installer, with the >>>> dependent modules on the module path. In theory, if Maven understands the >>>> above 2 cases, it would also be able to verify the requires clauses in my >>>> project’s module-info. >>>> >>>> So how will we be doing this in maven? Is it already supported? My first >>>> thought was that we need two new scopes: module (case 1) and module-test >>>> (case 2), but has this already been planned? >>>> >>>> Thanks, >>>> Russ >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: users-h...@maven.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
