On 03.11.2015 22:28, Alex Buckley wrote: [...]
groovy-compiler will obviously have a hard dependency on groovy-base, but you can avoid groovy-base having a hard dependency on groovy-compiler by using services. Of course this assumes a suitable split between the interface of your compiler and its implementation.
and of course that split does not exist ;) It is a difference of not including something and referring to it by reflection, to have it optional; and to have it as a service. The first we can do without bigger changes, the later requires the definition of a whole "new" API.
[...]
One option for the Groovy runtime is to special case its meta class package hierarchy by arranging for g.r.m.** classes to be defined by, and exported from, a special module that the runtime generates; the runtime would set up readability between this module and the user modules that "thought" they were defining and exporting g.r.m.**. You can see a flavor of this technique in the "dynamic module" created by Java's Core Reflection when you proxy certain interfaces -- see "Package and Module Membership of Proxy Class" in http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/reflect/Proxy.html.
will have a look soon, thanks. bye Jochen
