Split packaging changes for Groovy 3

[Paul King <pa...@asert.com.au>]

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