[jira] [Resolved] (GROOVY-8647) Split package renaming

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

     [ https://issues.apache.org/jira/browse/GROOVY-8647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul King resolved GROOVY-8647.
-------------------------------
       Resolution: Fixed
    Fix Version/s: 3.0.0-beta-2

First part complete - final removal and extra tools can be in separate issues.

> Split package renaming
> ----------------------
>
>                 Key: GROOVY-8647
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8647
>             Project: Groovy
>          Issue Type: Task
>            Reporter: Paul King
>            Assignee: Paul King
>            Priority: Major
>             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
(v7.6.14#76016)