Hi Mridul, +1 for this cleanup.
This will be a great cleanup for the codebase and will help prevent any confusion for developers moving forward. Best regards, --- Arun Patidar On Thu, May 28, 2026 at 12:55 PM Nicolas Malin via dev <[email protected]> wrote: > +1, > > If we have someone that are already used, I suggest to move them on plugin. > > More generally for this third api my heart balance to keep only them are > maintain by one or more identified committer, like jenkins plugins [1]. > And if no active commiter are present, we can plan to move it on attic. > > Nicolas > > [1] https://plugins.jenkins.io/ > > On 5/28/26 08:44, Mridul Pathak wrote: > > I completely agree Jacopo. We need to thoroughly review the codebase to > > identify and remove unmaintained features and code for long-term > stability. > > > > I have a similar feeling about payment integrations, most were > implemented > > long ago and must be using deprecated APIs. I plan to review those next. > > > > Regards, > > Mridul Pathak > > > > On Thu, May 28, 2026 at 12:00 PM Jacopo Cappellato < > > [email protected]> wrote: > > > >> +1, I agree with this decision. > >> > >> More broadly, I think we should adopt a similar strategy across all > OFBiz > >> features: either the community actively maintains a feature, or we > should > >> seriously consider removing it. > >> > >> The OFBiz codebase is already large, and historically our attitude has > >> often been to accept new features and keep them indefinitely because, > even > >> if we do not know it, “someone may still use them”. While > understandable, > >> this approach also means accumulating code that is no longer actively > >> maintained, is not updated alongside external dependencies, receives > little > >> or no bug fixing, and increases the maintenance burden. > >> > >> If we care about stability, overall quality, and making wise use of the > >> limited time and energy of the volunteers maintaining this codebase, I > >> think we should be more proactive in identifying unsupported or > effectively > >> abandoned features and cleaning them up when necessary. > >> > >> In this specific case, removing integrations built around deprecated and > >> unsupported APIs seems like the right direction. > >> > >> Jacopo > >> > >> On Thu, May 28, 2026 at 7:54 AM Mridul Pathak<[email protected]> > >> wrote: > >> > >>> Hi All, > >>> > >>> The existing shipping integrations for UPS, USPS, FedEx, and DHL all > use > >>> deprecated SOAP/XML APIs, even though these carriers have already moved > >> to > >>> modern REST APIs. > >>> > >>> - UPS has officially deprecated the legacy access key and legacy > >>> SOAP/XML API in favour of RESTful API OAuth 2.0 security > protocols. ( > >>> https://developer.ups.com/oauth-developer-guide) > >>> - FedEx is completely retiring FedEx Web Services (SOAP/XML APIs) > by > >>> June 1, 2026. ( > >>> https://developer.fedex.com/wirc/browser/#/en-us/guides/migrate) > >>> - USPS retired the Web Tools API on January 25, 2026. ( > >>> https://www.usps.com/business/web-tools-apis/) > >>> - DHL integration uses the legacy DHL ShipIT XML API which is > obsolete > >>> and has been superseded by the modern DHL Express REST API. > >>> > >>> I propose removing and cleaning up these shipping integrations because > >> they > >>> are built on unsupported legacy APIs and are no longer maintained. > >>> > >>> Regards, > >>> Mridul Pathak > >>> >
