Issues * Provide composite emitters
An emitter might use more than one emiter technology (e.g. when generating source files plus relating xml configuration files). In that case different emitter engines are used. Support composite emitters which are composed of different emitters.
Realize public/protected/private rules
A rule method should be able to declare whether it can be called from out of the transformation or not.
Integrate XSD/DTD to POJO transformation
Have a look at JAXB
What if the Transformation has more than one rule combination?
E.g. from an UML class generate multiple Java classes? Declaring an intermediate domain is complex. How to ease this?
Integrate JRuby and Jaskell as transformation engines
Provide a JavaBean repository
It would be nice to be able to execute transformations against some JavaBean model. E.g. to generate a POJO implementation for a given Java interface, or to generate some SessionBean facades for Hibernate POJOs
Provide an Java Annotation processor as repository
Additionally it would be nice to have the possibility to evaluate certain annotations and to use them in the transformation.
Provide transformations that take a JavaBean repository as input and create the corresponding JSF stuff as output
Have a look at XDoclet
Maybe it would be valuable to provide an adapter to the xdoclet generator engine.
Maybe it would be valuable to provide an adapter to the Velocity generator engine to use it at least as emitter technology
Maybe it would be valuable to provide an adapter to the FreeMarker template engine to us it at least as emitter technology
Ordering of associations during emitting
Consider to preserve ordering during emitting. E.g. import statements or the ordering of operations should not change when regenerating
Generator configuration information in generated sources
It should be possible to generate some information into the generated sources about the configuration that was used when the generation was performed. Interesting information would be the versions the transformations used and the input elements from which the result was derived from.
Refactor the StringTemplateEmitter
Make use of TemplateInterfaces and TemplateGroups to get rid of the TemplateConfig class. Ideally the complete StringTemplateEmitter class can be implemented to take a URL to the templates as configuration.
Exception handlilng for transformations
Polymorphic resolution of transformation rules.
E.g. when transforming a property in the pojo domain the type can be a Pojo or a Primitive. The Property rules should not have to be aware of that
Use manifest file as transformation descriptor
Instead of writing a class that implements the Transformation interface provide a default implementation that initializes itself from a jar file. The transformation specific information must be declared in the manifest file of that jar file. Using this mechanism a dynamic lookup would be possible.
JAXB emitter
Provide an emitter that can emit XML files using JAXB
