Open jamesnetherton opened 2 years ago
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..
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.
@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.
https://github.com/quarkusio/quarkus/commit/afaca21cc49064a78f79ce14345681065faf9e46#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 ?
So we might implement
CamelSalesForceCodeGen
inquarkus-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.
Some random things on this topic:
- 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.
raise upstream CAMEL-17306 to refactor the DTO generation codes.
@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.
yeah, feel free to take this issue. Thanks!
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 thegenerate-code
mojo.