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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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

JIRA jira@apache.org

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

Paul King updated GROOVY-8647:
------------------------------
    Description:
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:
 rename groovy.xml.QName to groovy.lang.QName

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-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:
 rename org.codehaus.groovy.binding to org.apache.groovy.swing.binding
 -copy org.codehaus.groovy.runtime.SwingGroovyMethods to org.apache.groovy.swing.extensions.SwingExtensions and deprecate original-
 rename groovy.model to groovy.swing.model
 rename groovy.inspect.swingui to org.apache.groovy.swing.table

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-
 rename groovy.util to groovy.test.util
 rename org.codehaus.groovy to org.apache.groovy.test
 rename groovy.lang to groovy.test.util

groovy-xml:
 rename groovy.util to groovy.xml
 rename org.codehaus.groovy.runtime to org.apache.groovy.xml.extensions

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

 

  was:
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:
 rename groovy.xml.QName to groovy.lang.QName

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-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:
 rename org.codehaus.groovy.binding to org.apache.groovy.swing.binding
 rename org.codehaus.groovy.runtime to org.apache.groovy.swing.extensions
 rename groovy.model to groovy.swing.model
 rename groovy.inspect.swingui to org.apache.groovy.swing.table

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-
 rename groovy.util to groovy.test.util
 rename org.codehaus.groovy to org.apache.groovy.test
 rename groovy.lang to groovy.test.util

groovy-xml:
 rename groovy.util to groovy.xml
 rename org.codehaus.groovy.runtime to org.apache.groovy.xml.extensions

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

 


> 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
>
> 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:
>  rename groovy.xml.QName to groovy.lang.QName
> 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-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:
>  rename org.codehaus.groovy.binding to org.apache.groovy.swing.binding
>  -copy org.codehaus.groovy.runtime.SwingGroovyMethods to org.apache.groovy.swing.extensions.SwingExtensions and deprecate original-
>  rename groovy.model to groovy.swing.model
>  rename groovy.inspect.swingui to org.apache.groovy.swing.table
> 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-
>  rename groovy.util to groovy.test.util
>  rename org.codehaus.groovy to org.apache.groovy.test
>  rename groovy.lang to groovy.test.util
> groovy-xml:
>  rename groovy.util to groovy.xml
>  rename org.codehaus.groovy.runtime to org.apache.groovy.xml.extensions
> Specific remaining questions:
>  * should {{groovy.ant}} or {{groovy.ant.AntBuilder}} be an automatic import? Currently the assumption is that it is no longer automatic.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)