see: https://issues.apache.org/jira/browse/DELTASPIKE-1376?jql=project%20%3D%20DELTASPIKE%20AND%20fixVersion%20%3D%202.0
Am Sa., 11. Sept. 2021 um 17:25 Uhr schrieb Thomas Andraschko < andraschko.tho...@gmail.com>: > +1 > > i created some jira tickets for it 1-2 years ago > > Am Sa., 11. Sept. 2021 um 14:58 Uhr schrieb Cody Lerum < > cody.le...@gmail.com>: > >> +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 <strub...@yahoo.de.invalid> >> 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 >> > >> > >> >
