Leverage Quarkus code generation for Salesforce DTO generation

[jamesnetherton]

It'd be good if we could leverage the code generation features of the quarkus-maven-plugin to do the generation of the Salesforce DTOs.

Currently this is handled by the camel-salesforce-maven-plugin. If we could make the core logic available is some artifact that our extension would depend on, then we should be able to add hooks for the generate-code mojo.

[zhfeng]

I aussme that the basic idea here is to implement such a class

public class CamelSalesForceCodeGen implements CodeGenProvider {
    @Override
    public String providerId() {
        return "camel-salesforce-codegen";
    }

    @Override
    public boolean trigger(CodeGenContext context) throws CodeGenException {
        /* the core logic in camel-salesforce-maven-plugin to generate DTOs */
        /* 
             1. fetch Object descriptions by RestClient
             2. use velocity engine to generate the DTOs java codes
         */
    }

}

some properies could be similar with the camel-salesforce-maven-plugin Mojo parameters

quarkus.camel.salesforce.codegen.skip = false
quarkus.camel.salesforce.codegen.includes = Account
quarkus.camel.salesforce.codegen.includePatterns = *
...

What's the benifit we can get from this enhancement ? Maybe generate different codes with launch mode, coulde be useful for testing purpose..

[ppalaga]

What's the benifit we can get from this enhancement ?

I think the main benefit is the ergonomy: end users do not need to maintain an extra version of an extra Maven plugin. All is done via Quarkus plugin (that must be there anyway) and the underlying CQ extension that must be there too.

[zhfeng]

@jamesnetherton I found there is a change in CodeGenContext which uses Config config instead of Map<String, String> properties to read the properties in build time.
quarkusio/quarkus@afaca21#diff-093e7aa039ebc68d29ba9fe5eee571a0298831111766385c33987bd227e62962

I assume that we need to use the Config to read the properties of quarkus.camel.salesforce.codegen.. So we might implement CamelSalesForceCodeGen in quarkus-main branch. WDYT ?

[jamesnetherton]

So we might implement CamelSalesForceCodeGen in quarkus-main branch. WDYT ?

Quarkus 2.5.0.CR1 will be released some time today. So I'll be merging quarkus-main to main. So lets wait for that and any work related to cogen can continue on main as per normal.

[lburgazzoli]

Some random things on this topic:

• wonder if the same model can then be extended to servicenow and openapi route generator
• wonder it we can leverage camel components extension to have a generic generator at Camel level that camel quarkus can leverage

[jamesnetherton]

• wonder if the same model can then be extended to servicenow and openapi route generator

Yes, I was thinking the same thing. We should try to do the same for those other extensions. I can create issues for that.

wonder it we can leverage camel components extension to have a generic generator at Camel level that camel quarkus can leverage

I think that's the general aim. I.e have something in Camel that both the maven plugin and quarkus extension can reuse so we don't end up reinventing everything in CQ.

[zhfeng]

raise upstream CAMEL-17306 to refactor the DTO generation codes.

[jamesnetherton]

@zhfeng Seems the required work on the Camel side is complete. Do you think we can complete the remaining tasks for the CQ side?

Would be nice to get it done for CQ 2.12.0 or 2.13.0 if possible. I could try to look into it if you do not have time right now.

[zhfeng]

yeah, feel free to take this issue. Thanks!