You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Robert Scholte <rf...@apache.org> on 2016/01/08 18:42:18 UTC
[Jigsaw] Fwd: Specifying module paths
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 <jo...@oracle.com>
To: jigsaw-dev <ji...@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
Re: [Jigsaw] Fwd: Specifying module paths
Posted by Robert Scholte <rf...@apache.org>.
module-info on classpath is ignored. That's also the reason why I can run
surefire with my module-info enriched project.
If you add a jar without module-info to the module-path, it is considered
an automodule, i.e exports all packages and requires all available modules.
This kind of information is available, it is not a discussion.
thanks,
Robert
Op Sat, 09 Jan 2016 18:22:19 +0100 schreef Tibor Digana
<ti...@googlemail.com>:
> 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 <pb...@apache.org>
> 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" <ti...@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 <rf...@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 <
>> > > pbenedict@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
>> <rfscholte@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
>> > >>> <jo...@oracle.com> <jo...@oracle.com> To:
>> > >>> jigsaw-dev
>> > >>> <ji...@openjdk.java.net> <ji...@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-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> >
>> >
>> > --
>> > Cheers
>> > Tibor
>> >
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Jigsaw] Fwd: Specifying module paths
Posted by Tibor Digana <ti...@googlemail.com>.
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 <pb...@apache.org> 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" <ti...@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 <rf...@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 <
> > > pbenedict@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 <rfscholte@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
> > >>> <jo...@oracle.com> <jo...@oracle.com> To:
> > >>> jigsaw-dev
> > >>> <ji...@openjdk.java.net> <ji...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> > --
> > Cheers
> > Tibor
> >
>
--
Cheers
Tibor
Re: [Jigsaw] Fwd: Specifying module paths
Posted by Paul Benedict <pb...@apache.org>.
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" <ti...@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 <rf...@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 <
> > pbenedict@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 <rf...@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
> >>> <jo...@oracle.com> <jo...@oracle.com> To:
> >>> jigsaw-dev
> >>> <ji...@openjdk.java.net> <ji...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Cheers
> Tibor
>
Re: [Jigsaw] Fwd: Specifying module paths
Posted by Tibor Digana <ti...@googlemail.com>.
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 <rf...@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 <
> pbenedict@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 <rf...@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
>>> <jo...@oracle.com> <jo...@oracle.com> To:
>>> jigsaw-dev
>>> <ji...@openjdk.java.net> <ji...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Cheers
Tibor
Re: [Jigsaw] Fwd: Specifying module paths
Posted by Robert Scholte <rf...@apache.org>.
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
<pb...@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 <rf...@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
>> <jo...@oracle.com> <jo...@oracle.com> To:
>> jigsaw-dev
>> <ji...@openjdk.java.net> <ji...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Jigsaw] Fwd: Specifying module paths
Posted by Paul Benedict <pb...@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 <rf...@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
> <jo...@oracle.com> <jo...@oracle.com> To: jigsaw-dev
> <ji...@openjdk.java.net> <ji...@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
>
>
>
>
>
>
>
Re: [Jigsaw] Fwd: Specifying module paths
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
This is a very good proposal. My only suggestion is to extend
javax.tools CompilationTask API to take modulepath map as in-memory
parameter. Not a big deal, but it'll be silly to write properties
file to disk for it to be immediately read by the code executed in
the same jvm.
--
Regards,
Igor
On Fri, Jan 8, 2016, at 12:42 PM, Robert Scholte 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 <jo...@oracle.com>
> To:
> jigsaw-dev <ji...@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
>
>
>
>