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