Skip to main content
This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
arunpatidar
arunpatidarAccepted solution
Community Advisor
November 19, 2024

Hi @tom_fought 
Here is the difference

 

n Adobe Experience Manager (AEM), both com.day.cq.workflow and com.adobe.granite.workflow are Java APIs related to workflow management, but they belong to different stages of AEM's evolution and serve slightly different purposes. Here's a breakdown of the differences:

1. Namespace Origin

  • com.day.cq.workflow:

    • This API comes from an older version of AEM when the product was owned by Day Software. It reflects the legacy codebase and earlier workflow systems.
    • It is still present for backward compatibility but is generally considered deprecated for new development.

  • com.adobe.granite.workflow:

    • This is the newer, modernized API introduced by Adobe after acquiring Day Software. It aligns with the updated architecture and Adobe's enhancements to the workflow system.
    • It is actively maintained and should be used for new implementations.

2. Architectural Alignment

  • com.day.cq.workflow:

    • Tightly coupled with the older JCR-based implementation of workflows.
    • Interacts primarily with the repository at a low level, often relying on raw JCR nodes for workflow metadata and execution.

  • com.adobe.granite.workflow:

    • Abstracts away much of the low-level JCR complexity.
    • Aligns with the Granite platform's extensibility and modular architecture.
    • Provides more modern, flexible, and scalable mechanisms for workflow interaction.

3. Feature Enhancements

  • com.day.cq.workflow:

    • Limited to the features available in earlier AEM versions.
    • Basic workflow creation, execution, and management capabilities.

  • com.adobe.granite.workflow:

    • Enhanced with features like better integration with AEM's Sling and OSGi architecture.
    • Supports transient workflows, better performance, and scalability improvements.
    • Offers APIs for event-driven workflows, enhanced security, and future-proof integrations.

4. Recommended Usage

  • For legacy projects, the com.day.cq.workflow API might still be necessary for maintaining backward compatibility.
  • For new projects, always use com.adobe.granite.workflow as it is the modern, preferred approach and offers better support for current AEM features.

 

Feature com.day.cq.workflow com.adobe.granite.workflow
Namespace Origin Day Software (Legacy) Adobe (Modern)
Architecture JCR-centric Granite Platform, OSGi-compliant
Use Case Legacy compatibility Modern workflows
Feature Support Basic Enhanced and scalable
Recommendation Use for maintenance of old code Use for all new implementations



Note : GenAI Generated content but the information is from Adobe docs.

Arun Patidar
View in thread

2 replies

Tom_FoughtAuthor
Level 4
November 19, 2024

So I found this on stackoverflow written 10, TEN!, years ago.

https://stackoverflow.com/questions/26790931/differences-between-traditional-packages-com-day-cq-workflow-and-com-adobe-grani

No replies. 

Any comments?

Translate
arunpatidar
Community Advisor
arunpatidarCommunity AdvisorAccepted solution
Community Advisor
November 19, 2024

Hi @tom_fought 
Here is the difference

 

n Adobe Experience Manager (AEM), both com.day.cq.workflow and com.adobe.granite.workflow are Java APIs related to workflow management, but they belong to different stages of AEM's evolution and serve slightly different purposes. Here's a breakdown of the differences:

1. Namespace Origin

  • com.day.cq.workflow:

    • This API comes from an older version of AEM when the product was owned by Day Software. It reflects the legacy codebase and earlier workflow systems.
    • It is still present for backward compatibility but is generally considered deprecated for new development.

  • com.adobe.granite.workflow:

    • This is the newer, modernized API introduced by Adobe after acquiring Day Software. It aligns with the updated architecture and Adobe's enhancements to the workflow system.
    • It is actively maintained and should be used for new implementations.

2. Architectural Alignment

  • com.day.cq.workflow:

    • Tightly coupled with the older JCR-based implementation of workflows.
    • Interacts primarily with the repository at a low level, often relying on raw JCR nodes for workflow metadata and execution.

  • com.adobe.granite.workflow:

    • Abstracts away much of the low-level JCR complexity.
    • Aligns with the Granite platform's extensibility and modular architecture.
    • Provides more modern, flexible, and scalable mechanisms for workflow interaction.

3. Feature Enhancements

  • com.day.cq.workflow:

    • Limited to the features available in earlier AEM versions.
    • Basic workflow creation, execution, and management capabilities.

  • com.adobe.granite.workflow:

    • Enhanced with features like better integration with AEM's Sling and OSGi architecture.
    • Supports transient workflows, better performance, and scalability improvements.
    • Offers APIs for event-driven workflows, enhanced security, and future-proof integrations.

4. Recommended Usage

  • For legacy projects, the com.day.cq.workflow API might still be necessary for maintaining backward compatibility.
  • For new projects, always use com.adobe.granite.workflow as it is the modern, preferred approach and offers better support for current AEM features.

 

Feature com.day.cq.workflow com.adobe.granite.workflow
Namespace Origin Day Software (Legacy) Adobe (Modern)
Architecture JCR-centric Granite Platform, OSGi-compliant
Use Case Legacy compatibility Modern workflows
Feature Support Basic Enhanced and scalable
Recommendation Use for maintenance of old code Use for all new implementations



Note : GenAI Generated content but the information is from Adobe docs.

Translate
Arun Patidar
    Terms & ConditionsAccessibility statement

    Loading footer...