Expand my Community achievements bar.

SOLVED

what is the difference between com.day.cq.workflow and com.adobe.granite.workflow?

Avatar

Level 4

Subject says it all. is cq.workflow deprecated?

Thanks.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

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 solution in original post

2 Replies

Avatar

Correct answer by
Community Advisor

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