To me since we have an internal representation for DocumentBuilder to
do
its runtime job, the user visible model could end up being a flyweight
object in front of it exposing thigns the way we want. Whether you
create this flyweight structure each time is another question.
Right. That's my thinking as well.
> Things we wanted but where too hard to do so far:
> - Separate annotation reading from Document building. Separate
> validity checks too.
> - It checks for JPA @Id using reflection as it might not be available
> -> pluggable?
We know only one use case for this pluggable mechanism, do we really
need it?
Which is?
> Do we all agree on this? In practical terms we'd also need to
define
> how far Hardy wants to go with this, if he wants to deal only with the
> Metadata API/SPI aspect and then I could apply the rest, or if he
> wants to try doing it all in one go. I don't think we can start
> working in parallel on this ;-)
I aslo don't think anyone should work on the DocumentBuilders while I am
doing work on them. I would just be a merging hell. Other than that I was planning to
tackle tow things. First the metadata API and then the idea of decoupling the
parsing of annotations from the rest of the DocumentBuilder code.
--Hardy