Hardy, could the API be fixed up? I have not used it enough to be able to tell if it is salvageable (only enough to know it needs changing ;) On Tue 26 Jun 2012 02:37:02 PM CDT, Sanne Grinovero wrote: > Ok that sounds all nice. But we need programmatic definition of > annotations too, you remember Hibernate Search right? > > The first point you make about the XClass abstraction sounds to me a > good one, a good reason to use it. It doesn't have to be big and > bloated, but if we have a simple way to abstract from the annotation > reading > - XML > - Class definitions > - programmatic overrides > > in a single API, that sounds like a good thing? You mention this API > is confusing, maybe we can improve on it? Sounds better than to have > to deal with the three sources independently. > > On 26 June 2012 20:29, Hardy Ferentschik <hardy(a)hibernate.org&gt; wrote: >> >> On Jun 26, 2012, at 9:02 PM, Sanne Grinovero wrote: >> >>> There are a lot of libraries depending on Hibernate Commons >>> Annotations, up to Infinispan for the Query module (not depending on >>> any other Hibernate core library). >>> >>> If you want to rewrite it's internals and provide a drop-in >>> replacement, that's nice. But I see no reason to throw it away? >> >> Sure, here we go. >> >> Commons Annotations tries to do two things at the same time. >> >> First there is the annotation abstraction, hiding the fact whether >> an annotation is an actual annotation >> or a corresponding xml configuration element. It does this by >> introducing XClass & Co. >> And that's the first rub. Working with XClass is highly confusing. >> You never know whether you >> deal w/ an XClass or an actual Class instance. Working on the ORM >> annotation processing code you have often >> have methods you get one or the other. Confusing! >> >> Also, working with Jandex you get the actual annotation vs xml >> configuration much easier. Jandex itself abstracts already an >> annotation. >> Hence you just have to implement the right Jandex classes to create >> pseudo annotation (annotation backed by xml configuration). Using >> Jandex >> in combination with Commons Annotations would mean you would >> abstract the abstraction. >> >> Back to the two things Commons Annotation tries to do. Commons >> Annotation also does generic type resolution. >> IMO this two things should be separate. There is annotation >> processing and there is type resolution. I often don't need >> both, but just one of them. Using a library like classmate can >> easily do the type resolution when I need it in a much more >> transparent way. The code is actually easily understandable. It is >> much harder to understand how the corresponding Commons Annotation >> code works. >> >> Regarding your reinventing the wheel argument. The metamodel branch >> already successfully removed the Commons Annotation >> dependency. Jandex offers all we need and Strong implemented some >> classes which create pseudo >> annotations for the xml config. The type resolution was replaced by >> classmate. Bottom line is that Commons Annotations is already >> replaced on the metamodel branch. >> >> Last but not least, I am definitely not the guy who wants to rewrite >> working just for the sake of it. However, if I see that there are >> better >> alternatives for existing code which results in easier to understand >> code I go for it. >> >> --Hardy >>