Normally you specify what a provided service in module is. Thus the java
compiler has no reason to look at random files in this directory. In
fact the module info makes it very specific what to look for. That is
why I doubt javac will have a problem, unless specified as not valid.
And I have no indicator of the later.
As I said, the plugin afaik tries to create a module configuration for
groovy. Tthat includes the services it provides or expects. Since this
is automatic, the plugin has to do quite the opposite of javac and every
file in there is potentially defining a service. And from that
perspective it is quite understandable, that anything that is in those
directories is supposed to be a service of some kind and thus should be
exposed. The failure is just in acknowledging, that people do strange
things from your individual pov. For others that strange thing might be
the norm.
But as I said. We have to test if a module X depending on the groovy
module can provide extension methods to groovy using the old mechanism
or not. I suspect it cannot. I suspect a service provider structure will
be required. And then we have to clean up META-INF/services as well.
Am 04.12.2017 um 10:44 schrieb Ceki Gulcu:
Jochen makes a good point regarding the source of the complaint being
Maven rather than the JDK. However, Maven relies on JDK module support
to know how to populate the classpath/modulepath prior to compilation.
It essentially invokes java.lang.module.ModuleFinder.of(path).findAll().
Thus, I suspect that loading groovy-2.4.13,jar would fail anyway but
Maven detects this condition before the java compiler has a chance to
complain.
On 04.12.2017 10:28, Cédric Champeau wrote:
Oh thanks for the clarification, Jochen, I didn't realize the problem
was with Maven itself. I think Maven over-interprets the spec. It's
not because you find a file in `META-INF/services` that it *must* be a
service descriptor.
Now for the extension mechanism, for sure we need to check what it
means for us.
2017-12-04 10:23 GMT+01:00 Jochen Theodorou <blackd...@gmx.org
<mailto:blackd...@gmx.org>>:
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> <mailto: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>
<http://markmail.org/message/obdyvuv24kqpxm6v
<http://markmail.org/message/obdyvuv24kqpxm6v>>
