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" <tibor.dig...@googlemail.com>
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 <rfscho...@apache.org>
> 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 <
> > pbened...@apache.org>:
> >
> >
> > 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
<rfscho...@apache.org
>
> >> 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
> >>> <jonathan.gibb...@oracle.com> <jonathan.gibb...@oracle.com> To:
> >>> jigsaw-dev
> >>> <jigsaw-...@openjdk.java.net> <jigsaw-...@openjdk.java.net>
> >>>
> >>> 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: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> --
> Cheers
> Tibor
>
