Also, I have been thinking that there really ought to be different types of "integrators". Not sure what we gain by forcing MetadataContributingIntegrator, ServiceContributingIntegrator, TypeContributingIntegrator, etc to extend Integrator On Sat 18 Aug 2012 05:50:29 PM CDT, Steve Ebersole wrote: > The general idea is good. But not really getting the point/purpose of > having both before and after hooks.

> > On 08/17/2012 01:12 AM, Strong Liu wrote: >> I'm thinking add the interface below, with it, modules like envers >> can choose either before or after the metamodel get processed to hook >> into its own extending mappings >> >> >> public interface MetadataContributingIntegrator extends Integrator { >> /** >> * Allow the integrator to alter the {@link MetadataImplementor} >> BEFORE {@link MetadataSources} get processed. >> * <p/> >> * >> * At this stage, metamode ( like {@link >> org.hibernate.metamodel.spi.binding.EntityBinding} etc. ) is not >> available yet. >> * This is a good time to add the custom sources into >> {@MetadataSources} and get it processed by Hibernate Metamodel. >> * >> * @param metadata The Metamodel which is going to be completed >> by processing MetadataSources. >> * @param source Meta data sources to be processed. >> */ >> public void beforeMetadataProcessing(MetadataImplementor >> metadata, MetadataSources source); >> >> /** >> * Allow the itnegrator to alter the {@link MetadataImplementor} >> AFTER @{@link MetadataSources} get processed. >> * <p/> >> * >> * At this stage, metamode ( like {@link >> org.hibernate.metamodel.spi.binding.EntityBinding} etc. ) is bindded. >> * So, it depends on the integrator to manually create metamodel >> and add it to {@link MetadataImplementor} or modifiy the >> * existing one. >> * >> * @param metadata >> * @param source >> */ >> public void afterMetadataProcessing(MetadataImplementor metadata, >> MetadataSources source); >> } >> >> downside is, envers with old metamodel calls >> Configuration.buildMappings() again during the integration phase, so, >> its created hbm xml can be processed (again) before SF create, but >> with new metamodel, it is hard to do that I think ( or too time >> consuming ) >> >> and to create envers own metamodel ( hbm ) it needs to know the >> hibernate type of entity property, which can be easily get from >> Entitybinding but hard / duplicated to resolve from source by envers >> itself, so it seems we should choose "afterMetadataProcessing" >> >> but envers' hbm creation involves lots of code and pretty complicated >> ( to me :) it's better to reuse those code and choose >> "beforemetadataProcessing" and let new metamodel to take care of that. >> >> thoughts? >> >> >> On Aug 2, 2012, at 12:17 AM, Hardy Ferentschik <hardy(a)hibernate.org&gt; >> wrote: >> >>> On 31 Jan 2012, at 10:55 PM, Sanne Grinovero wrote: >>> >>>> Why is the "annotation indexing" discussion part of the metamodel? >>> Why not? We are using Jandex in the new metamodel which is a >>> annotation index/repository >>> >>>> I initially understood that a replacement of commons-annotations was >>>> being developed, which would be nice for Search too as Search does not >>>> and should not depend on Hibernate ORM. >>> as Strong already said, there is no replacement module for >>> commons-annotations. There is no >>> need for it. >>> >>> And yes, Search should imo also switch to Jandex, however, it can >>> initially just create its own index. >>> Of course it might be nice to be able to use a Jandex index passed >>> to it via the integrator spi. Different story though. >>> >>> --Hardy >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> ------------------------- >> Best Regards, >> >> Strong Liu <stliu at hibernate.org> >> http://about.me/stliu/bio >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- steve(a)hibernate.org http://hibernate.org

Yes, thats what you said in the javadocs ;) What I mean is that we have a use case for one of those. But not the other. So why develop something that we do not have a use case for? On Mon 20 Aug 2012 11:23:14 PM CDT, Strong Liu wrote: > reuse the IntegratorService / ServiceLoader ? > > On Aug 21, 2012, at 2:14 AM, Steve Ebersole <steve(a)hibernate.org > <mailto:steve@hibernate.org>> wrote: > >> Also, I have been thinking that there really ought to be different >> types of "integrators". Not sure what we gain by forcing >> MetadataContributingIntegrator, ServiceContributingIntegrator, >> TypeContributingIntegrator, etc to extend Integrator >> >> >> On Sat 18 Aug 2012 05:50:29 PM CDT, Steve Ebersole wrote: >>> The general idea is good. But not really getting the point/purpose of >>> having both before and after hooks. > > BEFORE: > > modules can choose extend the MetadataSources with its own hbm/ann and > get Metadata (Binder) process it > > this is pretty like what envers does today, or what i'm hoping it > could do, so we could reuse lots of envers code > > AFTER: > > modify existing EntityBindings etc or create its own EntityBindings > based on the existing ones > > > > >>> >>> On 08/17/2012 01:12 AM, Strong Liu wrote: >>>> I'm thinking add the interface below, with it, modules like envers >>>> can choose either before or after the metamodel get processed to hook >>>> into its own extending mappings >>>> >>>> >>>> public interface MetadataContributingIntegrator extends Integrator { >>>> /** >>>> * Allow the integrator to alter the {@link MetadataImplementor} >>>> BEFORE {@link MetadataSources} get processed. >>>> * <p/> >>>> * >>>> * At this stage, metamode ( like {@link >>>> org.hibernate.metamodel.spi.binding.EntityBinding} etc. ) is not >>>> available yet. >>>> * This is a good time to add the custom sources into >>>> {@MetadataSources} and get it processed by Hibernate Metamodel. >>>> * >>>> * @param metadata The Metamodel which is going to be completed >>>> by processing MetadataSources. >>>> * @param source Meta data sources to be processed. >>>> */ >>>> public void beforeMetadataProcessing(MetadataImplementor >>>> metadata, MetadataSources source); >>>> >>>> /** >>>> * Allow the itnegrator to alter the {@link MetadataImplementor} >>>> AFTER @{@link MetadataSources} get processed. >>>> * <p/> >>>> * >>>> * At this stage, metamode ( like {@link >>>> org.hibernate.metamodel.spi.binding.EntityBinding} etc. ) is bindded. >>>> * So, it depends on the integrator to manually create metamodel >>>> and add it to {@link MetadataImplementor} or modifiy the >>>> * existing one. >>>> * >>>> * @param metadata >>>> * @param source >>>> */ >>>> public void afterMetadataProcessing(MetadataImplementor metadata, >>>> MetadataSources source); >>>> } >>>> >>>> downside is, envers with old metamodel calls >>>> Configuration.buildMappings() again during the integration phase, so, >>>> its created hbm xml can be processed (again) before SF create, but >>>> with new metamodel, it is hard to do that I think ( or too time >>>> consuming ) >>>> >>>> and to create envers own metamodel ( hbm ) it needs to know the >>>> hibernate type of entity property, which can be easily get from >>>> Entitybinding but hard / duplicated to resolve from source by envers >>>> itself, so it seems we should choose "afterMetadataProcessing" >>>> >>>> but envers' hbm creation involves lots of code and pretty complicated >>>> ( to me :) it's better to reuse those code and choose >>>> "beforemetadataProcessing" and let new metamodel to take care of that. >>>> >>>> thoughts? >>>> >>>> >>>> On Aug 2, 2012, at 12:17 AM, Hardy Ferentschik <hardy(a)hibernate.org >>>> <mailto:hardy@hibernate.org>> >>>> wrote: >>>> >>>>> On 31 Jan 2012, at 10:55 PM, Sanne Grinovero wrote: >>>>> >>>>>> Why is the "annotation indexing" discussion part of the metamodel? >>>>> Why not? We are using Jandex in the new metamodel which is a >>>>> annotation index/repository >>>>> >>>>>> I initially understood that a replacement of commons-annotations was >>>>>> being developed, which would be nice for Search too as Search >>>>>> does not >>>>>> and should not depend on Hibernate ORM. >>>>> as Strong already said, there is no replacement module for >>>>> commons-annotations. There is no >>>>> need for it. >>>>> >>>>> And yes, Search should imo also switch to Jandex, however, it can >>>>> initially just create its own index. >>>>> Of course it might be nice to be able to use a Jandex index passed >>>>> to it via the integrator spi. Different story though. >>>>> >>>>> --Hardy >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> ------------------------- >>>> Best Regards, >>>> >>>> Strong Liu <stliu at hibernate.org <http://hibernate.org>> >>>> http://about.me/stliu/bio >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> >> >> -- >> steve(a)hibernate.org <mailto:steve@hibernate.org> >> http://hibernate.org > > ------------------------- > Best Regards, > > Strong Liu <stliu at hibernate.org <http://hibernate.org/>> > http://about.me/stliu/bio > -- steve(a)hibernate.org http://hibernate.org

On Aug 22, 2012, at 8:11 AM, Steve Ebersole <steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote: > Also, I think how you were expecting beforeMetadataProcessing to > happen can't really happen, but I suspect it is the more direct way to > port envers. > > I *think* what you were thinking is to have envers pass along its > extra EntitySource/EntityHierarchy stuff. You cannot just simply "add > the custom sources into {@MetadataSources} and get it processed by > Hibernate Metamodel" if you mean adding EntitySource/EntityHierarchy. > That is actually not the role of MetadataSources. MetadataSources is > a collection of sources for find metadata information; its the > collection of mapping files, annotated classes, annotated packages, > etc. org.hibernate.metamodel.spi.MetadataSourceProcessor > implementations (there is one for HBM and one for Annotations) are > responsible for taking the MetadataSources and building > EntityHierarchy instances and passing those off to binder. > > So I need to understand exactly what y'all want here in terms of > Envers since that is our primary use case for this. Are you wanting > to "contribute" additional EntityHierarchy structures? IIRC, old > envers code used to build in-memory DOM structures (or am I way off > base in my memroy there?); if that is the target, maybe contributing > JaxbRoots to MetadataSources is the way to go. Envers still builds in-memory DOM, and this is why I want a "beforeMetadataProcessing" ( the name is under discussion ) so we can call org.hibernate.metamodel.MetadataSources#addDocument but the problem here is, I'm not sure if envers could (easier) build a DOM without knowing metadata info ( like hibernate type of user provided mapping entity property ) > > Also, I wonder if we ought to rename MetadataSources to remove the > ambiguity, maybe MetadataOrigins or MetadataSourcesOrigins? > > On 08/21/2012 08:16 AM, Steve Ebersole wrote: >> Yes, thats what you said in the javadocs ;) >> >> What I mean is that we have a use case for one of those. But not the >> other. So why develop something that we do not have a use case for? >> >> On Mon 20 Aug 2012 11:23:14 PM CDT, Strong Liu wrote: >>> reuse the IntegratorService / ServiceLoader ? >>> >>> On Aug 21, 2012, at 2:14 AM, Steve Ebersole <steve(a)hibernate.org >>> <mailto:steve@hibernate.org> >>> <mailto:steve@hibernate.org>> wrote: >>> >>>> Also, I have been thinking that there really ought to be different >>>> types of "integrators". Not sure what we gain by forcing >>>> MetadataContributingIntegrator, ServiceContributingIntegrator, >>>> TypeContributingIntegrator, etc to extend Integrator >>>> >>>> >>>> On Sat 18 Aug 2012 05:50:29 PM CDT, Steve Ebersole wrote: >>>>> The general idea is good. But not really getting the point/purpose of >>>>> having both before and after hooks. >>> >>> BEFORE: >>> >>> modules can choose extend the MetadataSources with its own hbm/ann and >>> get Metadata (Binder) process it >>> >>> this is pretty like what envers does today, or what i'm hoping it >>> could do, so we could reuse lots of envers code >>> >>> AFTER: >>> >>> modify existing EntityBindings etc or create its own EntityBindings >>> based on the existing ones >>> >>> >>> >>> >>>>> >>>>> On 08/17/2012 01:12 AM, Strong Liu wrote: >>>>>> I'm thinking add the interface below, with it, modules like envers >>>>>> can choose either before or after the metamodel get processed to hook >>>>>> into its own extending mappings >>>>>> >>>>>> >>>>>> public interface MetadataContributingIntegrator extends Integrator { >>>>>> /** >>>>>> * Allow the integrator to alter the {@link MetadataImplementor} >>>>>> BEFORE {@link MetadataSources} get processed. >>>>>> * <p/> >>>>>> * >>>>>> * At this stage, metamode ( like {@link >>>>>> org.hibernate.metamodel.spi.binding.EntityBinding} etc. ) is not >>>>>> available yet. >>>>>> * This is a good time to add the custom sources into >>>>>> {@MetadataSources} and get it processed by Hibernate Metamodel. >>>>>> * >>>>>> * @param metadata The Metamodel which is going to be completed >>>>>> by processing MetadataSources. >>>>>> * @param source Meta data sources to be processed. >>>>>> */ >>>>>> public void beforeMetadataProcessing(MetadataImplementor >>>>>> metadata, MetadataSources source); >>>>>> >>>>>> /** >>>>>> * Allow the itnegrator to alter the {@link MetadataImplementor} >>>>>> AFTER @{@link MetadataSources} get processed. >>>>>> * <p/> >>>>>> * >>>>>> * At this stage, metamode ( like {@link >>>>>> org.hibernate.metamodel.spi.binding.EntityBinding} etc. ) is bindded. >>>>>> * So, it depends on the integrator to manually create metamodel >>>>>> and add it to {@link MetadataImplementor} or modifiy the >>>>>> * existing one. >>>>>> * >>>>>> * @param metadata >>>>>> * @param source >>>>>> */ >>>>>> public void afterMetadataProcessing(MetadataImplementor metadata, >>>>>> MetadataSources source); >>>>>> } >>>>>> >>>>>> downside is, envers with old metamodel calls >>>>>> Configuration.buildMappings() again during the integration phase, so, >>>>>> its created hbm xml can be processed (again) before SF create, but >>>>>> with new metamodel, it is hard to do that I think ( or too time >>>>>> consuming ) >>>>>> >>>>>> and to create envers own metamodel ( hbm ) it needs to know the >>>>>> hibernate type of entity property, which can be easily get from >>>>>> Entitybinding but hard / duplicated to resolve from source by envers >>>>>> itself, so it seems we should choose "afterMetadataProcessing" >>>>>> >>>>>> but envers' hbm creation involves lots of code and pretty complicated >>>>>> ( to me :) it's better to reuse those code and choose >>>>>> "beforemetadataProcessing" and let new metamodel to take care of >>>>>> that. >>>>>> >>>>>> thoughts? >>>>>> >>>>>> >>>>>> On Aug 2, 2012, at 12:17 AM, Hardy Ferentschik >>>>>> <hardy(a)hibernate.org <mailto:hardy@hibernate.org> >>>>>> <mailto:hardy@hibernate.org>> >>>>>> wrote: >>>>>> >>>>>>> On 31 Jan 2012, at 10:55 PM, Sanne Grinovero wrote: >>>>>>> >>>>>>>> Why is the "annotation indexing" discussion part of the metamodel? >>>>>>> Why not? We are using Jandex in the new metamodel which is a >>>>>>> annotation index/repository >>>>>>> >>>>>>>> I initially understood that a replacement of >>>>>>>> commons-annotations was >>>>>>>> being developed, which would be nice for Search too as Search >>>>>>>> does not >>>>>>>> and should not depend on Hibernate ORM. >>>>>>> as Strong already said, there is no replacement module for >>>>>>> commons-annotations. There is no >>>>>>> need for it. >>>>>>> >>>>>>> And yes, Search should imo also switch to Jandex, however, it can >>>>>>> initially just create its own index. >>>>>>> Of course it might be nice to be able to use a Jandex index passed >>>>>>> to it via the integrator spi. Different story though. >>>>>>> >>>>>>> --Hardy >>>>>>> _______________________________________________ >>>>>>> hibernate-dev mailing list >>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>> <mailto:hibernate-dev@lists.jboss.org> >>>>>>> <mailto:hibernate-dev@lists.jboss.org> >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> ------------------------- >>>>>> Best Regards, >>>>>> >>>>>> Strong Liu <stliu at hibernate.org <http://hibernate.org> >>>>>> <http://hibernate.org>> >>>>>> http://about.me/stliu/bio >>>>>> >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>>> >>>> >>>> -- >>>> steve(a)hibernate.org <mailto:steve@hibernate.org> >>>> <mailto:steve@hibernate.org> >>>> http://hibernate.org >>> >>> ------------------------- >>> Best Regards, >>> >>> Strong Liu <stliu at hibernate.org <http://hibernate.org> >>> <http://hibernate.org/>> >>> http://about.me/stliu/bio >>> >> >> -- >> steve(a)hibernate.org <mailto:steve@hibernate.org> >> http://hibernate.org > > -- > steve(a)hibernate.org <mailto:steve@hibernate.org> > http://hibernate.org ------------------------- Best Regards, Strong Liu <stliu at hibernate.org <http://hibernate.org/>> http://about.me/stliu/bio

Hello Steve, I think I could start working on metamodel branch at the beginning of September. Is it acceptable for you? I don't want to postpone 4.1.7 release. JIRA task has been already registered: https://hibernate.onjira.com/browse/HHH-7490. Best Regards, Lukasz __________ Information from ESET NOD32 Antivirus, version of virus signature database 7412 (20120823) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

Hello Steve, Just wanted to let you know that I am trying to migrate Envers to new metamodel. I have asked below question on IRC, but without any response. At the moment Envers locates its annotations (for example @Audited) using ReflectionManager. What would be the preferable way of achieving this in metamodel branch? Shall I use EntityBinding#getClassReference() method and standard reflection API? Just a hint, please :). Regards, Lukasz 2012/8/24 Steve Ebersole <steve(a)hibernate.org&gt;: > Lukasz, as always, any help you can give is appreciated! Whenever you have > time. We have a temporary solution that will isolate needed changes to just > Envers. Basically the changes at some point will be using the JAXB binding > model rather than DOM. > > > On Fri 24 Aug 2012 01:55:55 AM CDT, Łukasz Antoniak wrote: >> >> Hello Steve, >> >> I think I could start working on metamodel branch at the beginning of >> September. Is it acceptable for you? I don't want to postpone 4.1.7 >> release. JIRA task has been already registered: >> https://hibernate.onjira.com/browse/HHH-7490. >> >> Best Regards, >> Lukasz >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 7412 (20120823) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> > > -- > steve(a)hibernate.org > http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Should have mentioned to look at Index, ClassInfo and AnnotationInstance to get a feel for the Jandex API. You find the Jandex project on Github - https://github.com/jbossas/jandex. I don't think there is a project website yet. --hardy On 7 Sep 2012, at 22:05, Łukasz Antoniak <lukasz.antoniak(a)gmail.com&gt; wrote: > Hello Steve, > > Just wanted to let you know that I am trying to migrate Envers to new > metamodel. I have asked below question on IRC, but without any > response. At the moment Envers locates its annotations (for example > @Audited) using ReflectionManager. What would be the preferable way of > achieving this in metamodel branch? Shall I use > EntityBinding#getClassReference() method and standard reflection API? > Just a hint, please :). > > Regards, > Lukasz > > 2012/8/24 Steve Ebersole <steve(a)hibernate.org&gt;: >> Lukasz, as always, any help you can give is appreciated! Whenever you have >> time. We have a temporary solution that will isolate needed changes to just >> Envers. Basically the changes at some point will be using the JAXB binding >> model rather than DOM. >> >> >> On Fri 24 Aug 2012 01:55:55 AM CDT, Łukasz Antoniak wrote: >>> >>> Hello Steve, >>> >>> I think I could start working on metamodel branch at the beginning of >>> September. Is it acceptable for you? I don't want to postpone 4.1.7 >>> release. JIRA task has been already registered: >>> https://hibernate.onjira.com/browse/HHH-7490. >>> >>> Best Regards, >>> Lukasz >>> >>> >>> __________ Information from ESET NOD32 Antivirus, version of virus >>> signature database 7412 (20120823) __________ >>> >>> The message was checked by ESET NOD32 Antivirus. >>> >>> http://www.eset.com >>> >>> >> >> -- >> steve(a)hibernate.org >> http://hibernate.org > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

It wont be via Integrator. This is the same discussion you and I had with Max wrt tooling. I'll ping you when Jandex is available for use by Envers (I'll take care of all the wiring). Hopefully should be done tomorrow or the day after. On 09/08/2012 05:37 AM, Łukasz Antoniak wrote: > Hello Hardy, > > Thank you for the clarification. This is what I thought initially by > looking at the code. I have reviewed the relevant mailing list topic, > and would agree that Jandex repository should be passed to integrator > somehow. Other Hibernate extensions probably introduce custom > annotations as well. Looking at MetadataSources#buildJandexView() I > suppose that Jandex indexes all annotations applied, not just a > predefined subset (JPA), so there would be no need for Envers to > create its own index. I am researching other Envers tasks, so no need > to rush with the decision. > > Regards, > Lukasz > > 2012/9/8 Hardy Ferentschik <hardy(a)hibernate.org&gt;: >> Should have mentioned to look at Index, ClassInfo and >> AnnotationInstance to get a feel for the Jandex API. You find the >> Jandex project on Github - https://github.com/jbossas/jandex. I >> don't think there is a project website yet. >> >> --hardy >> >> >> >> On 7 Sep 2012, at 22:05, Łukasz Antoniak <lukasz.antoniak(a)gmail.com&gt; >> wrote: >> >>> Hello Steve, >>> >>> Just wanted to let you know that I am trying to migrate Envers to new >>> metamodel. I have asked below question on IRC, but without any >>> response. At the moment Envers locates its annotations (for example >>> @Audited) using ReflectionManager. What would be the preferable way of >>> achieving this in metamodel branch? Shall I use >>> EntityBinding#getClassReference() method and standard reflection API? >>> Just a hint, please :). >>> >>> Regards, >>> Lukasz >>> >>> 2012/8/24 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> Lukasz, as always, any help you can give is appreciated! Whenever >>>> you have >>>> time. We have a temporary solution that will isolate needed >>>> changes to just >>>> Envers. Basically the changes at some point will be using the >>>> JAXB binding >>>> model rather than DOM. >>>> >>>> >>>> On Fri 24 Aug 2012 01:55:55 AM CDT, Łukasz Antoniak wrote: >>>>> >>>>> Hello Steve, >>>>> >>>>> I think I could start working on metamodel branch at the >>>>> beginning of >>>>> September. Is it acceptable for you? I don't want to postpone 4.1.7 >>>>> release. JIRA task has been already registered: >>>>> https://hibernate.onjira.com/browse/HHH-7490. >>>>> >>>>> Best Regards, >>>>> Lukasz >>>>> >>>>> >>>>> __________ Information from ESET NOD32 Antivirus, version of virus >>>>> signature database 7412 (20120823) __________ >>>>> >>>>> The message was checked by ESET NOD32 Antivirus. >>>>> >>>>> http://www.eset.com >>>>> >>>>> >>>> >>>> -- >>>> steve(a)hibernate.org >>>> http://hibernate.org >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

On 22 Jan 2012, at 2:11 AM, Steve Ebersole wrote: > Also, I wonder if we ought to rename MetadataSources to remove the > ambiguity, maybe MetadataOrigins or MetadataSourcesOrigins? Not so fond of this. Then you would have to almost rename MetadataSource as well.

Even though I also get sometimes confused by the fine distinction between MetadataSource and MetadataSources. If renaming I prefer something like MetadataSourceCollector.