Return-Path: X-Original-To: apmail-hadoop-common-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-common-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 73EA118707 for ; Tue, 7 Jul 2015 02:14:05 +0000 (UTC) Received: (qmail 44853 invoked by uid 500); 7 Jul 2015 02:14:05 -0000 Delivered-To: apmail-hadoop-common-issues-archive@hadoop.apache.org Received: (qmail 44799 invoked by uid 500); 7 Jul 2015 02:14:05 -0000 Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-issues@hadoop.apache.org Delivered-To: mailing list common-issues@hadoop.apache.org Received: (qmail 44783 invoked by uid 99); 7 Jul 2015 02:14:05 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Jul 2015 02:14:05 +0000 Date: Tue, 7 Jul 2015 02:14:05 +0000 (UTC) From: "Andrew Wang (JIRA)" To: common-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HADOOP-11903) test-patch should fail any new classes called Default-foo MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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)