RichFaces 5.0 build redesign

Version 18

    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

     

     

     

    build-restructure.png