Yeah I think a 2.0 with some removed modules and Features is a good start We may remove more with Jakarta ee 10
Mark Struberg <[email protected]> schrieb am Sa., 11. Sept. 2021, 20:53: > 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 > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >
