You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Paul King <pa...@asert.com.au> on 2018/02/14 02:34:34 UTC
Re: Loading groovy as a Jigsaw auto-module
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 <bl...@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
>> 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 <blackdrag@gmx.org <mailto:
>>> blackdrag@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 <ceki@qos.ch
>>> <ma...@qos.ch> <mailto:ceki@qos.ch <ma...@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>>
>>>
>>>
>>>
>>>
Re: Loading groovy as a Jigsaw auto-module
Posted by Jochen Theodorou <bl...@gmx.org>.
Hi,
Everything in META-INF/service has to move, unless it is following the
SPI structure.
But just us moving will not allow Groovy libraries to define extension
methods sadly.
Am 22.02.2018 um 10:56 schrieb Paul King:
> After moving the Extensions file, it looks like the only other file in
> Cédric's list that causes Java 9's ModuleFinder a problem is Groovy's
> extension module file:
> META-INF/services/org.codehaus.groovy.runtime.ExtensionModule
>
> I'll also see what is involved in moving that (with a fallback to the
> current location).
>
> Cheers, Paul.
>
> On Thu, Feb 15, 2018 at 3:49 AM, Jochen Theodorou <blackdrag@gmx.org
> <ma...@gmx.org>> wrote:
>
>
> Am 14.02.2018 um 03:34 schrieb Paul King:
>
> 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.
>
>
> in the meantime I know that META-INF/services has been reserved for
> the normal purposes and everything else is indeed not valid. You can
> find this in some javadoc comment on some class... somewhere. I can
> look for it again if you want to (of course that is java9+ only)
>
> I still think a groovy library as module will not be able to expose
> its extension methods this way, which means we will most probably
> not even be able to keep the file and will have to move to a SPI
> structure... but moving to META-INF/groovy is probably a good first step
>
> bye Jochen
>
>
Re: Loading groovy as a Jigsaw auto-module
Posted by Paul King <pa...@asert.com.au>.
After moving the Extensions file, it looks like the only other file in
Cédric's list that causes Java 9's ModuleFinder a problem is Groovy's
extension module file:
META-INF/services/org.codehaus.groovy.runtime.ExtensionModule
I'll also see what is involved in moving that (with a fallback to the
current location).
Cheers, Paul.
On Thu, Feb 15, 2018 at 3:49 AM, Jochen Theodorou <bl...@gmx.org> wrote:
>
> Am 14.02.2018 um 03:34 schrieb Paul King:
>
>> 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.
>>
>
> in the meantime I know that META-INF/services has been reserved for the
> normal purposes and everything else is indeed not valid. You can find this
> in some javadoc comment on some class... somewhere. I can look for it again
> if you want to (of course that is java9+ only)
>
> I still think a groovy library as module will not be able to expose its
> extension methods this way, which means we will most probably not even be
> able to keep the file and will have to move to a SPI structure... but
> moving to META-INF/groovy is probably a good first step
>
> bye Jochen
>
Re: Loading groovy as a Jigsaw auto-module
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 14.02.2018 um 03:34 schrieb Paul King:
> 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.
in the meantime I know that META-INF/services has been reserved for the
normal purposes and everything else is indeed not valid. You can find
this in some javadoc comment on some class... somewhere. I can look for
it again if you want to (of course that is java9+ only)
I still think a groovy library as module will not be able to expose its
extension methods this way, which means we will most probably not even
be able to keep the file and will have to move to a SPI structure... but
moving to META-INF/groovy is probably a good first step
bye Jochen