Couldn't get details of com.adobe.granite.jobs.async.notification.email.EmailConfig during Adobe CQ DAM Expiry Notification customization

[DEBAL_DAS]

Hello All,

I am doing customization of Adobe CQ DAM Expiry Notification.

To understand the existing logic of Adobe CQ DAM Expiry Notification , I have de compiled the bundle(com.day.cq.dam-dam-core). Then noticed Adobe CQ DAM Expiry Notification is a scheduler named: ExpiryNotificationJobImpl.java and we are using one helper class named: MailHelper.java inExpiryNotificationJobImpl.java. MailHelper.java is using com.adobe.granite.jobs.async.notification.email.EmailConfig class.

While doing the modification I am having issue to import com.adobe.granite.jobs.async.notification.email.EmailConfig.

First I have find out the dependency as shown below -

Then added the maven dependency in pom.xml file but it didn't get downloaded.

I have searched com.adobe.granite.jobs.async.notification.email.EmailConfig api document also but couldn't see anything.

Do we have replacement of com.adobe.granite.jobs.async.notification.email.EmailConfig?

Is com.adobe.granite.jobs.async.notification.email.EmailConfig already deprecated?

I am using AEM 6.5.9

Please let me know.

[lukasz-m · Accepted solution]

Hi @DEBAL_DAS, I think that com.adobe.granite.jobs.async.notification.email.EmailConfig is part of internal API, that is not publically available and most likely can only be used by Adobe (because Adobe have access to it). I guess this is also the reason why you can not find documentation of this part of code. I doubt it is deprecated.

Nevertheless you can consider below options:

1. If you absolute have to use com.adobe.granite.jobs.async.notification.email.EmailConfig, then the only way I see, will be to copy the bundle into your internal maven repository or internal artifactory/nexus to have access to it, as to any other maven dependency. Technically this will work and you will be able to compile your code. I am not sure if this approach will not be against AEM license. It will also bring other drawback, e.g. every time you would like to install SP, you will need to at least check, if version of above bundle did not change, and if so update it on your side repeating entire process of coping it to your repository. Base on above I would not recommend to use that option.
2. The other option will be to write your own custom code, and if I good understand you already doing some customization so that should not be an issue. I agree that this will add more code in your project, but on the other hand you will have full control of the lifecycle of this code, you can cover it with unit test and/or integration test etc. So in my opinion this option have also some positive aspects.