4 Replies Latest reply on Apr 30, 2013 8:59 AM by lfryc

    Moving the component sources to own Java packages


      I 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:



      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
      • 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)






      1. Diverge some more obvious logical groups



      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




      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




      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.