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. Cheers Andres Sent from my primitive Tricorder > On 1 Sep 2018, at 15:17, Paul King <[email protected]> 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 <[email protected]> wrote: >> I’d rather keep the files where they are unless they stand in the way for >> Java9+ integration. >> >> Sent from my primitive Tricorder >> >> > On 1 Sep 2018, at 11:05, Jochen Theodorou <[email protected]> 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
