So if I do not implement module-info.java in surefire booter, everything would be same as in the old JVM? What if a user has module-info.class in one of his jar files which appears in Class-Path of surefire's MANIFEST.MF?
Anyway we should include Oracle guys into our discussion. What influence the jdk9 would have in order to run surefirebooter4942721306300108667.jar? The expected of course is to run this jar file as before, full JRE available in classpath with no extra work in Surefire. $ jar tf surefirebooter4942721306300108667.jar META-INF/MANIFEST.MF Manifest-Version: 1.0 Class-Path: file:****surefire-booter-2.19.1.jar *** *** *** etc Main-Class: org.apache.maven.surefire.booter.ForkedBooter Cheers Tibor On Sat, Jan 9, 2016 at 6:04 PM, Paul Benedict <[email protected]> wrote: > According to the JDK ticket, Alan says: "anything that implements "module > path" would need to support this." I assumed this also means java.exe. The > ticket also states they want to get away from "long command lines". Based > on these remarks, it should be affecting forking too. > On Jan 9, 2016 10:57 AM, "Tibor Digana" <[email protected]> > wrote: > > > a. > > Regarding execution of forked JVM in Surefire it has nothing to do with > > javac, nothing but java. > > Regarding building forked jar, then yes this may have an impact because > we > > create jar file which contains manifetst having Class-Path. > > > > b. > > Is the classpath in manifest going to be deprecated or removed? > > > > c. > > Is the javac switch "-cp" going to be deprecated or removed in future? > > > > d. > > Maybe a solution from me. > > Imaging this command: > > > > javac -modulepath dir1:dir2:dir3 -modulepathfactory ./mfactory.jar > > > > If -modulepathfactory is unspecified then Oracle's default is applied. > > Compiler API can be extended with new SPI interface (spi=global in VM :( > ) > > or whatever other interface. > > > > It would be nice and modern style to have javac which understands a > > scripting language along with jar file in -modulepathfactory. > > In such case: > > javac -modulepath ... -modulepathfactory mf.groovy > > > > Cheers > > Tibor > > > > > > > > On Sat, Jan 9, 2016 at 4:41 PM, Robert Scholte <[email protected]> > > wrote: > > > > > Hi Paul, > > > > > > thanks for your response. > > > > > > I'm not sure if I follow you with the forking problem. I guess you're > > > talking about the fork option of surefire. > > > Maybe one of the active surefire committers can explain how classpaths > > are > > > handled right now and if this has a conflict with this proposal. > > > Based on what I read the name of the properties file doesn't matter. > > > > > > One possibility is to allow the module path to directly contain entries > > >>> specifying modules, as compared to directories containing modules. > See > > >>> JDK-8144665 [3]. While feasible, that would put us back in the world > of > > >>> long paths, and hence long command lines, which are problematic on > some > > >>> platforms, and which have led to ad-hoc workarounds such as the use > of > > >>> so-called @-files, to workaround around any platform-specific command > > >>> line limitations. > > >>> > > >> AFAIK buildtools use the compiler-api, where the limitation is the max > > > array size. I wonder if the commandline should still be used as first > > > reference. IMHO if commandlines become that long you should switch to a > > > buildtool. > > > > > > There are 2 things important to me: > > > - reference must result in a single file > > > - predictable order > > > > > > For those who aren't aware of it: java.io.File.list() returns an array > of > > > strings naming the files and directories in the directory denoted by > this > > > abstract pathname. > > > But the javadoc also says: There is no guarantee that the name strings > in > > > the resulting array will appear in any specific order; they are not, in > > > particular, guaranteed to appear in alphabetical order. > > > I can confirm this, I've seen different orders for different OS's. > > > > > > To be honest, I don't know if the order of "requires" in the > module-info > > > has effect on the "classpath", nor how transitive modules behave. So if > > the > > > predictable order is controlled by the module-info, then it is not a > > Maven > > > problem anymore. > > > > > > thanks, > > > Robert > > > > > > Op Fri, 08 Jan 2016 20:14:33 +0100 schreef Paul Benedict < > > > [email protected]>: > > > > > > > > > It sounds like Maven will have to generate many .properties file in a > > >> build. > > >> 1) Modules to compile main source > > >> 2) Modules to compile test source > > >> 3) Modules to execute tests > > >> 4) And what about forking? > > >> > > >> I am concerned #4 is going to create issues unless the .properties > file > > >> name is unique enough. Perhaps it can be based on process id. > > >> > > >> > > >> Cheers, > > >> Paul > > >> > > >> On Fri, Jan 8, 2016 at 11:42 AM, Robert Scholte <[email protected] > > > > >> wrote: > > >> > > >> FYI, a new idea to solve our modulepath issue. > > >>> Any feedback is appreciated. > > >>> > > >>> thanks, > > >>> Robert > > >>> > > >>> -------- Forwarded Message -------- Subject: Specifying module paths > > >>> Date: > > >>> Thu, 07 Jan 2016 15:39:43 -0800 From: Jonathan Gibbons > > >>> <[email protected]> <[email protected]> To: > > >>> jigsaw-dev > > >>> <[email protected]> <[email protected]> > > >>> > > >>> This is a follow-up to some of the recent email discussions regarding > > >>> the use of the module path. > > >>> > > >>> The "State of the Module System" [1] defines a _module path_ as > > follows: > > >>> > > >>> > A module path is a sequence of directories containing module > > artifacts > > >>> > which are searched, in order, for the first artifact that defines a > > >>> > suitable module. > > >>> > > >>> However, build systems may find it inconvenient to aggregate the > > >>> necessary set of modules for an application into such a sequence of > > >>> directories. For example, see [2]. In general, it is undesirable to > > >>> have to copy jar files into directories on the module path, partly > > >>> because of the IO cost involved, and partly because of the number of > > >>> duplicated files that might ensue. > > >>> > > >>> One possibility is to allow the module path to directly contain > entries > > >>> specifying modules, as compared to directories containing modules. > See > > >>> JDK-8144665 [3]. While feasible, that would put us back in the world > of > > >>> long paths, and hence long command lines, which are problematic on > some > > >>> platforms, and which have led to ad-hoc workarounds such as the use > of > > >>> so-called @-files, to workaround around any platform-specific command > > >>> line limitations. > > >>> > > >>> Another possibility would be to use symbolic links, so that the > > >>> directories on the module path do not directly contain the necessary > > jar > > >>> files but instead contain links to those jar files. But symbolic > links > > >>> are not uniformly supported on all systems, which would make such an > > >>> approach somewhat problematic. > > >>> > > >>> This note suggests a similar-but-different approach. > > >>> > > >>> The proposal is that it should be possible to represent an entry on > the > > >>> module path as a text file in Java properties file format, such that > it > > >>> provides a mapping from a module name to a location on the host > system > > >>> where the contents of the module can be found. The representation of > > the > > >>> module itself could be any form that could otherwise appear in a > > >>> directory on the module path, such as a modular jar or exploded > module. > > >>> Just as a file system directory provides a mapping from a name to the > > >>> content of a module, so too could such a properties file, which could > > be > > >>> created at minimal cost, without copying any files, and which would > > work > > >>> uniformly across all platforms. Although there need not be any > > inherent > > >>> restrictions on the use of such entries on the module path, in the > > >>> extreme case, the location of all the application modules for an > > >>> application could be specified in a single properties file entry on > the > > >>> application module path. > > >>> > > >>> While conceptually similar to the use of @-files, the use of property > > >>> files to express a large number of entries on a module path would > > >>> provide a more structured solution that would be uniformly adopted > > >>> across all tools that process module paths, including but not limited > > to > > >>> the Java launcher (java), linker (jlink), and compiler (javac). > > >>> > > >>> -- Jon > > >>> > > >>> > > >>> [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/ > > >>> [2] > > >>> > > > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005582.html > > >>> [3] https://bugs.openjdk.java.net/browse/JDK-8144665 > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > -- > > Cheers > > Tibor > > > -- Cheers Tibor
