Re: How does maven handle Java module dependencies?
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 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 > ::: > --add-modules > --patch-module = > --add-reads =junit > --add-exports /=junit > -m junit/org.junit.runner.JUnitCore > > 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 > 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 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 >>> 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 > > -
Re: How does maven handle Java module dependencies?
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 ::: --add-modules --patch-module = --add-reads =junit --add-exports /=junit -m junit/org.junit.runner.JUnitCore 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 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 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 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
Re: How does maven handle Java module dependencies?
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 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 > 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
Re: How does maven handle Java module dependencies?
Hi, On 27/08/17 14:38, Robert Scholte 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. This is not an installer it is a Java Run-Time Image which uses JLink (maven-jlink-plugin, maven-jmod-plugin)... An example how it looks like at the moment can be seen[1] and in [2] how the most recent code works... The first alpha release of maven-jlink-plugin and maven-jmod-plugin is planned within a few weeks... Kind regards Karl Heinz Marbaise [1]: http://blog.soebes.de/blog/2017/06/06/howto-create-a-java-run-time-image-with-maven/ [2]: https://github.com/khmarbaise/jdk9-jlink-jmod-example/tree/master/maven-example thanks, Robert On Sun, 27 Aug 2017 13:50:46 +0200, Russell Gold 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 Mit freundlichem Gruß Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579 Hauptstrasse 177 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How does maven handle Java module dependencies?
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 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
Re: How does maven handle Java module dependencies?
A bit more research turned up this page https://www.sitepoint.com/maven-cannot-generate-module-declaration/ in which Robert explains why my “first thought” below is a non-starter, unless the pom spec is upgraded. So it sounds now as though we are waiting on ASM to read module-info files…? Is there really nothing to be done in the meantime? > On Aug 27, 2017, at 7:50 AM, Russell Gold 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
How does maven handle Java module dependencies?
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
