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 <roman.grigori...@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 <rfscho...@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.grigori...@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 <rfscho...@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.grigori...@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.desruisse...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to