Just to clarify things... This is a maven plugin complaining, not JDK9,
as I see it. Afaik the plugin tries to create a module configuration for
groovy and cannot interpret the services provided in those directories.
JDK9 would not care, unless you say your module is providing a certain
service.
And I want to add two more points: The extension mechanism is unlikely
to work as intended on JDK9. If you want to provide a service across
modules you are now forced to use the very doubtful ServiceProvider
infrastructure. And one module to read a file from another module was at
least till late stages of JDK9 not possible. I am not sure what the
latest state here was. Maybe I did interpret something wrong - writing a
test for this would be easy.
But if I am right, this would mean our extension mechanism must become a
SPI structure to enable other modules to provide extension modules.
Am 03.12.2017 um 19:01 schrieb Cédric Champeau:
This file is used by Groovy internally, there's no reason for the JDK to
interpret its contents since it has only a meaning for Groovy. In short,
it declares the list of extensions recognized by the Groovy compiler.
That it prevents loading as a module is rather strange.
2017-12-03 16:37 GMT+01:00 Ceki Gulcu <c...@qos.ch <mailto:c...@qos.ch>>:
Hi all,
Referring to a discussion on the maven users list [1], it appears that
removing the file
META-INF/services/org.codehaus.groovy.source.Extensions from
groovy-2.4.13.jar allows Java 9 to successfully load
groovy-2.4.13.jar as an auto-module.
The org.codehaus.groovy.source.Extensions file contains the lone
word "groovy" instead of a fully qualified class name.
Please advise.
Best regards,
--
Ceki Gülcü
[1] http://markmail.org/message/obdyvuv24kqpxm6v
<http://markmail.org/message/obdyvuv24kqpxm6v>
