groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: Loading groovy as a Jigsaw auto-module
Date Mon, 04 Dec 2017 11:54:46 GMT
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 < 
>> <>>:
>>     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 <
>>         <> < <>>>:
>>              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]
>>         <>
>>              <
>>         <>>

View raw message