groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <>
Subject Re: Loading groovy as a Jigsaw auto-module
Date Wed, 14 Feb 2018 02:34:34 GMT
Any objections if I look into moving the Extensions file from
META-INF/services to META-INF/groovy (with a fallback to the current one).
But not for 2.4.x.

Cheers, Paul.

On Mon, Dec 4, 2017 at 9:54 PM, Jochen Theodorou <> wrote:

> 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 < <mailto:
>>>     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