RichFaces CDK status.
1. All parts of CDK are implemented as pluggable objects that are stored in the single 'context' object, therefore it is easy to configure particular build. The same context also keeps project settings ( source and output folders, tag library url, source files ).
2. Cdk builds components library model from Annotations and faces-config.xml.
Currently, the only component class annotations are parsed, except IDE-related tags like 'icon' 'short description' and so on, same as for attributes. JavaDoc comments are stored as 'description' property hence we have a single point for library documentation.
Faces-config.xml parser works also with 'component' section only. It configured with xinclude support, but I had some troubles with proper namespace configuration. The same parser is used to include '@Attributes' references and standard JSF components definitions, therefore they could be used from annotations and included into faces-config.xml by xinclude directive. Generator merges information from both sources with highest precedence for xml.
3. Model validator, what supposed to check configuration consistency and infer default values for omitted parameters, performs simple checks only.
4. Component class builder implemented as FreeMarker template parser, but template itself does not finished yet. Templates for other library classes are not yet created.
5. Faces-config.xml file generator implemented by JAXB marshaller, but that is not yet tested.
5. Template compiler was included as part of build process. That seems necessary to create 'interface' section of template structure ( i think it should use JSF 2.0 composite component syntax as possible ) to provide information that is necessary to library consistence, like renderer-specific attributes, associated component type and tag names, behavior events and more.
6. To avoid repeated builds for project with multiply errors, CDK could record recoverable errors, like Java or XML syntax and continue build other parts, but does not write any output for project with errors, but these errors does not sorted yet.
7. maven plugin runs whole build project, but configuration syntax was not clean. Currently, it uses the old CDK 3.x configuration directives.
8. Integration test has been created for maven plugin. That test passed without execution errors but generated component file contains FreeMarker warnings.
9. Most of implemented features are covered by unit tests, and have JavaDoc comments.
Tasks to be done:
1. Parse annotations for JSF converters, validators, events, behaviors and all optional information.
2. Parse whole faces-config.xml content.
3. Create configuration files for standard JSF components and interfaces, pass-through attributes. We already have them in the CDK 3.x syntax and JSF-RI project has same files too, so it would be enough to create XSLT stylesheet that transform existing files into format expected by CDK. Also, XML schema for cdk extension attributes have to be finished.
4. Implement CDK naming conventions and configuration requirements in the model validator.
5. Sort CDK exceptions as recoverable and fatal, record recoverable errors.
6. Create templates for all generated class files. Test faces-config.xml generation.
7. Implement 'Interface' section in the template compiler, integrate compiler with el-expressions parser.
8. Cleanup maven plugin configuration.
9. Log project build process ( logger functionality is already implemented ).
10. Write unit tests for all significant parts of CDK extend integration test to cover at least most important CDK features.