[
https://issues.apache.org/jira/browse/HADOOP-11903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616063#comment-14616063
]
Andrew Wang commented on HADOOP-11903:
--------------------------------------
I'd be wary of including checkstyle-like functionality in Yetus because
eventually regexes aren't going to be enough. checkstyle for instance can
understand Java, so can do pattern matching on Java-level concepts like
classes, methods, interfaces, etc. Same for other language-specific lint tools;
they will be more powerful, general, and better at linting.
Since I take it Yetus doesn't want to be in the linting business, again my 2c
is to avoid it altogether and leave it to the purpose-built tooling. It's
pretty easy to add checkstyle or whatever linter to a build, so I have a hard
time imagining a project which cares about these patterns and is also unwilling
to use a linter.
> test-patch should fail any new classes called Default-foo
> ---------------------------------------------------------
>
> Key: HADOOP-11903
> URL: https://issues.apache.org/jira/browse/HADOOP-11903
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: yetus
> Affects Versions: HADOOP-12111
> Reporter: Allen Wittenauer
> Assignee: Kengo Seki
> Attachments: HADOOP-11903.HADOOP-12111.00.patch
>
>
> In the past, we've named things like DefaultResourceCalculator,
> DefaultContainerExecutor, and DefaultCodec that do nothing but cause problems
> down the road since they are effectively version and functionality locked
> forever. If these examples had been named what they truly were (e.g.,
> MemoryResourceCalculator, SimpleContainerExecutor, and GZipCodec), the
> defaults could then be changed in the future in a compatible way.
> One way to enforce this is to prevent the creation of new classes called
> Default-anything.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
