You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Roman Grigoriadi <ro...@gmail.com> on 2018/04/10 14:23:10 UTC
maven-compiler-plugin JPMS module resolution
Hi,
I would like to place some of the project dependencies to --module-path to
make them automatic "derived name" modules during project compilation. I
can see that maven-compiler-plugin:3.7.0 tries to find module-info.class
and Automatic-Module-Name entry in MANIFEST. If found it uses those jars as
modules.
Is there any way I can force placement non-modularized dependencies on
module path?
Thank you,
Roman
Re: maven-compiler-plugin JPMS module resolution
Posted by Robert Scholte <rf...@apache.org>.
Hi Roman,
seems like you want to mark your dependency as <optional>true</optional>
and define the depending module as requires static some.module;
thanks,
Robert
On Wed, 11 Apr 2018 13:14:24 +0200, Roman Grigoriadi
<ro...@gmail.com> wrote:
> Thanks Robert,
>
> I tried to add requires for name which is resolved by JPMS for my
> non-modularised jar, and it *somehow* made compiler-plugin to put this
> jar
> on module-path.
>
> However if I don't want to reference this jar in my module descriptor,
> so I
> let decision up to user if to put this dependency on CP or MP for app
> runtime, would it make sense to add configuration parameter for
> compiler-plugin which will force CP/MP for some of the dependencies
> during
> compilation?
>
> The best solution I have found so far is to copy such dependencies
> somewhere before compilation and pass --module-path, --add-modules and
> --add-reads to javac.
>
>
> Thank you,
> Roman
>
> On Tue, Apr 10, 2018 at 8:55 PM, Robert Scholte <rf...@apache.org>
> wrote:
>
>> Hi
>>
>> every jar that matches a "requires"-entry of your projects module
>> descriptor and all jars that matches the indirect requirements will be
>> added to the module-path. The rest will stay on the classpath.
>> If you want to do more, you need to verify the JPMS options available
>> for
>> java/javac[1]
>>
>> thanks
>> Robert
>>
>> [1] https://docs.oracle.com/javase/9/tools/javac.htm#JSWOR627
>>
>>
>> On Tue, 10 Apr 2018 16:23:10 +0200, Roman Grigoriadi <
>> roman.grigoriadi@gmail.com> wrote:
>>
>> Hi,
>>>
>>> I would like to place some of the project dependencies to
>>> --module-path to
>>> make them automatic "derived name" modules during project compilation.
>>> I
>>> can see that maven-compiler-plugin:3.7.0 tries to find
>>> module-info.class
>>> and Automatic-Module-Name entry in MANIFEST. If found it uses those
>>> jars
>>> as
>>> modules.
>>>
>>> Is there any way I can force placement non-modularized dependencies on
>>> module path?
>>>
>>>
>>> Thank you,
>>> Roman
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven-compiler-plugin JPMS module resolution
Posted by Robert Scholte <rf...@apache.org>.
You're actually asking for details about the JPMS specification.
I advice you to read the thread "Proposal: #AutomaticModuleNames
(revised)"[1]
This has been one of the crucial changes to accept the JPMS specification.
Before this thread started, there was only bottom up and top down, and no
way for the library-builders in the middle to adopt JPMS.
The Automatic-Module-Name attribute for the MANIFEST was introduced to
help in these situations.
The last paragraph handles a proposal for partial requirements, which was
not accepted.
Just read it all, including the responses.
IMHO What the maven-compiler-plugin currently offers matches the specs
quite good.
thanks,
Robert
[1]
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000687.html
On Mon, 16 Apr 2018 11:58:03 +0200, Roman Grigoriadi
<ro...@gmail.com> wrote:
> I see your point. But wouldn't it result in a kind of modularization
> deadlock if all will wait for their dependencies to have a module name?
>
> Lets say I develop a library, which has 10 dependencies. I own most of
> those and have them modularised except for one or two. I want to add
> early
> testing support for native JPMS so users may start experimenting.
> So I want to release a binary distribution with dependencies packed
> inside:
>
> mylib/libs/*.jar (not modularized yet)
> mylib/mods/*.jar (with module descriptor)
>
> What I am thinking about is to require all from mylib/mods in the
> descriptor of the main jar and let up to users to decide how to make
> available jars from mylib/lib to the runtime. During compilation of the
> project I still want to force maven-compiler-plugin to reference them on
> module path so I can see if there are any JPMS issues.
>
>
> Thank you,
> Roman
>
> On Fri, Apr 13, 2018 at 4:07 PM, Robert Scholte <rf...@apache.org>
> wrote:
>
>> Here you hit the nail on the head! This is exactly my concern and I've
>> spoken about this on several conferences.
>>
>> TLDR: Don't publish libraries to Maven Central that depend on at least
>> one
>> filename-based automatic module. You must wait until all your
>> dependencies
>> are explicit modules.
>> In the meantime you can add the following entry to your MANIFEST.MF so
>> the
>> library consumers can refer to it as if it already a module:
>> Automatic-Module-Name: module.name.of.the.library
>>
>> thanks,
>> Robert
>>
>>
>> On Fri, 13 Apr 2018 11:43:22 +0200, Roman Grigoriadi <
>> roman.grigoriadi@gmail.com> wrote:
>>
>> I guess you are right. I wasn't sure if it is a good idea to include a
>> name
>>> for a module in my descriptor for a dependency which is actually not
>>> named
>>> (automatic) and release with such descriptor. But given this
>>> dependency is
>>> fixed version, it will not get any other name than I am referencing
>>> and it
>>> is more convenient for users than to additionally decide where to put
>>> and
>>> how to reference it.
>>>
>>> Thank you.
>>> Roman
>>>
>>> On Fri, Apr 13, 2018 at 10:17 AM, Robert Scholte <rf...@apache.org>
>>> wrote:
>>>
>>> But that means that the dependency is actually required at runtime.
>>>>
>>>> Looks to me there are 2 options:
>>>> - make that dependency a requirement
>>>> - restructure your code so it can be a static requirement
>>>>
>>>> One of the benefits I do like about the modularization is that it
>>>> forces
>>>> you to do clean coding. It is a new way of thinking and it looks like
>>>> your
>>>> project has potential to be optimized for that.
>>>>
>>>> thanks,
>>>> Robert
>>>>
>>>>
>>>> On Thu, 12 Apr 2018 13:19:34 +0200, Roman Grigoriadi <
>>>> roman.grigoriadi@gmail.com> wrote:
>>>>
>>>> Hi Robert,
>>>>
>>>>>
>>>>> I don't think my case is suitable for requires static / optional.
>>>>> Runtime
>>>>> will fail with ClassNotFound exception if classes are neither on CP
>>>>> or
>>>>> MP.
>>>>>
>>>>>
>>>>> Roman
>>>>>
>>>>> On Thu, Apr 12, 2018 at 12:46 PM, Martin Desruisseaux <
>>>>> martin.desruisseaux@geomatys.com> wrote:
>>>>>
>>>>> Hello Robert
>>>>>
>>>>>>
>>>>>> Le 11/04/2018 à 18:45, Robert Scholte a écrit :
>>>>>>
>>>>>> > I am not aware of such problem. Did you create a Jira[1] issue for
>>>>>> it?
>>>>>> >
>>>>>> Done: https://issues.apache.org/jira/browse/MCOMPILER-336
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven-compiler-plugin JPMS module resolution
Posted by Roman Grigoriadi <ro...@gmail.com>.
I see your point. But wouldn't it result in a kind of modularization
deadlock if all will wait for their dependencies to have a module name?
Lets say I develop a library, which has 10 dependencies. I own most of
those and have them modularised except for one or two. I want to add early
testing support for native JPMS so users may start experimenting.
So I want to release a binary distribution with dependencies packed inside:
mylib/libs/*.jar (not modularized yet)
mylib/mods/*.jar (with module descriptor)
What I am thinking about is to require all from mylib/mods in the
descriptor of the main jar and let up to users to decide how to make
available jars from mylib/lib to the runtime. During compilation of the
project I still want to force maven-compiler-plugin to reference them on
module path so I can see if there are any JPMS issues.
Thank you,
Roman
On Fri, Apr 13, 2018 at 4:07 PM, Robert Scholte <rf...@apache.org>
wrote:
> Here you hit the nail on the head! This is exactly my concern and I've
> spoken about this on several conferences.
>
> TLDR: Don't publish libraries to Maven Central that depend on at least one
> filename-based automatic module. You must wait until all your dependencies
> are explicit modules.
> In the meantime you can add the following entry to your MANIFEST.MF so the
> library consumers can refer to it as if it already a module:
> Automatic-Module-Name: module.name.of.the.library
>
> thanks,
> Robert
>
>
> On Fri, 13 Apr 2018 11:43:22 +0200, Roman Grigoriadi <
> roman.grigoriadi@gmail.com> wrote:
>
> I guess you are right. I wasn't sure if it is a good idea to include a name
>> for a module in my descriptor for a dependency which is actually not named
>> (automatic) and release with such descriptor. But given this dependency is
>> fixed version, it will not get any other name than I am referencing and it
>> is more convenient for users than to additionally decide where to put and
>> how to reference it.
>>
>> Thank you.
>> Roman
>>
>> On Fri, Apr 13, 2018 at 10:17 AM, Robert Scholte <rf...@apache.org>
>> wrote:
>>
>> But that means that the dependency is actually required at runtime.
>>>
>>> Looks to me there are 2 options:
>>> - make that dependency a requirement
>>> - restructure your code so it can be a static requirement
>>>
>>> One of the benefits I do like about the modularization is that it forces
>>> you to do clean coding. It is a new way of thinking and it looks like
>>> your
>>> project has potential to be optimized for that.
>>>
>>> thanks,
>>> Robert
>>>
>>>
>>> On Thu, 12 Apr 2018 13:19:34 +0200, Roman Grigoriadi <
>>> roman.grigoriadi@gmail.com> wrote:
>>>
>>> Hi Robert,
>>>
>>>>
>>>> I don't think my case is suitable for requires static / optional.
>>>> Runtime
>>>> will fail with ClassNotFound exception if classes are neither on CP or
>>>> MP.
>>>>
>>>>
>>>> Roman
>>>>
>>>> On Thu, Apr 12, 2018 at 12:46 PM, Martin Desruisseaux <
>>>> martin.desruisseaux@geomatys.com> wrote:
>>>>
>>>> Hello Robert
>>>>
>>>>>
>>>>> Le 11/04/2018 à 18:45, Robert Scholte a écrit :
>>>>>
>>>>> > I am not aware of such problem. Did you create a Jira[1] issue for
>>>>> it?
>>>>> >
>>>>> Done: https://issues.apache.org/jira/browse/MCOMPILER-336
>>>>>
>>>>> Thanks
>>>>>
>>>>> Martin
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: maven-compiler-plugin JPMS module resolution
Posted by Robert Scholte <rf...@apache.org>.
Here you hit the nail on the head! This is exactly my concern and I've
spoken about this on several conferences.
TLDR: Don't publish libraries to Maven Central that depend on at least one
filename-based automatic module. You must wait until all your dependencies
are explicit modules.
In the meantime you can add the following entry to your MANIFEST.MF so the
library consumers can refer to it as if it already a module:
Automatic-Module-Name: module.name.of.the.library
thanks,
Robert
On Fri, 13 Apr 2018 11:43:22 +0200, Roman Grigoriadi
<ro...@gmail.com> wrote:
> I guess you are right. I wasn't sure if it is a good idea to include a
> name
> for a module in my descriptor for a dependency which is actually not
> named
> (automatic) and release with such descriptor. But given this dependency
> is
> fixed version, it will not get any other name than I am referencing and
> it
> is more convenient for users than to additionally decide where to put and
> how to reference it.
>
> Thank you.
> Roman
>
> On Fri, Apr 13, 2018 at 10:17 AM, Robert Scholte <rf...@apache.org>
> wrote:
>
>> But that means that the dependency is actually required at runtime.
>>
>> Looks to me there are 2 options:
>> - make that dependency a requirement
>> - restructure your code so it can be a static requirement
>>
>> One of the benefits I do like about the modularization is that it forces
>> you to do clean coding. It is a new way of thinking and it looks like
>> your
>> project has potential to be optimized for that.
>>
>> thanks,
>> Robert
>>
>>
>> On Thu, 12 Apr 2018 13:19:34 +0200, Roman Grigoriadi <
>> roman.grigoriadi@gmail.com> wrote:
>>
>> Hi Robert,
>>>
>>> I don't think my case is suitable for requires static / optional.
>>> Runtime
>>> will fail with ClassNotFound exception if classes are neither on CP or
>>> MP.
>>>
>>>
>>> Roman
>>>
>>> On Thu, Apr 12, 2018 at 12:46 PM, Martin Desruisseaux <
>>> martin.desruisseaux@geomatys.com> wrote:
>>>
>>> Hello Robert
>>>>
>>>> Le 11/04/2018 à 18:45, Robert Scholte a écrit :
>>>>
>>>> > I am not aware of such problem. Did you create a Jira[1] issue for
>>>> it?
>>>> >
>>>> Done: https://issues.apache.org/jira/browse/MCOMPILER-336
>>>>
>>>> Thanks
>>>>
>>>> Martin
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven-compiler-plugin JPMS module resolution
Posted by Roman Grigoriadi <ro...@gmail.com>.
I guess you are right. I wasn't sure if it is a good idea to include a name
for a module in my descriptor for a dependency which is actually not named
(automatic) and release with such descriptor. But given this dependency is
fixed version, it will not get any other name than I am referencing and it
is more convenient for users than to additionally decide where to put and
how to reference it.
Thank you.
Roman
On Fri, Apr 13, 2018 at 10:17 AM, Robert Scholte <rf...@apache.org>
wrote:
> But that means that the dependency is actually required at runtime.
>
> Looks to me there are 2 options:
> - make that dependency a requirement
> - restructure your code so it can be a static requirement
>
> One of the benefits I do like about the modularization is that it forces
> you to do clean coding. It is a new way of thinking and it looks like your
> project has potential to be optimized for that.
>
> thanks,
> Robert
>
>
> On Thu, 12 Apr 2018 13:19:34 +0200, Roman Grigoriadi <
> roman.grigoriadi@gmail.com> wrote:
>
> Hi Robert,
>>
>> I don't think my case is suitable for requires static / optional. Runtime
>> will fail with ClassNotFound exception if classes are neither on CP or MP.
>>
>>
>> Roman
>>
>> On Thu, Apr 12, 2018 at 12:46 PM, Martin Desruisseaux <
>> martin.desruisseaux@geomatys.com> wrote:
>>
>> Hello Robert
>>>
>>> Le 11/04/2018 à 18:45, Robert Scholte a écrit :
>>>
>>> > I am not aware of such problem. Did you create a Jira[1] issue for it?
>>> >
>>> Done: https://issues.apache.org/jira/browse/MCOMPILER-336
>>>
>>> Thanks
>>>
>>> Martin
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: maven-compiler-plugin JPMS module resolution
Posted by Robert Scholte <rf...@apache.org>.
But that means that the dependency is actually required at runtime.
Looks to me there are 2 options:
- make that dependency a requirement
- restructure your code so it can be a static requirement
One of the benefits I do like about the modularization is that it forces
you to do clean coding. It is a new way of thinking and it looks like your
project has potential to be optimized for that.
thanks,
Robert
On Thu, 12 Apr 2018 13:19:34 +0200, Roman Grigoriadi
<ro...@gmail.com> wrote:
> Hi Robert,
>
> I don't think my case is suitable for requires static / optional. Runtime
> will fail with ClassNotFound exception if classes are neither on CP or
> MP.
>
>
> Roman
>
> On Thu, Apr 12, 2018 at 12:46 PM, Martin Desruisseaux <
> martin.desruisseaux@geomatys.com> wrote:
>
>> Hello Robert
>>
>> Le 11/04/2018 à 18:45, Robert Scholte a écrit :
>>
>> > I am not aware of such problem. Did you create a Jira[1] issue for it?
>> >
>> Done: https://issues.apache.org/jira/browse/MCOMPILER-336
>>
>> Thanks
>>
>> Martin
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven-compiler-plugin JPMS module resolution
Posted by Roman Grigoriadi <ro...@gmail.com>.
Hi Robert,
I don't think my case is suitable for requires static / optional. Runtime
will fail with ClassNotFound exception if classes are neither on CP or MP.
Roman
On Thu, Apr 12, 2018 at 12:46 PM, Martin Desruisseaux <
martin.desruisseaux@geomatys.com> wrote:
> Hello Robert
>
> Le 11/04/2018 à 18:45, Robert Scholte a écrit :
>
> > I am not aware of such problem. Did you create a Jira[1] issue for it?
> >
> Done: https://issues.apache.org/jira/browse/MCOMPILER-336
>
> Thanks
>
> Martin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: maven-compiler-plugin JPMS module resolution
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Robert
Le 11/04/2018 à 18:45, Robert Scholte a écrit :
> I am not aware of such problem. Did you create a Jira[1] issue for it?
>
Done: https://issues.apache.org/jira/browse/MCOMPILER-336
Thanks
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven-compiler-plugin JPMS module resolution
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Robert
Le 11/04/2018 à 18:45, Robert Scholte a écrit :
> I am not aware of such problem. Did you create a Jira[1] issue for it?
>
> There should be no reason to have a workaround, all the information is
> there so Maven is capable to divide jars properly over both paths. If
> you can add a project so I can reproduce the issue, I can have a look
> at it.
>
I have not yet created a JIRA issue. I tried last week to create a
minimal test case reproducing the issue, without success. The issue
happen with the real project; I have not yet isolated all the conditions
that make the issue happen.
The issue happen with GeoAPI [1]. The following works fine (assuming a
JSR 385 2.0-SNAPSHOT is available on the local repository):
mvn clean install -Pjdk9
But running the following immediately after:
mvn install -Pjdk9
cause the following error message:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on project geoapi: Compilation failure
[ERROR] module not found: java.measure
Executing in debug mode, we can see that the java.measure (JSR-385)
dependency is correctly put in modulepath when maven-compiler-plugin
compiles everything (e.g. when the "clean" phase is present), but not
when the plugin compiles only the classes that have been modified and
that set of classes do not include module-info.java. For example the
following work
touch geoapi/src/main/java9/module-info.java
mvn install -Pjdk9
But maven-compiler-plugin then fails on the next module, unless I touch
the module-info.java of that next module too, /etc./
I will see if I can do a new attempt at creating a minimal test case
later this week.
Martin
[1] https://github.com/opengeospatial/geoapi
Re: maven-compiler-plugin JPMS module resolution
Posted by Robert Scholte <rf...@apache.org>.
Hi Martin,
I am not aware of such problem. Did you create a Jira[1] issue for it?
There should be no reason to have a workaround, all the information is
there so Maven is capable to divide jars properly over both paths. If you
can add a project so I can reproduce the issue, I can have a look at it.
thanks,
Robert
[1] https://issues.apache.org/jira/projects/MCOMPILER
On Wed, 11 Apr 2018 14:24:36 +0200, Martin Desruisseaux
<ma...@geomatys.com> wrote:
> I also have the case where maven-compiler-plugin puts a dependency in
> classpath while it should be in modulepath. Strangely, the plugin does
> the correct thing when executed with "mvn _clean_ install" but not when
> executing "mvn install" without clean. This issue happen only when the
> useIncrementalCompilation option is set to false. In addition the
> javadoc plugin also seems to sometime put dependencies in unexpected
> classpath/modulepath option. A Maven option for specifying whether a
> dependency should be in the classpath or modulepath would be convenient
> as a workaround…
>
> Martin
>
>
> Le 11/04/2018 à 13:14, Roman Grigoriadi a écrit :
>
>> Thanks Robert,
>>
>> I tried to add requires for name which is resolved by JPMS for my
>> non-modularised jar, and it *somehow* made compiler-plugin to put this
>> jar
>> on module-path.
>>
>> However if I don't want to reference this jar in my module descriptor,
>> so I
>> let decision up to user if to put this dependency on CP or MP for app
>> runtime, would it make sense to add configuration parameter for
>> compiler-plugin which will force CP/MP for some of the dependencies
>> during
>> compilation?
>>
>> The best solution I have found so far is to copy such dependencies
>> somewhere before compilation and pass --module-path, --add-modules and
>> --add-reads to javac.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven-compiler-plugin JPMS module resolution
Posted by Martin Desruisseaux <ma...@geomatys.com>.
I also have the case where maven-compiler-plugin puts a dependency in
classpath while it should be in modulepath. Strangely, the plugin does
the correct thing when executed with "mvn _clean_ install" but not when
executing "mvn install" without clean. This issue happen only when the
useIncrementalCompilation option is set to false. In addition the
javadoc plugin also seems to sometime put dependencies in unexpected
classpath/modulepath option. A Maven option for specifying whether a
dependency should be in the classpath or modulepath would be convenient
as a workaround…
Martin
Le 11/04/2018 à 13:14, Roman Grigoriadi a écrit :
> Thanks Robert,
>
> I tried to add requires for name which is resolved by JPMS for my
> non-modularised jar, and it *somehow* made compiler-plugin to put this jar
> on module-path.
>
> However if I don't want to reference this jar in my module descriptor, so I
> let decision up to user if to put this dependency on CP or MP for app
> runtime, would it make sense to add configuration parameter for
> compiler-plugin which will force CP/MP for some of the dependencies during
> compilation?
>
> The best solution I have found so far is to copy such dependencies
> somewhere before compilation and pass --module-path, --add-modules and
> --add-reads to javac.
Re: maven-compiler-plugin JPMS module resolution
Posted by Roman Grigoriadi <ro...@gmail.com>.
Thanks Robert,
I tried to add requires for name which is resolved by JPMS for my
non-modularised jar, and it *somehow* made compiler-plugin to put this jar
on module-path.
However if I don't want to reference this jar in my module descriptor, so I
let decision up to user if to put this dependency on CP or MP for app
runtime, would it make sense to add configuration parameter for
compiler-plugin which will force CP/MP for some of the dependencies during
compilation?
The best solution I have found so far is to copy such dependencies
somewhere before compilation and pass --module-path, --add-modules and
--add-reads to javac.
Thank you,
Roman
On Tue, Apr 10, 2018 at 8:55 PM, Robert Scholte <rf...@apache.org>
wrote:
> Hi
>
> every jar that matches a "requires"-entry of your projects module
> descriptor and all jars that matches the indirect requirements will be
> added to the module-path. The rest will stay on the classpath.
> If you want to do more, you need to verify the JPMS options available for
> java/javac[1]
>
> thanks
> Robert
>
> [1] https://docs.oracle.com/javase/9/tools/javac.htm#JSWOR627
>
>
> On Tue, 10 Apr 2018 16:23:10 +0200, Roman Grigoriadi <
> roman.grigoriadi@gmail.com> wrote:
>
> Hi,
>>
>> I would like to place some of the project dependencies to --module-path to
>> make them automatic "derived name" modules during project compilation. I
>> can see that maven-compiler-plugin:3.7.0 tries to find module-info.class
>> and Automatic-Module-Name entry in MANIFEST. If found it uses those jars
>> as
>> modules.
>>
>> Is there any way I can force placement non-modularized dependencies on
>> module path?
>>
>>
>> Thank you,
>> Roman
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: maven-compiler-plugin JPMS module resolution
Posted by Robert Scholte <rf...@apache.org>.
Hi
every jar that matches a "requires"-entry of your projects module
descriptor and all jars that matches the indirect requirements will be
added to the module-path. The rest will stay on the classpath.
If you want to do more, you need to verify the JPMS options available for
java/javac[1]
thanks
Robert
[1] https://docs.oracle.com/javase/9/tools/javac.htm#JSWOR627
On Tue, 10 Apr 2018 16:23:10 +0200, Roman Grigoriadi
<ro...@gmail.com> wrote:
> Hi,
>
> I would like to place some of the project dependencies to --module-path
> to
> make them automatic "derived name" modules during project compilation. I
> can see that maven-compiler-plugin:3.7.0 tries to find module-info.class
> and Automatic-Module-Name entry in MANIFEST. If found it uses those jars
> as
> modules.
>
> Is there any way I can force placement non-modularized dependencies on
> module path?
>
>
> Thank you,
> Roman
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org