+1 for removing these old integrations since the APIs are no longer supported. Regards, Chandan Khandelwal
On Thu, Jun 4, 2026 at 9:54 AM Arun Patidar <[email protected]> wrote: > 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 > > >>> > > >
