Hm, seems like the "AP delayed generation" approach is a possibility. From a quick search:
https://stackoverflow.com/questions/41874462/java-annotation-process-not-yet-generated-elements https://docs.oracle.com/javase/6/docs/api/javax/annotation/processing/RoundEnvironment.html#processingOver%28%29 Disclaimer - I have not tried this, just read about it... On Thu, Jan 10, 2019 at 7:18 AM Steve Ebersole <st...@hibernate.org> wrote: > This is one of the cases (there are others) where we do not completely > follow the JPA spec. > > TBH I'm not really sure how we would address this in an annotation > processor, though granted my knowledge of those APIs is limited. But as I > understand it we have to generate the metamodel class as we process the > model class without knowledge of or access to other classes. Specifically > here, we see the MappedSuperclasss first as it is a superclass and the > compiler needs to process it first. > > I had planned on re-looking at this in 7 to offer a non-AP solution to > metamodel generation. I don't think anything requires that we support this > through an AP. > > There are other problems using an AP for this, namely it is extremely > difficult to incorporate orm.xml info whether partial or complete. > > I guess a solution for now would involve somehow delaying the generation > of the metamodel classes until the end of the AP cycle which (IIUC) would > only really work with `proc:only` > > On Thu, Jan 10, 2019 at 6:29 AM Guillaume Smet <guillaume.s...@gmail.com> > wrote: > >> The generated model of the MappedSuperclass? >> >> Because the one of the subclass is correct for sure. >> >> On Thu, Jan 10, 2019 at 12:44 PM andrea boriero <and...@hibernate.org> >> wrote: >> >> > I'm not sure I have fully understood the issue, the @Id may be not >> defined >> > in the MappedSuperclass but for sure it must be in the subclasses >> extending >> > it. >> > >> > I have tried and I can reproduce the issue only if I do not specify >> > any @Id annotation in the subclass, but as soon as I add the @Id to a >> > subclass of the MappedSuperclass the generated static metamodel is >> correct. >> > >> > >> > On Thu, 10 Jan 2019 at 11:04, Guillaume Smet <guillaume.s...@gmail.com> >> > wrote: >> > >> >> Hi, >> >> >> >> We recently had this issue opened about us not choosing the right >> access >> >> type for a mapped super class: >> >> https://hibernate.atlassian.net/browse/HHH-12938 . >> >> >> >> Hibernate currently base the access type decision on the sole >> placement of >> >> the @Id annotation, which, in the case of a @MappedSuperclass might >> not be >> >> defined (this is the OP's case). >> >> >> >> I closed the issue explaining what we do and pointing a workaround but >> the >> >> OP rightfully replied with the JPA spec saying "The default access >> type of >> >> an entity hierarchy is determined by the placement of mapping >> annotations >> >> on the attributes of the entity classes and mapped superclasses of the >> >> entity hierarchy that do not explicitly specify an access type". >> >> >> >> I'm wondering if we should also consider the @Column annotations >> placement >> >> if there is no @Id annotation. >> >> >> >> If the answer is that it's already fixed in 6, it's all good for me :). >> >> >> >> Thoughts? >> >> >> >> -- >> >> Guillaume >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev@lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev