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