Version 7
Created by jbalunas on Apr 24, 2009 3:18 PM. Last modified by jbalunas on Jan 6, 2010 11:13 AM.

    Draft - for design discussion - not final

     

    This page is part of a larger series of pages discussing RichFaces 4.0 Release Center

    Requirements
    • Modulize the various areas of RichFaces
    • Clean lines of dependencies between modules
    • Shorten build time - especially when working on discrete modules
    • Able to build any part without the need to build every part
    • Able to exclude components,skins,themes from packaged ui artifacts
    • "sandbox" areas for components, examples, skins, and themes
    • Able to release updates to individual modules without requiring a complete release of everything
    • Have theme's and skins be separate modules
    • We want to deliver example distributions
    General Concepts

    These concepts apply across the proposals below.

    • Unit and function tests should be nested in modules where ever possible
      • There may be a need for a common "/test" modules but that is TBD
      • Applications used to test RichFaces should be in the "examples" module
    • Components, themes, skins, etc.... should only depend on api, and not impl.
    • There should be no top level SVN trunk/branches, instead modules should have there own.
      • See questions section for more
      • We want it to be easy to selectively develop, build, test, release each module.
      • Keep it easy to identify and maintain dependencies and rules
    • Themes and skins become independent modules
      • Want about default skins/themes?
      • Should all skins/themes become separate?  
    • The new build system should allow for independent builds in hudson for each module to fast testing and feedback.
    Collaboration with the Seam project
    Open Questions
    •    Version Matrix placement
      • Talk with Dan Allen and get his opinion

    4.0 Maven Build Plan

    This allows releases of concrete ui modules even if sandbox are not ready.  Keeps examples separate as they could have different release times.

     

    Note: Directories with "*" would have nested SVN trunk/branches/tags (t/b/t)

     

    /runtime*

       /trunk
          /api
          /impl
    /ui*

       /trunk
          /components
          /themes
          /skins
    /ui-sandbox*

       /trunk
          /components
          /themes
          /skins
    /examples*

       /trunk

    /examples-sandbox*

       /trunk
    /cdk*

       /trunk
    /doc*

       /trunk

    /assembly*

       /trunk

    /version-matrix*

       /trunk

     

    Version-matrix

    The version matrix contains a simple pom.xml that defines the versioning of all jars used in the project.  This pom is then either inherited, or included in all of the other modules to force common versioning between components.

     

    Assembly

    The assembly module is going to manage the packaging of the different modules into downloadable packages.  i.e. the binary dist, the CDK dist, the example dist, and manage the profiles for ui module inclusions/exclutions.

     

    This will use the maven assembly plugin - http://maven.apache.org/plugins/maven-assembly-plugin/introduction.html

     

    Component API

    There are times when individual component may have API code that should be packaged separately than actual UI code.  This API code should be separate than the runtime API, and not be packaged with the UI specific code.  This component API code includes, but is not limited to models, listeners, and events.  It is possible that this could apply to the themes and skins as well, and if needed a similar approach will be used.

     

    Each component should follow the same packaging scheme for these API classes such that they can be aggregated and packaged into a richfaces-component-api.jar.  The exact packaging is TBD.

     

    R&D Maven Shade plugin to aggregate API classes into richfaces-component-api.jar

         - http://maven.apache.org/plugins/maven-shade-plugin/

     

    This outline below is strictly for conversation and not final:

     

    /components/calendar/src/main/java/org/richfaces/calendar

         /api

         /ui

         /renderkit

         /etc....

    Misc
    • Review all project dependencies
      • Get a common dependency report working across all modules
      • Identify all items that can be removed, or centralized, or "provided"
      • Requirements of testing, should be separate from requirements of modules
        • right now it looks like RF has a large # of dependencies, but most are just for testing
    • Should attempt to the entire release use the maven-release-plugin without additional scripts
    • Make a hudson release job would handle the building, tagging (maybe), packaging of the release binaries. 
      • Once verified the distributions can be published straight from job workspace
      • This will save lots of time everyone, especially Minsk team.