Well transitive dep issue is solved with proper boms. Think we should ask ourselves the future of DS. Im not fully convinced of the added value these days in current IT ecosystem so maybe it should be split in subprojects and some full parts dropped or given to other asf projects?
Le sam. 11 sept. 2021 à 17:29, Thomas Andraschko < [email protected]> a écrit : > 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 < > [email protected]>: > > > +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 > >> > > >> > > >> > > >
