> What about global alternatives? Could we remove them, too? I fear not. The way to achieve global alternatives in weld is by putting @Priority on any @Alternative. But then it's a priory enabled. One would have to explicitly veto that bean. We could probably do something with out ConfigExtension. We need to investigate further.
LieGrue, strub > Am 04.06.2017 um 13:04 schrieb Thomas Andraschko > <[email protected]>: > > Yep! > What about global alternatives? Could we remove them, too? > > 2017-06-03 21:32 GMT+02:00 John D. Ament <[email protected]>: > >> I agree with Thomas. While always minimal, if we can trim our internal >> libraries and make them a bit more user friendly, it will simplify how >> users leverage our modules (e.g. maybe we don't have a core module >> anymore). This means better module isolation. If Mark brings config to >> Geronimo via MP then we could even provide the legacy DeltaSpike Config as >> a compatibility layer for those using it. >> >> I'm also confused about the comment around "micro-profile" as well as "cdi2 >> as a new baseline once its really useful" >> >> John >> >> On Sat, Jun 3, 2017 at 2:58 PM Thomas Andraschko < >> [email protected]> wrote: >> >>> IMO we should try to do a cut in 2.0 and do a big cleanup (1.x should be >> in >>> maintenance to support < JavaEE8): >>> - Drop bval module and the servlet module. AFAIR the injection support is >>> already in JavaEE 8. >>> - We can also try to remove some core APIs (BeanManagerProvider) >>> - Cleanup the JSF Module (injection support is also available in JavaEE8) >>> - Cleanup Java8 hacks >>> >>> What parts to you mean which are required for a microprofile? >>> >>> >>> >>> 2017-06-03 17:42 GMT+02:00 Gerhard Petracek <[email protected]>: >>> >>>> imo there's not a lot we should drop, because users might need those >>> parts >>>> e.g. for applications based on the micro-profile. >>>> maybe it's just a matter of documenting an useful combination of ee8 + >> ds >>>> and/or to highlight which parts of ds are covered by ee8. >>>> >>>> @ds2: >>>> maybe we should mainly take the chance to improve the consistency (= >> few >>>> but breaking api-changes). >>>> (+ only use cdi2,... as a new baseline once it's really useful.) >>>> >>>> regards, >>>> gerhard >>>> >>>> >>>> >>>> 2017-06-03 16:35 GMT+02:00 Thomas Andraschko < >>> [email protected] >>>>> : >>>> >>>>> basically +1 >>>>> we can do some cleanup (like removing features + modules which are >>>>> available in JavaEE8) >>>>> BUT - many user won't use JavaEE8 until next year as the AS' are not >>>> ready. >>>>> So IMO it's not necessary now. >>>>> >>>>> I will currently start to do some internal cleanup on the Data Module >>>> e.g. >>>>> >>>>> 2017-06-03 16:21 GMT+02:00 Gerhard Petracek <[email protected]>: >>>>> >>>>>> @romain: +1 >>>>>> >>>>>> regards, >>>>>> gerhard >>>>>> >>>>>> >>>>>> >>>>>> 2017-06-03 16:19 GMT+02:00 Romain Manni-Bucau < >> [email protected] >>>> : >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> Any strong feature from cdi 2 we need? If so +1 otherwise -1 >>>>>>> >>>>>>> Le 3 juin 2017 16:07, "John D. Ament" <[email protected]> a >>>> écrit >>>>> : >>>>>>> >>>>>>>> Hey guys >>>>>>>> >>>>>>>> I'm not sure there's much more for us to do in 1.x as far as >>>> feature >>>>>>> goes, >>>>>>>> but I could be wrong. I do think we should start to ramp up >> work >>>>>>>> DeltaSpike 2.0: >>>>>>>> >>>>>>>> - Baseline on CDI 2.0, Java EE 8, Java 8 >>>>>>>> - Remove older components that are not needed any more >>>>>>>> - See if there's new features we can add >>>>>>>> >>>>>>>> Thoughts? I'm thinking this could either be a 2.x branch, or >> we >>>> move >>>>>>>> master to a 1.x maintenance branch while we work on 2.0 in >>> master. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
