4 Replies Latest reply on Aug 5, 2010 9:34 AM by Jay Balunas

    Build structure redesign: UI modules

    Nick Belaevski Master

      To continue build system redesign discussion we need to agree on the structure of UI module internals.

       

      First of all, the following changes are proposed:

      - 'ui' module is renamed into 'components'

      - 'common' module is created to isolate components' & core API/impl. Code from current core/commons module will be placed into this module and core/commons module removed

       

      So, two alternative layouts - with shared & private API:

       

      private API:

       

      - components
         - dist
            - api
            - ui
         - parent
         - common
            - api
            - ui
         - input
            - api
            - ui
         - output
            - api
            - ui
         - misc
            - api
            - ui
         - iteration
            - api
            - ui
         - core
            - api
            - ui
         - validation (?)
            - api
            - ui
      

       

      shared API:

       

      - components
          - api
          - dist
          - parent
          - common
          - input
          - output
          - misc
          - iteration
          - core
          - validation (?)

       

      While shared API looks much simpler, private API allows to keep API classes tightly coupled to the particular component family - this can be important for module releases. 

        • 1. Re: Build structure redesign: UI modules
          Alexander Smirnov Master

          Actually, best structure would depend from developer habits.

          I'm using Mylin that perfectly filter workspace for classes and files involved in my work, so actual place doesn't matter. On the other hand, each additional project takes resources from IDE and command-line builds, and requires additional goals for distribution, so I prefer to have as little projects as possible. Also, if you take a look to existing api projects, they contains a few classes only - does it make sense to have separate project for just 2/3 classes ?

          • 2. Re: Build structure redesign: UI modules
            Jay Balunas Master
            • /parent is not needed.  The richfaces-parent is the only parent with the new system.   Although there is a possibility of a ui BOM.  Although now that I think of it the only thing that should have its own BOM is CDK (different runtime).  At some point we might want to have core have its own BOM, but it is not needed now.
            • Personally I really think that the private version is the way to go.  As Nick said it will make it easier to isolate, and is much easier to partition work, dependencies, etc…  Not to mention easier to grasp for new people.
              • However that does not mean that we need each <component-type> ( core, validation, iteration, etc…) to have sub-projects.  I think if the component set is simple enough ( as Alex said ) it could just be:
            /validation
              pom.xml
              /src
                /<api & ui source>
            
              • While complex component types like iteration could maintain separate projects like this:
            /iteration
              /pom.xml
                /api
                   pom.xml
                   /src
                /ui
                   pom.xml
                   /src
            
              • However - it is likely much easier to generate the project jars if api is kept separate.  In either case we will be using shade plugin to generate our component jars
            • One thing not covered here is java packaging, although it should follow suit.
            org.richfaces.components.iteration.api….
            org.richfaces.components.iteration.ui….
            
            • The only question there is - do we break this out to component name? 
            • 3. Re: Build structure redesign: UI modules
              Nick Belaevski Master
              • /parent is not needed.  The richfaces-parent is the only parent with the new system.   Although there is a possibility of a ui BOM.  Although now that I think of it the only thing that should have its own BOM is CDK (different runtime).  At some point we might want to have core have its own BOM, but it is not needed now.

              I've placed parent for ui module to keep independent shared plugin settings, e.g. CDK or Checktyle configuration. If we don't need this, it can be removed.

               

              • Personally I really think that the private version is the way to go.  As Nick said it will make it easier to isolate, and is much easier to partition work, dependencies, etc…  Not to mention easier to grasp for new people.
                • However that does not mean that we need each <component-type> ( core, validation, iteration, etc…) to have sub-projects.  I think if the component set is simple enough ( as Alex said ) it could just be:
              /validation
                pom.xml
                /src
                  /<api & ui source>
                • While complex component types like iteration could maintain separate projects like this:
              /iteration
                /pom.xml
                  /api
                     pom.xml
                     /src
                  /ui
                     pom.xml
                     /src
              
                • However - it is likely much easier to generate the project jars if api is kept separate.  In either case we will be using shade plugin to generate our component jars

               

              Ok, let's go with private API. Also I'm for unified package structure (the one where package name is the same in every ui submodule), so here is the structure outlined in more details:

               

                 - dist
                    - api
                    - ui
                 - parent (?)
                 - common
                    - api
                    - ui
                 - input
                    - api
                       - src/main/java
                          - org.richfaces.component
                             - InputOrientation.java
                             - SuggestionEvent.java
                             - SuggestionListener.java
                             - CalendarEvent.java
                             - CalendarListener.java
                             - ...
                    - ui
                       - src/main/java
                          - org.richfaces.component
                             - AbstractAutocomplete.java
                             - AbstractCalendar.java
                             - AbstractNumberInput.java
                             - ...
                          - org.richfaces.renderkit
                             - AutocompleteRendererBase.java
                             - CalendarRendererBase.java
                             - NumberInputRendererBase.java
                             - ...
                 - output
                    - api
                    - ui
                 - misc
                    - api
                    - ui
                       - src/main/java
                          - org.richfaces.function
                             - RichfacesFunction.java
                          - org.richfaces.component
                             - AbstractDrag.java
                             - AbstractDrop.java
                             - AbstractJQuery.java
                             - ...
                          - org.richfaces.renderkit
                             - DragRendererBase.java
                             - DropRendererBase.java
                             - JQueryRendererBase.java
                             - ...
                 - iteration
                    - api
                    - ui
                 - core
                    - api
                    - ui
                 - validation (?)
                    - api
                    - ui
              
              • 4. Re: Build structure redesign: UI modules
                Jay Balunas Master

                Nick Belaevski wrote:

                 

                • /parent is not needed.  The richfaces-parent is the only parent with the new system.   Although there is a possibility of a ui BOM.  Although now that I think of it the only thing that should have its own BOM is CDK (different runtime).  At some point we might want to have core have its own BOM, but it is not needed now.

                I've placed parent for ui module to keep independent shared plugin settings, e.g. CDK or Checktyle configuration. If we don't need this, it can be removed.

                That is a good point.  Lets leave the ui specific parent ( assuming it's parent is richfaces-parent)