This document will define requirements towards the ShrinkWrap Descriptors API for the 2.0.0-X series.
Please seed with any bullets of concern with notes to associated JIRA issues; everything is on the table for consideration and we'll denote approvals as we go forth:
| Proposed Requirement | Notes | JIRA (if applicable) | Approved? |
|---|---|---|---|
| Support for all XSDs / DTDs defined by EE 5 | Yes | ||
| Support for all XSDs / DTDs defined by EE 6 | Yes | ||
| Support for all XSDs / DTDs defined by JBoss AS 7 | Yes | ||
| Read-only Views | No need to protect against reflection or provide truly immutable objects; a read-only API will be sufficient | Yes | |
| Mutable Views | Yes | ||
| Source Generator | Implementation detail, but this has been proven to cut the workload. XSL approaches previously taken are prohibitively unmaintainable, so let's opt for a cleaner solution this go-round. | Yes | |
| Allow custom code overrides / enhancements into generated methods, allow for custom method naming | Yes | ||
| Pluggable typed formatters | For representation as formatted String, space-saving String, DOM object, etc:
interface Formatter<OUTPUTTYPE>{ OUTPUTTYPE format(); }
String output = descriptor.formatUsing(formatter); | Yes | |
| Validation layer | To validate values against supported input types. Not to be combined with the object model itself; implement as separate layer. Lesser priority than delivery of SWD Core | ||
| Zero runtime dependencies | Current Node SPI is fast, efficient, and handles parsing instead of DOM or SAX / Stax | Yes | |
| Allow for manual inclusion of methods not represented by the XSD | ie. shortcut methods: | Yes | |
| Default Descriptors paths | https://issues.jboss.org/browse/SHRINKDESC-114 | ||
| Better support for values replacement | Currenty it is not user friendly: https://gist.github.com/johnament/5189053 | ||
| Replace the parser with the Xerces Native Interface | The Xerces Native Interface allows to access the internal abstract syntax tree. The current parser doesn't support advanced features like multiple namespaces etc. This is pobably not the first priority. | No, this is not a requirement; it is an implementation hint. A requirement would read like: "Support multiple namespaces". Additionally, the parser isn't part of the user API, it's how we build the source. |
Comments