Moving the component sources to own Java packages
lfryc Apr 29, 2013 10:13 AMI have refactored all component related sources to respective packages.
Right now we have separated those under single package org.richfaces.ui where each logical group has its own subpackage:
----
The problem I can see now is the number of source files which are in these group packages:
For example:
- ui.ajax -> 52 sources https://github.com/richfaces/richfaces5/tree/bab225acc9ef7dd7b64f01c565c69c36a8d7b707/framework/src/main/java/org/richfaces/ui/ajax
- ui.input -> 45 sources https://github.com/richfaces/richfaces5/tree/bab225acc9ef7dd7b64f01c565c69c36a8d7b707/framework/src/main/java/org/richfaces/ui/input
- ui.output -> 55 sources https://github.com/richfaces/richfaces5/tree/bab225acc9ef7dd7b64f01c565c69c36a8d7b707/framework/src/main/java/org/richfaces/ui/output
- ui.iteration -> 105 sources https://github.com/richfaces/richfaces5/tree/bab225acc9ef7dd7b64f01c565c69c36a8d7b707/framework/src/main/java/org/richfaces/ui/iteration
This is quite scary, you can try it yourself how it is possible to browser this hierarchy.
----
What we want to achieve ideally:
- users wants
- no future changes of package structure [so that they can consider that as API]
- => as we do it now, it will stick forever
- no future changes of package structure [so that they can consider that as API]
- contributors wants
- dive easily into component sources [so that they have clear mapping between the component and its sources]
- => all relevant sources together (shared impl in ui.common/utils)
- dive easily into component sources [so that they have clear mapping between the component and its sources]
----
Options:
1. Diverge some more obvious logical groups
ui.toggleable ui.tree ...
The disadvantage of this principle is that we doesn't have to elimiate the issue completely - e.g. tables are still in the ui.iteration, and they have lot of sources.
2. Move the component sources to packages called by component name
ui.ajax ui.dataTable ui.extendedDataTable
This is the option which is most accessible to contributors - in order to see a source code of a component, one needs to enter org.richfaces.ui and he see (almost) all relevant sources.
The problem is with number of packages - this way we will end up with ~80 packages (per component).
3. Structure the ui.group sub-packages
ui.core.ajax ui.iteration.dataTable ui.iteration.extendedDataTable
This is the combination of previous concepts, which is not so obvious for contributors (in which group is my component located?),
but it keeps balance of complexity and number of packages.