We planned (originally about a year ago) to have split packaging sorted for 3.0. I didn't have time to get that ready for beta-1. I have it ready now for beta-2. At the time, there were a few options we planned to consider over and above the necessary changes to become compliant with JPMS package naming requirements.
One option was to have all of our preparation complete for Groovy's own module support, do all the renaming of classes and provide a compiler feature to automatically rename affected classes/packages if/when needed. Another option was to have some helper scripts that could convert source files as needed. We certainly haven't finished all work for module support and I believe getting 3.0 out soon is important. So, I am going to suggest we push further module support to 4.0 (and aim to do that earlier) and not claim full support for 3.0. This gives us some further flexibility which is what I have made use of in my changes so far. I have kept but deprecated all the old classes as well as providing the new repackaged classes in the 3.0 code base. The old classes will be removed in 4.0 when we will have compliant artifacts. We always knew there would be a "big" break sometime. This approach allows it to happen over the lifetime of Groovy 3 rather than just upon Groovy 3 adoption. There are some caveats though, we don't really want our APIs to reflect both sets of classes, so you typically would use the old classes together or the new classes together but not arbitrarily mix and match. E.g. If you have some existing XML parsing code which does namespace handling using the legacy QName class, you would use the legacy XmlParser to parse the XML and might use the legacy XmlNodePrinter class to print a node, i.e. nothing would change. When you are ready to use the new QName class, you change your imports for QName, XmlParser and XmlNodePrinter to move to the new versions. The details are in the related Jira[1] and Draft Release Notes[2] but might need further finessing before we release beta-2. As is, all import changes would need to be done manually. We still have the option of making the compiler smarter - though there is some merit in the KISS approach. I have been using Intellij Structural Search and Replace. It does a pretty good job for what I needed for converting some of the Groovy code base over but we could certainly also look at some script to do the conversions. The top 5 classes which have changed are possibly: GroovyTestCase (groovy.util => groovy.test) XmlParser (groovy.util => groovy.xml) XmlSlurper (groovy.util => groovy.xml) AntBuilder (groovy.util => groovy.ant) SwingBuilder (groovy.util => groovy.swing) Let me know if you have any thoughts. Cheers, Paul. [1] https://issues.apache.org/jira/browse/GROOVY-8647 [2] http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages
