Jetty dependency | Community
Skip to main content
S
sandeep
Level 1
March 2, 2026
Solved

Jetty dependency

  • March 2, 2026
  • 3 replies
  • 71 views

Usage of deprecated package found : org.eclipse.jetty.http : The Eclipse Jetty and Apache Felix Http Jetty packages are no longer supported. Deprecated since 2021-05-27 For removal : 2025-08-31

The cloud build log shows warnings/errors related to org.eclipse.jetty packages, which indicates that we must remove all Jetty imports from the project.

I reviewed the “Deprecated and Removed Features” page for Adobe Experience Manager and, based on its guidance, added all the recommended Jetty versions to the core POM. However, the issue still persists and the dependency conflict is not resolved. Since I cannot remove the Jetty‑dependent code, I need an alternative solution.

Best answer by AmitVishwakarma

Hi ​@sandeep ,
Cloud Manager is not complaining about a version of Jetty, it’s complaining about any usage of the org.eclipse.jetty packages at all. Those packages are deprecated for AEMaaCS and scheduled for removal, so adding different Jetty versions to your POM cannot fix it.

 

From Adobe’s deprecation list, Jetty is explicitly called out as a deprecated API family for AEMaaCS and is being enforced via the Analyzer/Cloud Manager checks:
https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/release-notes/deprecated-removed-features

https://experienceleague.adobe.com/en/docs/experience-manager-learn/cloud-service/developing/advanced/deprecated-apis-find-removal

What this means for your project

  • You cannot “solve” this with dependency management. As long as your bundles import or reference org.eclipse.jetty.* (or Felix Jetty HTTP), Cloud Manager will keep flagging it and, closer to the removal date, will start blocking deployments.
  • There is no supported override or exception for keeping Jetty inside AEMaaCS code.

Supported options

  • Refactor to non‑Jetty APIs (recommended, and what Adobe expects):
    • Replace Jetty server APIs with standard Servlet / Sling / OSGi Http Whiteboard and AEM servlets/filters.
    • Replace Jetty client APIs with Apache HttpComponents or the JDK HTTP client.
    • Remove org.eclipse.jetty.* and org.apache.felix.http.jetty from your Import-Package and dependencies.
  • If you absolutely must keep Jetty: move it out of AEM
    • Host that Jetty‑based code as a separate service (microservice) in your own infrastructure (or platform) and integrate with AEM via HTTP/REST.
    • The AEMaaCS codebase itself must not import Jetty.
  • There is no “alternative Jetty version” that will satisfy the Analyzer; the only compliant solution is to remove Jetty usage from the AEMaaCS deployment or move the Jetty‑dependent part outside AEM.

Thanks,
Amit

3 replies

AmitVishwakarma
Community Advisor
AmitVishwakarmaCommunity AdvisorAccepted solution
Community Advisor
March 2, 2026

Hi ​@sandeep ,
Cloud Manager is not complaining about a version of Jetty, it’s complaining about any usage of the org.eclipse.jetty packages at all. Those packages are deprecated for AEMaaCS and scheduled for removal, so adding different Jetty versions to your POM cannot fix it.

 

From Adobe’s deprecation list, Jetty is explicitly called out as a deprecated API family for AEMaaCS and is being enforced via the Analyzer/Cloud Manager checks:
https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/release-notes/deprecated-removed-features

https://experienceleague.adobe.com/en/docs/experience-manager-learn/cloud-service/developing/advanced/deprecated-apis-find-removal

What this means for your project

  • You cannot “solve” this with dependency management. As long as your bundles import or reference org.eclipse.jetty.* (or Felix Jetty HTTP), Cloud Manager will keep flagging it and, closer to the removal date, will start blocking deployments.
  • There is no supported override or exception for keeping Jetty inside AEMaaCS code.

Supported options

  • Refactor to non‑Jetty APIs (recommended, and what Adobe expects):
    • Replace Jetty server APIs with standard Servlet / Sling / OSGi Http Whiteboard and AEM servlets/filters.
    • Replace Jetty client APIs with Apache HttpComponents or the JDK HTTP client.
    • Remove org.eclipse.jetty.* and org.apache.felix.http.jetty from your Import-Package and dependencies.
  • If you absolutely must keep Jetty: move it out of AEM
    • Host that Jetty‑based code as a separate service (microservice) in your own infrastructure (or platform) and integrate with AEM via HTTP/REST.
    • The AEMaaCS codebase itself must not import Jetty.
  • There is no “alternative Jetty version” that will satisfy the Analyzer; the only compliant solution is to remove Jetty usage from the AEMaaCS deployment or move the Jetty‑dependent part outside AEM.

Thanks,
Amit

Amit Vishwakarma - Adobe Commerce Champion 2025 | 16x Adobe certified | 4x Adobe SME
    EstebanBustamante
    Community Advisor and Adobe Champion
    EstebanBustamanteCommunity Advisor and Adobe Champion
    Community Advisor and Adobe Champion
    March 3, 2026

    Hi ​@sandeep 

     

    From what I’ve seen so far, most of those packages are likely being pulled in through ACS Commons. In that case, the recommended approach would be to upgrade to the latest version of ACS Commons.

    You can clearly identify where the Jetty packages are coming from by using the Maven Analyze plugin. I’ve explained this in more detail in my response on the following thread regarding the same topic:

     

    If you confirm that ACS Commons is the dependency introducing the Jetty packages, upgrading it to the latest version should resolve the issue, if not, the plugin will tell you exactly where this dependency is being used for you to act on it.

     

    Hope this helps.

    Esteban Bustamante
    S
    sandeepAuthor
    Level 1
    March 4, 2026

    Hi ​@EstebanBustamante ,

    Jetty packages we are using in our codebase which I cannot change to any other third part libraries. That’s why i am asking for any suggestion to handle without changing the code.

    EstebanBustamante
    Community Advisor and Adobe Champion
    EstebanBustamanteCommunity Advisor and Adobe Champion
    Community Advisor and Adobe Champion
    March 4, 2026

    Oh, my bad — I didn’t realize you were intentionally using the Jetty HTTP packages. In that case, what ​@AmitVishwakarma  suggested covers all your available options.

    My recommendation would be to refactor the code to use a different library for HTTP handling. 

    Esteban Bustamante
      MukeshYadav_
      Community Advisor
      MukeshYadav_Community Advisor
      Community Advisor
      March 12, 2026

      Hi ​@sandeep ,

      Instead of  version upgrade of , better remove that dependency and use javax import which are already present in AEM.

      import javax.servlet.http.*;
      instead of
       import org.eclipse.jetty.http.*;

      e.g.
      import javax.servlet.http.HttpServletResponse;

      or to jakarta if on AEM LTS or newer version
      import javax.servlet.http.*;


      However you still want to go with  org.eclipse.jett
      Make sure you deploy exactly the version from below and do not embedd and export these packages.

        • org.eclipse.jetty:jetty-client:9.4.54.v20240208
        • org.eclipse.jetty:jetty-http:9.4.54.v20240208
        • org.eclipse.jetty:jetty-io:9.4.54.v20240208
        • org.eclipse.jetty:jetty-security:9.4.54.v20240208
        • org.eclipse.jetty:jetty-servlet:9.4.54.v20240208
        • org.eclipse.jetty:jetty-server:9.4.54.v20240208
        • org.eclipse.jetty:jetty-util:9.4.54.v20240208
        • org.eclipse.jetty:jetty-util-ajax:9.4.54.v20240208

      Refereance https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/release-notes/deprecated-removed-features?lang=en#api-removal-guidance
      Thanks

        Terms & ConditionsAccessibility statement

        Loading footer...