Closed lmazuel closed 5 months ago
We can do this, but as 2024/03/04 it would not be meaningful, as Java don't have a generic core published anywhere. @srnagar
Of course, if the target is only to generate the code, but no need to compile, this would be valid.
As discussed, since the generic-core is not published to Maven Central yet, switching the default will result in unresolved dependencies for generic core. Also, the generic core APIs are still work in progress and we should not change the emitter to be generic by default until the APIs are stabilized.
a bit of thought on internal impl
we probably still want to keep the boolean in internal, e.g. isBranded
or isAzure
or isGeneric
. personally I don't want to see 10+ lines of if ("azure".equalIgnoreCase(settings.getFlavor()) {
scattered around the whole repo (feel free to discuss with Srikanta tomorrow).
I'm going to close this task, and we will create other tasks related with unbranding later, e.g. adopting generic-core, embedding flavor to generated code, make non-azure code as default (after generic-core go public). @lmazuel @srnagar @lirenhe Please let me know if you have any concern on closing this task. /cc @weidongxu-microsoft
flavor
that generates azure code for the valueazure
. This is not case-sensitive. Any other value does nothing, and therefore generates unbranded code.branded
to help the transition to the new system. If both flags are set, readflavor
first and ignorebranded
boolean flag.package-dir
starts withazure
, auto-setflavor
toazure
ifflavor
was not set already. Ifpackage-dir
is anything else, no specific behavior.