On 27.11.2015 09:24, Cédric Champeau wrote:
2015-11-26 23:58 GMT+01:00 Jeff MAURY <[email protected] <mailto:[email protected]>>: +1 for Jesper proposition with the modification that 2 being groovy-all.jar with binary compatibility but also a Jigsaw module. So we could have: Groovy 3.x: several Jigsaw module refactored Groovy 2.x: same packaging with groovy-all being a stand alone Jigsaw module. I think that's more or less strictly equivalent to the current situation: Groovy 2 "groovy-all" being a jigsaw module can be as simple as exporting all packages. And we don't even have to: just put the jar on classpath and it's done. The problem comes as soon as we want to restrict some things to internal packages.
That's not fully right. Being on the classpath only means we will then be in the unnamed module. Other modules have then no way of exporting their internals to groovy (well, I think there are ways at runtime, but I am not sure). Which means groovy cannot call methods in those packages, which means those modules cannot be written in Groovy... at least that is how I do understand things.
Today, all the Groovy classes are exposed. Everything belongs, de facto, to the public API.
Well, we did not even really try to prevent this in the past. The mess could have been lowered with a more restrictive package named based convention.
bye blackdrag
