apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bhupesh Chawda <bhup...@datatorrent.com>
Subject Re: Checkstyle policies with auto generated code
Date Wed, 26 Apr 2017 03:52:24 GMT
Option 3 seems okay to me.

~ Bhupesh


_______________________________________________________

Bhupesh Chawda

E: bhupesh@datatorrent.com | Twitter: @bhupeshsc

www.datatorrent.com  |  apex.apache.org



On Mon, Apr 24, 2017 at 7:53 PM, Vlad Rozov <v.rozov@datatorrent.com> wrote:

> +1 for option 3.
>
> Thank you,
>
> Vlad
>
>
> On 4/23/17 16:25, Ananth G wrote:
>
>> Hello All,
>>
>> Apologies if it is a repost as the earlier email did not seem to go
>> through.
>>
>> I have run into a dilemma and would like to know what our policy is to
>> deal
>> with the following situation.
>>
>> As part of the implementation for Kudu Input operator (
>> https://issues.apache.org/jira/browse/APEXMALHAR-2472) , I will be using
>> Antlr4 as the parser tool to parse a line of string as an SQL equivalent
>> statement to represent the set of tuples that will be streamed out of Kudu
>> store to the downstream operators.
>>
>> I will post the design once a few things are finalised in a separate
>> mailing thread and this mail is more about Checkstyle and Auto generated
>> code from tools like Antlr4.
>>
>> The design involves in writing a grammar file and let the maven tool
>> generate the parser and related code as .java files as part of the build
>> process. We only keep maintaining the grammar “.g4” file as part of the
>> repository checkins as Kudu functionality evolves. However this brings me
>> to the situation wherein the check style fails for the classes that are
>> autogenerated. Following are the three options that I think we have and
>> would like to get thoughts on what is the best way to go forward.
>>
>> *Option 1:* We let the autogenerated code generate code in the
>> "target/generated-sources” path. This is the default for the maven antler
>> plugin. This however does not pass check style maven plugin as check style
>> plugin does check styles for auto-generated code as well. The fix for this
>> is to modify check style plugin to only look at “src/“ folder paths as
>> opposed “compiled sources”. This works from a build perspective but the
>> drawback is that IDEs will not include the “target/generated-sources” for
>> class resolution. IDEs do have plugins to resolve this error code but
>> might
>> be considered irksome by the developer community.
>>
>> *Option 2:* We let Antlr4 code-gen to generate code in the Kudu package
>> path and of course checkstlye would fail this as well. The fix is to let
>> Checktyle include a “excludes” pattern and make check style ignore all
>> java
>> files that represent a pattern of files generated by the Antlr4 code-gen
>> tool. There is still an issue that remains to be resolved even if this
>> approach is approved by the community. The issue is the tool generates a
>> couple of “.token” files that are always placed in the root class path and
>> not under the package structure which will pollute the sanity a bit. I am
>> still working on this bit as this needs to be resolved.
>>
>> *Option 3:* Perhaps the ideal is to let a separate module for kudu from
>> the
>> top level to resolve all of the issues ideally ( i.e. token files are
>> generated in the kudu module root along with the java sources in the
>> correct package structure ) and I guess that is a separate discussion that
>> Thomas/Vlad and others are planning to take up as a separate thread in the
>> mailing list.
>>
>> Could you please let me what you think is the ideal path to pursue ( or if
>> there are other alternatives for the use case above )
>>
>> Regards,
>> Ananth
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message