RichFaces 4.0 Component Migration Process

Version 2

Created by jbalunas on Aug 9, 2010 12:57 PM. Last modified by jbalunas on Aug 25, 2010 2:16 PM.

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