ds-core has still a ton of useful unique features. DS-config is probably the most mature config systems out there. @Exclude together with config -> feature switch on stereoids. I don't know any other project which provides this. @MessageBundle is another neat feature ProjectStage yet another
Other modules are still really worth it, e.g. the jpa module with @Transactional. This is still great since jakarta took over the broken javax.transaction.Transactional with the same borked Exception semantics like EJB. There is for sure a lot which can be ditched. E.g. exception eventing, injectable file resources, etc. But there is plenty of great stuff in here still. LieGrue, strub > Am 11.09.2021 um 18:48 schrieb Romain Manni-Bucau <[email protected]>: > > 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
