Re[2]: Force JPMS to add module to boot layer

[Alex Orlov]

 
>net/bytebuddy/NamingStrategy$SuffixingRandom$BaseNameResolver
> at
>org.hibernate.cfg.Environment.buildBytecodeProvider(Environment.java:345)
>~[hibernate-core-5.4.15.Final.jar:?]
> at
>org.hibernate.cfg.Environment.buildBytecodeProvider(Environment.java:337)
>~[hibernate-core-5.4.15.Final.jar:?]
> at org.hibernate.cfg.Environment.(Environment.java:230)
>~[hibernate-core-5.4.15.Final.jar:?]
>
> From what I can establish, org.hibernate.orm.core is an automatic
>module so it doesn't have any way to `requires net.bytebuddy` (an
>explicit module). You'll have to help out by adding `--add-modules
>net.bytebuddy` to the command line that surefire or failsafe uses.
 
Yes, and this is the work that I say is very silly. We add modules to module
path, but JPMS IGNORES THEM. It is obvious that it was a wrong solution
to let JPMS solve what modules it should add to layer and what modules 
shouldn’t.
 
AND I AM SURE EVERYONE WILL AGREE WITH ME.
 
Again — if any automatization is implemented there must be a possibility
to switch it off. Just imagine a plane with autopilot that can’t be disabled.
We have the same here. Someone implemented feature that we must
be able to turn off.
 
So, if I open a feature request to add flag to disable JPMS ignoring not
used modules, will you support it? By others words should I spend
my time on it?
 
Before answering, just imagine, how many developers in the world will
do this silly work when they add modules to module path, but JPMS will
ignore them.
 
Best regards,
 
 
>I can't explain why you don't see issues when you use module layers. It
>is possible that you've specified "net.bytebuddy" in the list of root
>modules that you specify to the resolve method?
>
>-Alan 
 
 
--
Alex Orlov
 

Fwd: Force JPMS to add module to boot layer

[Christian Stein]

On Sun, Jun 21, 2020 at 8:55 PM Alex Orlov  wrote:

>
> Hi all,
>
> New version of maven-failsafe-plugin (3.0.0-M5) has been released and now
> it is possible to have two module-info in one
> project — one in src/main/java and one in src/test/java  and to test
> modules on module -path.
> [...]


Support for the Java module system was included in Maven
Surefire/Failsafe (SF/FS) recently. As you noted, in version 3.0.0-M5.
There are for sure some short-comings, missing features,
and also plain bugs in the implementation of SF/FS. See this
recent discussion as an example: [1733] You're very welcome
to test-drive and propose fixes for SF/FS.

Java modules are declared by developers – no build tool can 100%
correctly guess what should be included (exported, opened, ...)
in a Java module. This goes for modules at (Maven) tests alike.
And it surely goes for setting up the module-path and the class-path
at test runtime. I invite you to read [1] and look at this sample
Maven project that show-cases most combinations of "intra-module"
and "extra-modular" testing [2].

 AND I AM SURE EVERYONE WILL AGREE WITH ME.


No.

Cheers,
Christian

PS: Just a blind guess, did you already try to pass

 --add-modules=ALL-MODULE-PATH

to the SF/FS runtime?

1733:
https://issues.apache.org/jira/browse/SUREFIRE-1733?focusedCommentId=17142664=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17142664
1: https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world

2: https://github.com/micromata/sawdust

Re: Force JPMS to add module to boot layer

[Alex Buckley]

On 6/23/2020 9:31 AM, Alex Orlov wrote:

From what I can establish, org.hibernate.orm.core is an automatic
module so it doesn't have any way to `requires net.bytebuddy` (an
explicit module). You'll have to help out by adding `--add-modules
net.bytebuddy` to the command line that surefire or failsafe uses.
  
Yes, and this is the work that I say is very silly. We add modules to module

path, but JPMS IGNORES THEM. It is obvious that it was a wrong solution
to let JPMS solve what modules it should add to layer and what modules 
shouldn’t.


The module path is not like the class path. The class path is chaos; the 
module path is order. Think of the module path as a repository that 
contains tens, hundreds, thousands of modules, all of which sit silently 
until one is required by some module, or resolved due to `--add-modules`.


You're asking the JDK team how to use the ORM core of Hibernate as an 
automatic module. What did the Hibernate team say what you asked them?


Alex

Re: Force JPMS to add module to boot layer

[Alan Bateman]

On 22/06/2020 18:15, Alex Orlov wrote:

Hi Alan,
Thank you very much for your answer. In order to be concrete a test 
project was created

and it is here https://github.com/PashaTurok/hibernate-h2-test4
Besides, if it is not very difficult for you, could you answer 
separately to

each questions (# 1 and #2). So, I repeat them again:
1) Is it possible to force JPMS to add modules even if it think that 
they won’t be used

(by the way — nobody asks it).
2) As I understand this problem doesn’t appear when we create child 
layer and add any jars to it.

In this case JPMS doesn’t ignore any modules. Is this statement right?

java.lang.NoClassDefFoundError: 
net/bytebuddy/NamingStrategy$SuffixingRandom$BaseNameResolver
    at 
org.hibernate.cfg.Environment.buildBytecodeProvider(Environment.java:345) 
~[hibernate-core-5.4.15.Final.jar:?]
    at 
org.hibernate.cfg.Environment.buildBytecodeProvider(Environment.java:337) 
~[hibernate-core-5.4.15.Final.jar:?]
    at org.hibernate.cfg.Environment.(Environment.java:230) 
~[hibernate-core-5.4.15.Final.jar:?]


From what I can establish, org.hibernate.orm.core is an automatic 
module so it doesn't have any way to `requires net.bytebuddy` (an 
explicit module). You'll have to help out by adding `--add-modules 
net.bytebuddy` to the command line that surefire or failsafe uses.


I can't explain why you don't see issues when you use module layers. It 
is possible that you've specified "net.bytebuddy" in the list of root 
modules that you specify to the resolve method?


-Alan