[hibernate-issues] [JIRA] (HHH-15996) Create an abstraction over Annotation for annotation processing

Steve Ebersole ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMmMzY2JmZWI2... ) / Improvement ( https://hibernate.atlassian.net/browse/HHH-15996?atlOrigin=eyJpIjoiMmMzY2... ) HHH-15996 ( https://hibernate.atlassian.net/browse/HHH-15996?atlOrigin=eyJpIjoiMmMzY2... ) Create an abstraction over Annotation for annotation processing ( https://hibernate.atlassian.net/browse/HHH-15996?atlOrigin=eyJpIjoiMmMzY2... ) Change By: Steve Ebersole ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) At the moment, annotation processing uses HCANN. HCANN provides an abstraction from , however, does not play well with models where there is not a 1-1 correspondence between managed-type and Class . Initially, the domain thought was to reuse HCANN’s model abstraction classes (XClass , XProperty, etc) but exposes {{Annotation}} directly build them within ORM itself for these cases. However, those classes are not very good at modeling these concepts at the moment and would require changes to HCANN. Ultimately Relatedly, we ultimately want to move away migrate from HCANN to use Jandex for reading the annotation details.  Jandex uses also exposes abstraction over Class - {{ClassInfo}}, etc.  It also exposes an abstraction from {{Annotation}} in the form of {{AnnotationInstance}}.  Ultimately this move to Jandex will require lots of changes to that code. {{org.hibernate.boot.model.source}} was developed as an abstraction over the source Given all of mapping information - annotations that , {{orm.xml}}, {{hbm.xml}} with the initial intent of unifying the processing of mapping sources. This better solution there is already how {{hbm to create an abstraction in ORM itself. xml}} is processed. This work would apply that abstraction can be used to annotations and {{orm.xml}} processing as well. The approach has benefits in addition to not only abstract the processing unification, such as - # Avoiding use Class information but also the source of library APIs in processing that Class information (HCANN v. Ultimately we want to move to Jandex over HCANN for annotation consumption - see ).  That work will be done under [https://hibernate.atlassian.net/browse/HHH- 9489 15698 |https://hibernate.atlassian.net/browse/HHH- 9489 15698 |smart-link].  Using this abstraction will make that migration much simpler. # Allows support for both dynamic models (MAP mode) and {{entity-name}} models.  This is important for deprecation of {{hbm.xml}} in favor of annotations / {{orm.xml}} - see [https://hibernate.atlassian.net/browse/HHH- 15698 15997 |https://hibernate.atlassian.net/browse/HHH- 15698 15997 |smart-link]. Given that we will be abstracting the managed-types, we also have an opportunity to decide about how to deal with annotations.  Specifically, whether we want to continue using {{Annotation}} from HCANN or use an abstraction.  This issue is about creating that abstraction. ( https://hibernate.atlassian.net/browse/HHH-15996#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-15996#add-comment?atlOrigin=ey... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=Em... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100213- sha1:cca7326 )