The current RichFaces build structure (RichFaces 4.0 Build & Directory Structure) has served the project well over the initial 4.0 release, and the subsequient 4.1 and 4.2 releases, we want to re-visit the the build struture with RichFaces 4.3, and make sure we are achieving our desired goals with the build structure.

This wiki page will capture:

User Stories

In this section we will capture the use cases that will drive the build requirements, and the build design.

1. As a RichFaces user I want to
   • include only a single jar in my applications pom file so that I can easily make use of the RichFaces components and framework without requiring complicated changes to the build
   • use RichFaces samples/examples as a starting point for my project so that I can easily include the provided sample code in my application.
   • include only a single namespace for use of RichFaces components so that I can more quickly and easily author new pages, with all components being discoverable with IDE autocompletion.
2. As a RichFaces dev I want to
   • rapidly develop new components so that I can achieve a rapid turnaround from the time I edit a component/renderer source/templates, to seeing those changes reflected in a browser window
   • build against multiple JSF implementations (RI, MyFaces, JBoss) so that I can know that API is compatible and that unit tests pass
   • run integration tests against multiple containers (using Arquillian) so that I can verify the integration with those containers easily
     
   • target examples on Java EE web profile so that I don't need to maintain dependencies for servlet containers
   • release project using a fully-automated and standard build so that I don't need to use custom scripts
   • use released version of CDK so that I don't depend on snapshot and can stabilize my build
   • bring test dependencies in bulks (dependency chains) so that I don't need to list all my dependencies in each submodule
   • clone project from single repository with clear structure so that I may dive right into code
3. As a RichFaces productization I want to
   • manage dependency and plugin versions from one or two points so that I don't have collisions in subprojects
4. As a RichFaces quality engineer, I want to
   • quickly create new samples for reported issues with minimal configuration (pom.xml, xml namespaces) so that I can copy & paste code snippets provided by user into my application .

Build Requirements

Here we will create a set of requirements based off the above user stories

• Doing away with the API/IMPL artifact split will greatly simplify the build
• the cdk should be in it's own repo with it's own release cycle
• We need to introduce a parent, but will have separate parents for the CDK and Framework projects
• We'll manage the JSF deps independently between the CDK and framework, and introduce a BOM if required

Build Design

The design of the project layout and artifacts required to satisfy the above requirements