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.
On Mon, Dec 4, 2017 at 9:54 PM, Jochen Theodorou <blackd...@gmx.org> 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
>> 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
>>> 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:
>>> 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
>>> 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 , it
>>> appears that
>>> removing the file
>>> 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
>>> word "groovy" instead of a fully qualified class name.
>>> Please advise.
>>> Best regards,
>>> Ceki Gülcü
>>>  http://markmail.org/message/obdyvuv24kqpxm6v