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]
