> > > > So what is the background to this thread, are you running into a split > package issue when trying to migrate something to modules? > > -Alan > I cannot speak for Jochen but at least this is something we have been discussing for a long time on the Groovy MLs since we know Jigsaw will prevent split packages. Basically our problem is binary backwards compatibility. Groovy has a long history, so before Groovy 2.0, everything was found in a single jar. We provided several versions of Groovy (we still do), but that is more a dependency management issue.
The real problem is more that after Groovy 2 we started splitting Groovy into different jars. But for backwards compatibility we didn't change the packages. So you can find classes in package groovy.util in both the `groovy-core` jar and the `groovy-xml` jar. Those jars would be obvious candidates for modules but as split packages are not allowed this is not possible. This doesn't give us many options. I was in favor of breaking everything, since Jigsaw is a long journey in any case, and leverage that to have Groovy 3 use different packages. Of course not everybody is happy with this, because it's a huge issue for all existing libraries that rely on "old" packages. We would basically break every Groovy program out there. Both at the source and binary level. It's a very big issue, typically all Gradle plugins written in Groovy would break. Gradle itself would break. There are things to mitigate that, like rewriting classes at load time, or an easier solution which is to have a single Groovy module for all (and come back to the monolith era, sigh...). We haven't made any decision yet. Not something we can take easy.
