+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 > >
