On Jul 16, 2012, at 9:06 PM, Steve Ebersole wrote:
Strong, I forgot to mention that Jason completely agrees that changes
to
Jandex are needed. I agreed to prototype some of the things he and I
discussed specifically in this code base and hand them back to him for
integration back into the next rev of Jandex.
Nice. Maybe I can lend a hand there as well. As you know I am strongly attached
to this issue :-)
One such point of discussion was a common interface for
"Index".
Unfortunately the name Index is already taken as in the main Jandex
class. So we came up with some other names. For this work I went ahead
with the name 'IndexResult' for that common contract (interface).
Anyway, no matter the name, eventually both Index and that new
CompositeIndex would both implement this new common contract.
Why do you need this contract? What benefit do you gain?
The other thing we discussed was integrating XML overrides into the
indexing process since quite a few places where Jandex gets used would
need this. And since you worked on that in the metamodel codebase, was
hoping to get your feedback as to whether you thought it would be
possible to integrate XML overrides into this process up front.
IMO it does not matter so much whether you do the overrides before or after
annotation processing. It kind of makes sense to do it afterwards, because the
xml configuration normally overrides existing annotations, so replacing an
AnnotationInstance
in the annotation based index with a pseudo AnnotationInstance reflecting xml
configuration seems "natural".
The problem of course is that a Jandex index is immutable and I cannot just
replace/modify
an AnnotationInstance. For that reason you have to a lot of collection iterations/copies.
If one wanted to improve on this I could imagine building some sort of OverrideIndex up
front
containing the pseudo AnnotationInstances from the XML configuration. This OverrideIndex
would be generic and could be part of Jandex to be used by other projects. This index
could be
passed prior to Jandex prior to the annotation discovery phase. For every annotation the
discovery
index could query the OverrideIndex whether an override exists for a given annotation. If
so this
override would be added. The benefit of this approach is of course that I don't have
to build
multiple indexes.
One thing I am not sure about is how to handle changes in xml configuration files. How do
we know
that we have to discard an index stored on the file system. Not even quite sure how AS
handles changed
classes (there might be some checksumming going on, not sure).
On the ORM side we are currently not saving the index to disk. Right now we create a new
index and add
explicitly the classes/packages the user specifies via the configuration. Once this
processing is complete
we do the xml overrides and get what Steve calls the CompositeIndex. After the
configuration phase is
over the index is discarded.
In the long run it would be good if we could store the index and load it on startup.
My 0.02$,
Hardy