groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andres Almiray <>
Subject Re: Move global transforms from META-INF/services to META-INF/groovy
Date Sat, 01 Sep 2018 15:12:06 GMT
I see. Well. Given the short explanation found at GROOVY-8766 I’d say there is no need to
move the files currently found at META-INF/services as OSGi is not the primary environment.

This being said, additional manifest entries to make Groovy work better with OSGi are OK.

What really causes trouble with ServiceLoader regardless of OSGi or not is the fact that we
used META-INf/services for Groovy extension module definitions which do not adhere to the
rules that all files under that directory must follow. We’ve discussed this topic before
and I believe the agreement was to move only these files to a different location. 

AST xform files found under META-INF/services are indeed services, to the Groovy compiler.


Sent from my primitive Tricorder

> On 1 Sep 2018, at 15:17, Paul King <> wrote:
> It's not our own JDK9+ integration that I am concerned with in the first instance. It's
actually Maven and OSGi where our non-standard location is currently problematic which is
behind my current desire for this change.
> The most recent was just our own fix in our build where we would have to step around
the non-uniform location when creating the right OSGi MANIFEST information, see GROOVY-8766
and the related proposed PR.
> It will subsequently make life easier for us on our JDK9+ journey I suspect but as Jochen
says, we might have to make additional changes there anyway.
>> On Sat, Sep 1, 2018 at 10:52 PM Andres Almiray <> wrote:
>> I’d rather keep the files where they are unless they stand in the way for Java9+
>> Sent from my primitive Tricorder
>> > On 1 Sep 2018, at 11:05, Jochen Theodorou <> wrote:
>> > 
>> >> On 01.09.2018 03:20, Paul King wrote:
>> >> I plan to move the default location to look for org.codehaus.groovy.transform.ASTTransformation
from META-INF/services to META-INF/groovy since the class(es) mentioned in that file aren't
service(s) in the normal Java sense.
>> > 
>> > basically good to conform with the Java9 understanding of what should be in
services and what not... BUT... if we think about Java9 modules then this might not be good
enough I am afraid. If we really want a library X in a different module than Groovy itself,
then X cannot expose transformation information files by putting them in META-INF/groovy.
We will not have access to that. Instead we have to go the full SPI approach here
>> > 
>> > bye Jochen

View raw message