add a missing breaking change (more still missing)
diff --git a/site/src/site/releasenotes/groovy-3.0.adoc b/site/src/site/releasenotes/groovy-3.0.adoc
index da06bef..4e6e706 100644
--- a/site/src/site/releasenotes/groovy-3.0.adoc
+++ b/site/src/site/releasenotes/groovy-3.0.adoc
@@ -558,129 +558,6 @@
The old parser is deprecated and will be removed in Groovy 4.
|===
-[[Groovy3.0releasenotes-Splitpackages]]
-== Split package changes (from beta-2)
-
-The Java Platform Module System requires that classes in distinct modules
-have distinct package names. Groovy has it's own "modules" but these haven't
-historically been structured according to the above requirement.
-For this reason, Groovy 2.x and 3.0 should be added to the classpath not module path
-when using JDK9+. This places Groovy's classes into the unnamed module
-where the split package naming requirement is not enforced.
-
-Groovy 3 is making changes to allow the codebase to move towards the compliant
-rules and allow Groovy users to begin the migration process.
-Groovy 4 is our target version for fully-compliant artifacts but you can
-start getting your classes ready ahead of time while using Groovy 3.
-
-As part of this change, some classes are moving packages.
-In a subset of those moved classes, it makes sense
-for Groovy 3 to have two copies of such classes:
-
-* a deprecated class having the old package name
-* a new class having the new package name
-
-This can aid with migration. In many cases, you will be able to recompile
-existing Groovy classes without change and they will use the old versions of the
-classes. You may notice deprecation warnings depending on how you edit classes.
-You should migrate as soon as convenient since your classes may no longer compile under Groovy 4
-if you haven't migrated to the new class location.
-Be aware that in some cases, some work is required even under Groovy 3.
-Read the _Notes_ column in the table below for further details.
-
-[cols="1a,1a,2a"]
-|===
-|Original class/package name
-(3.0 and lower if applicable)
-|New copied class/package name +
-(3.0 and above)
-|Notes
-3+^| *Module: groovy*
-| groovy.xml.QName
-| groovy.namespace
-| You need to migrate to using the new class at the same time as you migrate to affected modules
-using that class as a parameter in methods including `groovy-ant` and `groovy-xml` but only if you
-are using methods with `QName` parameters. You can continue to use the legacy class in your existing
-code or with the legacy versions of affected classes until Groovy 4.
-3+^| *Module: groovy-ant*
-| groovy.util
-| groovy.ant
-| Add an `import groovy.ant.AntBuilder` to classes/scripts
-using `AntBuilder` or you will still be using the deprecated version.
-3+^| *Module: groovy-console*
-| groovy.ui.ConsoleApplet
-| N/A
-| The `java.applet` API is deprecated. No replacement is planned for this Groovy class in Groovy 4.
-| groovy.inspect
-| groovy.console
-.3+| `groovyConsole` is normally used as a command-line tool and its use in that form is unaffected.
- If you use any of the classes directly you can use the old versions until you migrate.
- You should not mix and match old and new classes.
-| groovy.inspect.swingui
-| groovy.console.ui
-| groovy.ui
-| groovy.console.ui
-3+^| *Module: groovy-groovysh*
-| org.codehaus.groovy.tools.shell
-| org.apache.groovy.groovysh
-| `groovysh` is normally used as a command-line tool and its use in that form is unaffected.
-If you use any of the classes directly you can use the old versions until you migrate.
-You should not mix and match old and new classes.
-3+^| *Module: groovy-jmx*
-| groovy.util.GroovyMBean
-| groovy.jmx
-| You need to add the import for `GroovyMBean` before Groovy 4.
-Feel free to use the old class in your own code but `JmxBuilder` only uses the new class.
-You should not mix the old and new classes.
-3+^| *Module: groovy-nio*
-| org.codehaus.groovy.runtime. +
-NioGroovyMethods | org.apache.groovy.nio.extensions. +
-NioExtensions | In normal use, related extension methods will simply be automatically available from the new location.
-| org.codehaus.groovy.runtime. +
-WritablePath |org.apache.groovy.nio.runtime
-| We recommend that you reference `WritablePath` via its interfaces in which case you have nothing to do.
-If you must reference the class, we recommend changing imports and recompiling all affected classes.
-If this is difficult, you can use the old class (and directly use the related `NioGroovyMethods` methods)
-until you are ready to migrate.
-You should not mix and match old and new classes.
-3+^| *Module: groovy-swing*
-| org.codehaus.groovy.binding
-| org.apache.groovy.swing.binding
-.3+| You can continue to use the old classes if you use them in your existing code or from within legacy classes still
-using the old classes. `SwingBuilder` now uses the new classes.
-| groovy.model
-| groovy.swing.model
-| groovy.inspect.swingui
-| org.apache.groovy.swing.table
-3+^| *Module: groovy-test*
-| org.codehaus.groovy.runtime. +
-ScriptTestAdapter
-| org.apache.groovy.test
-| The old class remains available for use in your own classes if already in use
-but won't be recognized by Groovy 3's JUnit-related test suite classes.
-| groovy.transform. +
-NotYetImplemented
-| groovy.test. +
-NotYetImplemented
-| Both point to the (moved but otherwise unchanged) AST transform class.
-| groovy.util
-| groovy.test
-.2+| For classes like `GroovyTestCase`, you need to import `groovy.test.GroovyTestCase` to not
-get the deprecated version. You will need to do this before Groovy 4.
-| groovy.lang
-| groovy.test
-3+^| *Module: groovy-xml*
-| groovy.util
-| groovy.xml
-| For classes like `XmlParser` and `XmlSlurper`, you need to import `groovy.xml.XmlParser` and `groovy.xml.XmlSlurper` respectively to not
- get the deprecated versions. You will need to do this before Groovy 4. If you are using `groovy.xml.XmlUtil.serialize` on a
- `groovy.util.slurpersupport.GPathResult`, you will need to swap to using the deprecated methods in `groovy.util.XmlUtil` since
- `groovy.xml.XmlUtil` only handles the new classes.
-| org.codehaus.groovy.tools.xml.DomToGroovy
-| org.apache.groovy.xml.tools
-|
-|===
-
[[Groovy3.0releasenotes-GDKimprovements]]
== GDK improvements
@@ -807,6 +684,135 @@
Groovy has been improving JSR-308 support over recent versions.
As part of implementing the new grammar, additional support has been added.
+[[Groovy3.0releasenotes-Splitpackages]]
+== Split package changes (from beta-2)
+
+The Java Platform Module System requires that classes in distinct modules
+have distinct package names. Groovy has it's own "modules" but these haven't
+historically been structured according to the above requirement.
+For this reason, Groovy 2.x and 3.0 should be added to the classpath not module path
+when using JDK9+. This places Groovy's classes into the unnamed module
+where the split package naming requirement is not enforced.
+
+Groovy 3 is making changes to allow the codebase to move towards the compliant
+rules and allow Groovy users to begin the migration process.
+Groovy 4 is our target version for fully-compliant artifacts but you can
+start getting your classes ready ahead of time while using Groovy 3.
+
+As part of this change, some classes are moving packages.
+In a subset of those moved classes, it makes sense
+for Groovy 3 to have two copies of such classes:
+
+* a deprecated class having the old package name
+* a new class having the new package name
+
+This can aid with migration. In many cases, you will be able to recompile
+existing Groovy classes without change and they will use the old versions of the
+classes. You may notice deprecation warnings depending on how you edit classes.
+You should migrate as soon as convenient since your classes may no longer compile under Groovy 4
+if you haven't migrated to the new class location.
+Be aware that in some cases, some work is required even under Groovy 3.
+Read the _Notes_ column in the table below for further details.
+
+[cols="1a,1a,2a"]
+|===
+|Original class/package name
+(3.0 and lower if applicable)
+|New copied class/package name +
+(3.0 and above)
+|Notes
+3+^| *Module: groovy*
+| groovy.xml.QName
+| groovy.namespace
+| You need to migrate to using the new class at the same time as you migrate to affected modules
+using that class as a parameter in methods including `groovy-ant` and `groovy-xml` but only if you
+are using methods with `QName` parameters. You can continue to use the legacy class in your existing
+code or with the legacy versions of affected classes until Groovy 4.
+3+^| *Module: groovy-ant*
+| groovy.util
+| groovy.ant
+| Add an `import groovy.ant.AntBuilder` to classes/scripts
+using `AntBuilder` or you will still be using the deprecated version.
+3+^| *Module: groovy-console*
+| groovy.ui.ConsoleApplet
+| N/A
+| The `java.applet` API is deprecated. No replacement is planned for this Groovy class in Groovy 4.
+| groovy.inspect
+| groovy.console
+.3+| `groovyConsole` is normally used as a command-line tool and its use in that form is unaffected.
+If you use any of the classes directly you can use the old versions until you migrate.
+You should not mix and match old and new classes.
+| groovy.inspect.swingui
+| groovy.console.ui
+| groovy.ui
+| groovy.console.ui
+3+^| *Module: groovy-groovysh*
+| org.codehaus.groovy.tools.shell
+| org.apache.groovy.groovysh
+| `groovysh` is normally used as a command-line tool and its use in that form is unaffected.
+If you use any of the classes directly you can use the old versions until you migrate.
+You should not mix and match old and new classes.
+3+^| *Module: groovy-jmx*
+| groovy.util.GroovyMBean
+| groovy.jmx
+| You need to add the import for `GroovyMBean` before Groovy 4.
+Feel free to use the old class in your own code but `JmxBuilder` only uses the new class.
+You should not mix the old and new classes.
+3+^| *Module: groovy-nio*
+| org.codehaus.groovy.runtime. +
+NioGroovyMethods | org.apache.groovy.nio.extensions. +
+NioExtensions | In normal use, related extension methods will simply be automatically available from the new location.
+| org.codehaus.groovy.runtime. +
+WritablePath |org.apache.groovy.nio.runtime
+| We recommend that you reference `WritablePath` via its interfaces in which case you have nothing to do.
+If you must reference the class, we recommend changing imports and recompiling all affected classes.
+If this is difficult, you can use the old class (and directly use the related `NioGroovyMethods` methods)
+until you are ready to migrate.
+You should not mix and match old and new classes.
+3+^| *Module: groovy-swing*
+| org.codehaus.groovy.binding
+| org.apache.groovy.swing.binding
+.3+| You can continue to use the old classes if you use them in your existing code or from within legacy classes still
+using the old classes. `SwingBuilder` now uses the new classes.
+| groovy.model
+| groovy.swing.model
+| groovy.inspect.swingui
+| org.apache.groovy.swing.table
+3+^| *Module: groovy-test*
+| org.codehaus.groovy.runtime. +
+ScriptTestAdapter
+| org.apache.groovy.test
+| The old class remains available for use in your own classes if already in use
+but won't be recognized by Groovy 3's JUnit-related test suite classes.
+| groovy.transform. +
+NotYetImplemented
+| groovy.test. +
+NotYetImplemented
+| Both point to the (moved but otherwise unchanged) AST transform class.
+| groovy.util
+| groovy.test
+.2+| For classes like `GroovyTestCase`, you need to import `groovy.test.GroovyTestCase` to not
+get the deprecated version. You will need to do this before Groovy 4.
+| groovy.lang
+| groovy.test
+3+^| *Module: groovy-xml*
+| groovy.util
+| groovy.xml
+| For classes like `XmlParser` and `XmlSlurper`, you need to import `groovy.xml.XmlParser` and `groovy.xml.XmlSlurper` respectively to not
+get the deprecated versions. You will need to do this before Groovy 4. If you are using `groovy.xml.XmlUtil.serialize` on a
+ `groovy.util.slurpersupport.GPathResult`, you will need to swap to using the deprecated methods in `groovy.util.XmlUtil` since
+ `groovy.xml.XmlUtil` only handles the new classes.
+| org.codehaus.groovy.tools.xml.DomToGroovy
+| org.apache.groovy.xml.tools
+|
+|===
+
+== Other breaking changes
+In addition to the split package changes, the following other breaking changes exist:
+
+* For JDK13+ users, consider using `stripIndent(true)` instead of `stripIndent()`
+(link:https://issues.apache.org/jira/browse/GROOVY-9423[GROOVY-9423])
+
== JDK requirements
Groovy 3.0 requires JDK9+ to build and JDK8 is the minimum version of the JRE that we support.
