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 > > > > > > >
