Le sam. 11 sept. 2021 à 18:46, Thomas Andraschko < [email protected]> a écrit :
> true romain > > i think the most features can you go into the the spec (e.g. CDI event > broadcast of JSF events should be in JSF directly) > i think the biggest module is Data, which cant be easily put into JPA > Can go into openjpa but i didnt see a lot of adoption so can stay in 1.x i guess > Am Sa., 11. Sept. 2021 um 18:42 Uhr schrieb Romain Manni-Bucau < > [email protected]>: > > > 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 > > > >> > > > > >> > > > > >> > > > > > > > > > >
