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

Annotations processor:

Implemented:

Currently, the component class annotations are parsed, except events, same as for attributes. JavaDoc comments are stored as 'description' property hence we have a single point for library documentation.

To be done:

Converter, Validator, Behavior, FacesEvent, Renderer class annotations, test and tag information.

Faces-config.xml parser.

Implemented:

Faces-config.xml parser works with 'component' and 'render-kit' sections only, with attributes and extensions tags. It configured with xinclude support. 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.

To be done:

Parse and store in the model <converter>, <validator>, <behavior> and common configuration parts.

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.

Add CssParser support to compile CSS files as JSF renderers ( it is necessary for Skin feature optimization ).

Generate XML Schema which could be used in IDE editors instead of tag library.

Model Validator.

Model validator, what supposed to check configuration consistency and infer default values for omitted parameters, performs simple checks only.

To be done:

Implement CDK naming conventions and configuration requirements in the model validator.

Generation of output files.

Implemented:

Component class builder is implemented as FreeMarker template parser. Faces-config.xml file generator implemented by JAXB marshaller.

To be done:

Templates for other generated classes,  testing of the generated faces-config.xml. Generate I18N resource bundles to use with UIComponent#getResourceBundleMap() method.

Template compiler:

Implemented:

Template compiler was included as part of build process.

To be done:

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.

Maven plugin:

Implemented:

Maven plugin runs whole build project, but configuration syntax was not clean. Currently, it uses the old CDK 3.x configuration directives.

To be done:

Cleanup maven plugin configuration, check last modification time of source and generated files for incremental builds. Record recoverable errors and mark build 'filed' after whole build process only. Log project build process ( logger functionality is already implemented ).

maven-resource-dependency-plugin

Tests:

Implemented:

Most of implemented features are covered by unit tests, and have JavaDoc comments. Integration test has been created for maven plugin. That test passed without execution errors but generated component file contains FreeMarker warnings.

To be done:

Write unit tests for all significant parts of CDK, extend integration test to cover at least most important CDK features.