@john: i've discussed it with mark recently (for a new feature we could add). however, just for the existing parts there isn't a significant benefit compared to the additional expenses (maintenance, different releases,...)
we don't need to move to @Vetoed, since we could use @Exclude already. your comment about @Transactional isn't correct (it's similar, but not the same). -> we can't drop something from the jpa module at all. in case of the jsf module only ~4 classes (for handling the optional jsf 2.2 support) would get simpler. just for moving to CDI#current and dropping two small modules, the additional expenses are too serious imo. so far we haven't agreed on branches aligned with the revisions of java ee itself. some users without ee-servers might need a mixture. e.g. if they can't upgrade the version of jsf (e.g. due to a component library they have to use) as quickly as other parts. @arne: there are only few parts we could change at all and only some of them can be encapsulated in an useful manner. that worked for myfaces extval, but imo it isn't the same here. regards, gerhard 2014-10-01 9:35 GMT+02:00 Arne Limburg <[email protected]>: > 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 > >
