+1 to automatically fallback on hacks if we cant use cdi 1.1. Only thing to avoid would be to have 2 differznt dependencies to make migrations smooth
Le mercredi 1 octobre 2014, Arne Limburg <[email protected]> a écrit : > Ideally, we would encapsulate all the hacks and provide two > implementations. One for 1.0 with the hacks and one for 1.1 without the > hacks. > > Cheers, > Arne > > > Am 01.10.14 01:14 schrieb "John D. Ament" unter <[email protected]>: > >>HI all, >> >>I'd like to bring up the topic of how to best handle CDI 1.1/1.2 >>integration within DeltaSpike. If you look at our code, we have a few >>cases of "hacks" to make CDI 1.0 work cross container in our extensions. >>Much of this is fixed for CDI 1.1/1.2/EE7 so I was wondering how it would >>make sense for us to support those runtimes even better. Here are some of >>my thoughts. >> >>- Create a DS 1.1.0-SNAPSHOT branch for CDI 1.1/1.2 compatibility. >> 1.0.x-SNAPSHOT would remain for maintenance on this release line. We >>would have to determine branch naming strategy (e.g. does 1.1.0 go on >>master or a separate release branch?) >>- What features do we leverage? There's a bunch of things I see as >>problematic today >> - Keep BeanManagerProvider/BeanProvider but have them wrap >>CDI.current() instead of their current behaviour. >> - Replace usage of @Typed with @Vetoed >>- What do we enhance? >> - Our current @Transactional mirrors the EE7 transactional, except we >>support RESOURCE_LOCAL for JPA. >> - Certain modules become irrelevant (Servlet/BeanVal come to mind). >>Do >>we document how to migrate forward? >> - Certain modules can be significantly reduced (JPA/JSF). Do we do >>something similar? >> >> >>John > > -- Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau
