Re: Removing deprecated shipping integrations

[Arun Patidar <ar...@hotwax.co>]

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 <de...@ofbiz.apache.org>
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 <
> > jacopo.cappellato@gmail.com> 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<mr...@apache.org>
> >> 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
> >>>
>

Re: Removing deprecated shipping integrations

[Chandan Khandelwal <ch...@hotwaxsystems.com>]

+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 <ar...@hotwax.co> 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 <
> dev@ofbiz.apache.org>
> 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 <
> > > jacopo.cappellato@gmail.com> 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<mridulpathak@apache.org
> >
> > >> 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
> > >>>
> >
>