[
https://issues.apache.org/jira/browse/CALCITE-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17390804#comment-17390804
]
Lalith commented on CALCITE-4701:
---------------------------------
Author of that VMware PR here. The code in our build.gradle file, starting from
this line here [1], was the most cumbersome part to figure out. That said, it
seems like it could be wrapped into a gradle plugin offered by the calcite team
quite cleanly. Happy to test whatever you come up with.
[1]
https://github.com/vmware/declarative-cluster-management/blob/e46504209f6ae2dfb7333957fc1256a99565aea3/dcm/build.gradle#L113
> Implement and publish Gradle plugin for extending the parser
> ------------------------------------------------------------
>
> Key: CALCITE-4701
> URL: https://issues.apache.org/jira/browse/CALCITE-4701
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.27.0
> Reporter: Vladimir Sitnikov
> Priority: Major
>
> Currently, calcite-core.jar contains the relevant parser template files,
> however, the usage of the templates is not clear from the client perspective
> (especially when you are new to Calcite).
> It would be nice if Calcite published a plugin that simplifies building a
> parser extension.
> We could reuse the same plugin in calcite-babel module. Currently babel
> references $rootDir/core/... directrly rather than fetching the parser
> templates from core jar.
> It might make sense to ship parser templates in its own jar file, however, I
> have no strong opinion here. Parser.jj consumes <1% of the compressed jar
> size(225K compresses to 44K), so it is not a big deal, yet having a
> meaningful artifact name for the parser templates looks like the right thing
> to do.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
