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.
- 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.
- 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
- 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
- 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
Comments