+1 i created some jira tickets for it 1-2 years ago
Am Sa., 11. Sept. 2021 um 14:58 Uhr schrieb Cody Lerum <[email protected] >: > +1 > > 1.9.x seems very stable with minimal updates so it is unlikely to be > much of a burden to keep it alive for pre-Jakarta use. > > I could see some people say setting a JDK 17 minimum would be > aggressive, but those starting new Jakarta projects or going through > the upgrade work for an older project should really be moving up to > it. > > -C > > On Sat, Sep 11, 2021 at 6:48 AM Mark Struberg <[email protected]> > wrote: > > > > Hi folks! > > > > There was a bunch of user requests on the mailing list to add support > for Jakarta enterprise namespaces. > > I tried to implement this via shading but it seems not to be sufficient. > > The problem with shading is that the poms only have classifier to access > deltaspike. > > This is especially a problem with transitive dependencies. > > > > The other point is that we had many discussions about shipping an > upgraded version of DeltaSpike and deprecate/remove some obsolete APIs. > > So let's go big and why not move up to jakartaEE namespace and Java17 at > the same time? > > > > Potential candidates for dropping coming to my mind: > > > > .) BeanManagerProvider/BeanProvider. We historically kept this for 2 > reasons. 1.) backward compatibility with CDI-1.0, 2.) in EARs this is still > the only way which works to properly access the BeanManager on all > containers. CDI.current() is sadly broken in EARs in almost all containers. > But since EARs might go away in JakartaEE anyways, I'm fine with dropping > it. > > > > .) servlet module. Injecting the various servlet information objects > like HttpServletRequest, HttpSession etc is nowadays specified by the CDI > spec as well. > > > > .) Many parts of the JSF module are nowadays not needed anymore as well. > Remember the times when there was no injection into PhaseListeners and > FacesConverters? We did have support for it since ages, the spec added this > much later, but they finally did. > > > > .) bean validation module. Those parts are imo all part of the spec > nowadays > > > > .) scheduler. I'm not sure about that one. It probably would make sense > to implement an own smallish scheduler based on ScheduledExecutor instead > of going fully blown quartz? > > > > > > > > wdyt? > > > > I'd go on and create a new umbrella ticket for all the work. > > > > LieGrue, > > strub > > > > >
