RichFaces 4.0 Component Migration Process

Version 2

    This document covers the differences and changes in workflow from the RichFaces 4 Component Development Process required for components that are being migrated from the RichFaces 3.3.X code base.  Note - many of the steps are similar so please refer to the main document for details.

     

    Prior to moving a component and starting this process the <link>priority wiki page</link> and plan for the targeted release should be reviewed.  Once it is determined that a specific component will be migrated, the rest of the process below can be started.

    Dev Article, and Discussions

    A development forum post needs to be created for the component to be migrated.  It should contain:
    • Links in source code to the related source, JS, etc..
    • Links to documentation
    • Links to related items like forum posts, or other articles
    • Initial requirements updates
      • Component and attribute name changes?
      • Basic functionality and feature updates
    • Listing of what is core component functionality, and what can be done as a separate feature.
    • Links to related feature requests and jira's

     

    This should then be reviewed and commented on by members of the team, especially likely developers.

    3.3.X Source Code Review

    Once initial discussions are complete the lead developer and others ( designer, other developers ) should review the source code in more detail from 3.3.X.
    Question to be answered:
    • Does the markup need to be updated significantly to match semantic markup goals for 4.0.X?
    • Can the source code be moved directory to 4.0 sandbox?
      • Does it need to be moved piece by piece?
      • Does it require special updates or source refactoring?
    • Major redesigns, or refactoring required?
    • Base functionality vs. adv. features?
      • We want to break out core vs. advanced
      • Core will be developed first if possible
    • Client side library migration requirements
      • Standardizing on JQuery so others need to removed.

     

    This review should result in the better understanding of what is required for the component work, and should allow detailed jira's to be created in the next section.

    Component Jira

    The component jira requirements for a migrated component are very similar to those for a new component, and follow the <link to Ilya's jira doc >.
    However detailed tasks that have been identified from the above sections should be added, and any advanced features that can be implemented or migrated separately should created, as their own jira's.

    Design/Markup/Skinning

    The design markup and skinning requirements can be a bit more tricky that with new components because there is also an implementations there, that might need to be updated.  The project team, and designer should review the components following our goals for 4.0.  This includes attempting to follow semantic markups and structure, consistent usage of component elements, and following the 4.0 skinning plans.
    • Designer should must complete markup updates
      • Semantic markup updates
      • Consistency of html structure
      • Skinning updates
    • Dev should review client/server source for
      • What should be shifted for future development

    Copy/Migrate to /UI Sandbox

    Again this is not too different from new component development except that because an existing component exists updates must be made based on the reviews, and plans above.  i.e. sometimes a whole sale copy is best ( then update ), and other times starting fresh and integrating selected resources is the right choice.

    Update build

    Nearly identical to new development.  Remember the standards discussed in the <link> coding guidelines </link>.
    Specifically:
    • Maven build updates to use latest ui-parent
    • Sub-project structure to follow api/ui breakup
    • Java package updates for components
    • TODO - Make sure we have a section in the guidelines about proper component structure.

    Development

    No different than new components.

    Review

    No different than new components.

    Promotion

    No Different than new components.