Issue 43: Moving swingx components into sub-packages
I would like to move forward on this so judging from some of the input from the forums as well as hallway discussions with some J2SE/Swing engineers, we will move the components into sub-packages. I think we would like to try this. If this is totally the wrong directions then we can always move it back.
The following is a summary of the discussion:
Move some of the larger components from the base package into the sub-packages.
For example, moving a component like say JXTable from
org.jdesktop.swing.JXTable to org.jdesktop.swing.table.JXTable.
-- Reduces package interdependency
-- Makes it easier reduce the size of the deployment bundle based on usage
-- Developers using a non-trivial component can look at the package (and
package doc) to get the whole story about using that component.
-- Encourages greater use of package private classes.
-- This is not how Swing currently does it.
-- Not scalable in the medium term. Small components placed in swing.*
today may need to be placed in swing.foo.* tomorrow
- Mark Davidson: easier to learn, easier to prune unused functionality, may lead to less exposed implementation details.
- Patrick Wright: Will make it easier to learn a system of functionality.
- Adrian Sutton: Agreement but caution against loosing flexiblity.
- Ronald Tetsuo Muira: Agreed but only for complex components.
- Joshua Marinacci: Main components should be in a common package for convenient class importing.
- Ramesh Gupta: May make api "break" in the long term as components which exist in the base package may migrate to the sub packages as they get more complex.
- Richard Bair: Is there guidance on package structures? A: Not that I could find.
In addition, I was talking to Amy and a couple of Swing engineers around here and there was agreement that we should give it a try. This project is fluid and a means to explore other ways of developing Java API. We can always move classes around. I'm sure that when (if) parts of JDNC make it into the Java platform there will be name changes, api changes and package changes once again.
We will move forward on this proposal.
Thanks for all your input.