>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.<clinit>(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
