[jira] [Created] (GROOVY-9254) Split package renaming second stage

["Paul King (Jira)" <ji...@apache.org>]

Paul King created GROOVY-9254:
---------------------------------

             Summary: Split package renaming second stage
                 Key: GROOVY-9254
                 URL: https://issues.apache.org/jira/browse/GROOVY-9254
             Project: Groovy
          Issue Type: Task
            Reporter: Paul King
            Assignee: Paul King
             Fix For: 3.0.0-beta-2


This is the list of changes which need to be made to avoid split packages. As a separate issue, we should outline what compiler (or other) changes might be made that would allow (some of) these changes to occur without breaking source compatibility. Possibilities include:
 * a separate tool to add/change imports
 * some mechanism to define additional default imports per module
 * automatic renaming by the compiler from old to new package names (enabled by a switch)
 * add deprecated delegates for existing classes which point to the new versions
 * some classloading trick to rename packages on the fly when loaded (will Java9+ allow this?)

*Adjustments by module*

groovy:
* -copy groovy.xml.QName to groovy.namespace.QName and deprecate original-

groovy-ant:
* -copy groovy.util to groovy.ant and deprecate original-

groovy-console:
* -copy groovy.inspect to groovy.console and deprecate original-
* -copy groovy.inspect.swingui to groovy.console.ui and deprecate original-
* -copy groovy.ui groovy.console.ui and deprecate original-

groovy-groovysh:
* -copy org.codehaus.groovy.tools.shell to org.apache.groovy.groovysh and deprecate original-

groovy-jmx:
* -copy groovy.util.GroovyMBean to groovy.jmx and deprecate original-

groovy-nio:
* -copy org.codehaus.groovy.runtime.WritablePath to org.apache.groovy.nio.runtime and deprecate original-
* -copy org.codehaus.groovy.runtime.NioGroovyMethods to org.apache.groovy.nio.extensions.NioExtensions and deprecate original-

groovy-swing:
* -copy org.codehaus.groovy.binding to org.apache.groovy.swing.binding and deprecate original-
* -copy org.codehaus.groovy.runtime.SwingGroovyMethods to org.apache.groovy.swing.extensions.SwingExtensions and deprecate original-
* -copy groovy.model to groovy.swing.model and deprecate original-
* -copy groovy.inspect.swingui to org.apache.groovy.swing.table and deprecate original-

groovy-test:
* -copy groovy.transform.NotYetImplemented to groovy.test and deprecate the original-
* -copy org.codehaus.groovy.runtime.ScriptTestAdatper to org.apache.groovy.test and deprecate the original-
* -copy classes from groovy.util to groovy.test and deprecate originals-
* -copy classes from groovy.lang to groovy.test and deprecate originals-

groovy-xml:
* -copy groovy.util to groovy.xml and deprecate originals-
* -copy org.codehaus.groovy.tools.xml.DomToGroovy to org.apache.groovy.xml.tools and deprecate original-
* -copy org.codehaus.groovy.runtime.XmlGroovyMethods to org.apache.groovy.xml.extensions.XmlExtensions and deprecate original-

Specific remaining questions:
 * should {{groovy.ant}} or {{groovy.ant.AntBuilder}} be an automatic import? Currently the assumption is that it is no longer automatic.
 * should {{groovy.test}} or {{groovy.test.GroovyTestCase}} be an automatic import? Currently the assumption is that it is no longer automatic.
* should {{groovy.xml}} or {{groovy.xml.XmlSlurper}} or {{groovy.xml.XmlParser}} be an automatic import? Currently the assumption is that it is no longer automatic.


 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)