jcoderz / fawkez Goto Github PK

That means fix all generics related warnings by adding generics type information.

1. With JPA it is still necessary to write a lot of boilerplate code for the entity- / pojo- / dto- / ValueObject- classes. It is possible to add a field to the database table quiet easily but you then still need to update all the equals, toString... methods. With the jCoderZ SimpleTypesGenerator this has been much easier since ages. Just add the one field to the xml and with the next build you get a new class that supports the new field, just like any other.

To support JPA we need to support a place for java annotations in the generated classes. As with the support for xdoclet this is just a question of adding a element / attribute to the class and the fields.

2. JPA AFAIK does not support the use of final or immutable classes. This is a step back from the idea to make dto like classes as immutable as possible. Might be we find a way to support this easily? (like StringBuilder vs. String using the BuilderPattern)? Might be a 2nd step?

3. Not only because of (2) there is no easy way to use a SimpleType? in JPA. Embeddable is far less powerful than the hibernate user types we used before. We seem to be limited to 'String' for alphanumerical data types again, like Street, Name, UUID and so on. Might there is a solution for that?

4. The xml we defined for the codegenerators was straight forward without taking existing xml definitions into account (actually there was no schema definition available when we started). As of today it would make sense to use element and attribute names similar to the ones used in schema-type-definition. Like for example for String based types.

5. Most of the above is easier to achieve if we start a new xslt, might be dropping some outdated features and add the new ones. The old xslt could still be supported on a as is base, if we have a unique distinction between the old and the new ones in the source xml.