Actually my fault. Apparently renaming the package was way too aggressive and renamed the artifact
On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole <[email protected]> wrote: > Ah, nm. They change the artifact name. Boo! > > On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole <[email protected]> > wrote: > >> Anyone know what happened to the 2.0 CDI artifact on Maven Central? It >> was there last week, but is no longer there... >> >> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole <[email protected]> >> wrote: >> >>> Thanks for the replies. So unless we hear otherwise from anyone else, I >>> will plan on supporting just one DI container. >>> >>> >>> >>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere <[email protected]> >>> wrote: >>> >>>> Same here, compositions don't seem to be a reasonable use case. And >>>> even if >>>> users provide a custom bean registry, they could just implement their >>>> specific behavior for a few specific case, then retrieve another >>>> implementations on their own and delegate to it however they want. >>>> Overriding the service initiator looks like a very reasonable way to do >>>> that. >>>> >>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>> appropriate to me, since CDI is not the only implementation we will get >>>> and >>>> we know it. Also, if I wanted to nitpick, injection is not really >>>> something >>>> the bean registry must provide. We could imagine a bean registry without >>>> any support for injection, after all, just providing "monolithic >>>> beans". It >>>> would still make sense with respect to your ManagedBeanRegistry API. >>>> >>>> >>>> Yoann Rodière >>>> Hibernate NoORM Team >>>> [email protected] >>>> >>>> On 14 December 2017 at 08:01, Christian Beikov < >>>> [email protected]> >>>> wrote: >>>> >>>> > I don't think someone is actually going to use more than a single DI >>>> > framework and even if they do, they will probably bridge one way or >>>> > another between the DI frameworks to be able to access beans from one >>>> in >>>> > the other. >>>> > >>>> > So I don't think we should do "compositions" since it's not a big deal >>>> > to integrate different DIs and is also IMO an edge case. I'd prefer >>>> the >>>> > package name `org.hibernate.resource.di` since CDI seems to be just >>>> one >>>> > of the possible "integrations". >>>> > >>>> > >>>> > Mit freundlichen Grüßen, >>>> > >>>> ------------------------------------------------------------------------ >>>> > *Christian Beikov* >>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are >>>> mainly >>>> > > about back porting the work I did on 6.0 for the ManagedBeanRegistry >>>> > > abstraction over dependency injection containers. We will ship >>>> support >>>> > for >>>> > > CDI as well as non-managed beans (things we directly instantiate). >>>> Of >>>> > > course we'd ideally make it easy to plug in other DI containers >>>> such as >>>> > > Spring. So I wanted to discuss the configuration of this support. >>>> > > >>>> > > The first thing to consider is whether we want to support using >>>> multiple >>>> > DI >>>> > > containers simultaneously. E.g. is it conceivable that an >>>> application >>>> > > might want to use both CDI and Spring simultaneously? I started >>>> building >>>> > > in support for that via a CompositeManagedBeanRegistry >>>> implementation, >>>> > but >>>> > > stepping back I want to gauge whether that is "reasonable" before >>>> > > continuing down that path >>>> > > >>>> > > Assuming that we do want to support such "compositions" the next >>>> question >>>> > > is how we see this being configured. Clearly any time a CDI >>>> BeanManager >>>> > is >>>> > > present during bootstrap we want to enable CDI ManagedBeanRegistry >>>> > > support. How would users indicate additional ManagedBeanRegistry >>>> impls >>>> > be >>>> > > added to the CompositeManagedBeanRegistry? I have opinions about >>>> this, >>>> > but >>>> > > I'd like to hear other's thoughts... >>>> > > >>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. >>>> So it >>>> > > would be possible to completely redefine ManagedBeanRegistry support >>>> > simply >>>> > > by replacing that initiator. >>>> > > >>>> > > A minor point... notice that the package name here is >>>> > > `org.hibernate.resource.cdi`, even though one of the goals here is >>>> to >>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >>>> different >>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>> > > ``org.hibernate.resource.di`? >>>> ``org.hibernate.resource.injection`? >>>> > > Other suggestions? I'm actually ok with >>>> `org.hibernate.resource.cdi` - >>>> > imo >>>> > > "cdi" conveys the proper intent. But if others feel strongly it >>>> should >>>> > be >>>> > > something else, I am open to hearing what and why. >>>> > > _______________________________________________ >>>> > > hibernate-dev mailing list >>>> > > [email protected] >>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >>>> > _______________________________________________ >>>> > hibernate-dev mailing list >>>> > [email protected] >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> _______________________________________________ hibernate-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/hibernate-dev
