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/09/01 01:20:15 UTC
Move global transforms from META-INF/services to META-INF/groovy
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.
We already did this for valid source file extensions.
Obviously, the old location will be kept for backwards compatibility for
some time.
See:
https://issues.apache.org/jira/browse/GROOVY-8771
https://github.com/apache/groovy/pull/791
Cheers, Paul.
Re: Move global transforms from META-INF/services to META-INF/groovy
Posted by Guillaume Laforge <gl...@gmail.com>.
Sounds good!
On Sat, Sep 1, 2018 at 5:21 AM Daniel.Sun <su...@apache.org> wrote:
> +1
>
>
>
> -----
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Twitter: @glaforge <http://twitter.com/glaforge>
Re: Move global transforms from META-INF/services to
META-INF/groovy
Posted by "Daniel.Sun" <su...@apache.org>.
+1
-----
Daniel Sun
Apache Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Move global transforms from META-INF/services to META-INF/groovy
Posted by Paul King <pa...@asert.com.au>.
Okay, will leave things as they are for now. It will make the OSGi tweaks
we do to the build somewhat uglier but we can live with that for now.
All other non-conforming files are already out of META-INF/services. These
are the only files in that directory that we have that don't use a service
loader.
I guess when we get back to re-working the JDK9+ changes we can look at
this again if needed.
Cheers, Paul.
On Sun, Sep 2, 2018 at 1:12 AM Andres Almiray <aa...@gmail.com> wrote:
> 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 <pa...@asert.com.au> 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 <aa...@gmail.com> 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 <bl...@gmx.org> 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
>>
>
Re: Move global transforms from META-INF/services to META-INF/groovy
Posted by Andres Almiray <aa...@gmail.com>.
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 <pa...@asert.com.au> 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 <aa...@gmail.com> 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 <bl...@gmx.org> 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
Re: Move global transforms from META-INF/services to META-INF/groovy
Posted by Paul King <pa...@asert.com.au>.
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 <aa...@gmail.com> 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 <bl...@gmx.org> 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
>
Re: Move global transforms from META-INF/services to META-INF/groovy
Posted by Andres Almiray <aa...@gmail.com>.
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 <bl...@gmx.org> 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
Re: Move global transforms from META-INF/services to META-INF/groovy
Posted by Jochen Theodorou <bl...@gmx.org>.
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