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