> 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
@thomas: +1
@micro-profile:
e.g. we should keep @Transactional
(however, we should align the api with the data-module)
@core:
if we really use cdi2 as the new baseline, we can drop the builders as well
as the literals for std. annotations.
@test-control:
we should drop the mock-support (and docu
Yep!
What about global alternatives? Could we remove them, too?
2017-06-03 21:32 GMT+02:00 John D. Ament :
> 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
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
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 (in
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 cha
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
@romain: +1
regards,
gerhard
2017-06-03 16:19 GMT+02:00 Romain Manni-Bucau :
> Hi
>
> Any strong feature from cdi 2 we need? If so +1 otherwise -1
>
> Le 3 juin 2017 16:07, "John D. Ament" a écrit :
>
> > Hey guys
> >
> > I'm not sure there's much more for us to do in 1.x as far as feature
>
Hi
Any strong feature from cdi 2 we need? If so +1 otherwise -1
Le 3 juin 2017 16:07, "John D. Ament" 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:
>
> - B
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 ca
10 matches
Mail list logo