maven-compiler-plugin JPMS module resolution

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

maven-compiler-plugin JPMS module resolution

Roman Grigoriadi
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
Reply | Threaded
Open this post in threaded view
|

Re: maven-compiler-plugin JPMS module resolution

rfscholte
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  
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven-compiler-plugin JPMS module resolution

Roman Grigoriadi
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 <[hidden email]>
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 <
> [hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: maven-compiler-plugin JPMS module resolution

Martin Desruisseaux
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.

Reply | Threaded
Open this post in threaded view
|

Re: maven-compiler-plugin JPMS module resolution

rfscholte
In reply to this post by Roman Grigoriadi
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  
<[hidden email]> 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 <[hidden email]>
> 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 <
>> [hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven-compiler-plugin JPMS module resolution

rfscholte
In reply to this post by Martin Desruisseaux
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  
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven-compiler-plugin JPMS module resolution

Martin Desruisseaux
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


Reply | Threaded
Open this post in threaded view
|

Re: maven-compiler-plugin JPMS module resolution

Martin Desruisseaux
In reply to this post by rfscholte
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven-compiler-plugin JPMS module resolution

Roman Grigoriadi
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 <
[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: maven-compiler-plugin JPMS module resolution

rfscholte
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  
<[hidden email]> 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 <
> [hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven-compiler-plugin JPMS module resolution

Roman Grigoriadi
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 <[hidden email]>
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 <
> [hidden email]> 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 <
>> [hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: maven-compiler-plugin JPMS module resolution

rfscholte
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  
<[hidden email]> 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 <[hidden email]>
> 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 <
>> [hidden email]> 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 <
>>> [hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven-compiler-plugin JPMS module resolution

Roman Grigoriadi
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 <[hidden email]>
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 <
> [hidden email]> 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 <[hidden email]>
>> 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 <
>>> [hidden email]> 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 <
>>>> [hidden email]> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: maven-compiler-plugin JPMS module resolution

rfscholte
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  
<[hidden email]> 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 <[hidden email]>
> 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 <
>> [hidden email]> 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 <[hidden email]>
>>> 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 <
>>>> [hidden email]> 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 <
>>>>> [hidden email]> 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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]