@Robert As I am reading Oracle's statements the Maven would use only programming API. I could not find any API regarding modulepath.
Cheers Tibor On Sat, Jan 16, 2016 at 11:08 AM, Robert Scholte <[email protected]> wrote: > FYI > > ------- Doorgestuurd bericht ------- > Van: "Jonathan Gibbons" <[email protected]> > Aan: [email protected] > Cc: > Onderwerp: Re: Specifying module paths > Datum: Sat, 16 Jan 2016 00:22:30 +0100 > > Winding up this discussion ... > > While the use of a properties file to provide a mapping from module name > to file system artifact has some attractive properties, it seems that > there is insufficient interest to pursue it further at this time. We can > always revisit it later. The same applies to variant suggestions, such > as a plain text file containing a list of module artifacts. > > Instead, there is clearly interest in putting compiled module artifacts > directly on the module path. > > To that end, we will modify the specification of a module path such that > the appearance of a file (as compared to a directory) on a module path > will be treated as though it was in a directory containing just that > file. A directory on the module path will continue to be treated as now. > > The corollary is that "exploded modules" (represented by a directory > hierarchy) cannot themselves be placed directly on the module path; they > must continue to be placed in a directory on the module path. > > This will apply to all JDK tools that support options whose value is a > module path. > > -- Jon > > > On 01/07/2016 03:39 PM, Jonathan Gibbons wrote: > >> 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
