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:54:11 PM CDT, Steve Ebersole wrote: > 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 <ha...@hibernate.org> 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 >>> -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
