Return-Path: X-Original-To: apmail-giraph-dev-archive@www.apache.org Delivered-To: apmail-giraph-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E9529D934 for ; Sun, 1 Jul 2012 22:27:40 +0000 (UTC) Received: (qmail 19995 invoked by uid 500); 1 Jul 2012 22:27:40 -0000 Delivered-To: apmail-giraph-dev-archive@giraph.apache.org Received: (qmail 19924 invoked by uid 500); 1 Jul 2012 22:27:40 -0000 Mailing-List: contact dev-help@giraph.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@giraph.apache.org Delivered-To: mailing list dev@giraph.apache.org Received: (qmail 19915 invoked by uid 99); 1 Jul 2012 22:27:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Jul 2012 22:27:40 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jghoman@gmail.com designates 74.125.82.54 as permitted sender) Received: from [74.125.82.54] (HELO mail-wg0-f54.google.com) (74.125.82.54) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Jul 2012 22:27:35 +0000 Received: by wgbfg15 with SMTP id fg15so3648493wgb.11 for ; Sun, 01 Jul 2012 15:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Zf5Jjt8HZfbxA3oH4aOanDPecJjZTrDzHijnIWRty7I=; b=cKn0FdbwWqwgJt3f2OrqmLrafKasIWvYEOjb7iihypwZU9UMOR3FnVOeF6cD0TsT4G 8Em8LZIoTvWPVDksO0fCCdtgHWzjE5oozJnTxv45ZK80c0kmC5TRWk7UYozd4AJp+nu5 LuycqHQbra652S7p6GQqCy5JZ51T76CGAzTdg5V7n6jyfr/T+NkcXak0nUuNcWcOnvZO TE59bLHpwkKzurBJeTxHAbEChhlKYMID7VzYQRz7YmePThd0dy8rYYDvcUfb8hcvb14d Icrq6kFP8UJEevDC3irIMdbRa6j8cozauoI8sB9i67F4D7Amx9xWO5SVVgHfVnKzMsyJ JKaw== Received: by 10.180.78.33 with SMTP id y1mr4990609wiw.3.1341181634275; Sun, 01 Jul 2012 15:27:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.109.165 with HTTP; Sun, 1 Jul 2012 15:26:43 -0700 (PDT) In-Reply-To: References: From: Jakob Homan Date: Sun, 1 Jul 2012 15:26:43 -0700 Message-ID: Subject: Re: Order of imports To: dev@giraph.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org There needs to be special configuration for devs to support these new restrictions, if they are going to go in (-1 otherwise). And yes, Eclipse will need to be supported automatically as well. As for NetBeans... well, there may be some wiggle room there. On Sun, Jul 1, 2012 at 3:25 PM, Alessandro Presta wrote: > I think we can also just include the pre-configured files in the .idea/ > folder in the project root. I can find out how that works. > > On 7/1/12 11:20 PM, "Hyunsik Choi" wrote: > >>If IDE configurations should be provided, they can be available from the >>web page. For example, the section 'Generating Patches' in the home ( >>http://giraph.apache.org) would be good place. >> >>-- >>Hyunsik Choi >> >>On Mon, Jul 2, 2012 at 7:15 AM, Alessandro Presta >>wrote: >> >>> I don't think we currently have IDE configurations in the repo. We >>>should >>> do that. I can see how that works for IntelliJ IDEA. Anyone using >>>Eclipse? >>> >>> On 7/1/12 11:06 PM, "Hyunsik Choi" wrote: >>> >>> >That seems a great idea. In addition to the order of imports, it will >>>be >>> >better if all coding convention is included in both IDE configurations. >>> > >>> >-- >>> >Hyunsik Choi >>> > >>> >On Mon, Jul 2, 2012 at 3:13 AM, Avery Ching >>> wrote: >>> > >>> >> I think uniformity is good. I think as long as IDE's support our >>>rules >>> >> (as Alessandro mentioned) this can only be better. We can continue >>>this >>> >> discussion per GIRAPH-230. >>> >> >>> >> Avery >>> >> >>> >> >>> >> On 7/1/12 8:35 AM, Alessandro Presta wrote: >>> >> >>> >>> I think we should strive to make the signal-to-noise ratio of our >>> >>>diffs as >>> >>> high as possible, while at the same time enforce a certain level of >>> >>> uniformity. >>> >>> Besides, we already have a bunch of conventions for imports in >>> >>> checkstyle.xml, so this is straightforward. >>> >>> IDEA (and I'm pretty sure Eclipse too) can organize your imports >>>given >>> >>>a >>> >>> set of rules, and there are also Checkstyle plugins that run checks >>> >>>while >>> >>> you're coding. >>> >>> >>> >>> On 6/30/12 6:43 AM, "Jakob Homan" wrote: >>> >>> >>> >>> My thought is that after reviewing a lot of patches, I honestly >>>don't >>> >>>> care about the imports... If your IDE can do something sensible >>>with >>> >>>> them, that's great. But they have no effect on the code or add any >>> >>>> extra effort to the code reviews. >>> >>>> >>> >>>> >>> >>>> On Fri, Jun 29, 2012 at 10:34 PM, Avery Ching >>> >>>>wrote: >>> >>>> >>> >>>>> It's not silly at all. I suggest that we add some checkstyle >>>rules >>> >>>>>for >>> >>>>> enforcing our convention as well. >>> >>>>> >>> >>>>> >>> >>>>>http://checkstyle.sourceforge.**net/config_imports.html< >>> http://checkst >>> >>>>>yle.sourceforge.net/config_imports.html> >>> >>>>> >>> >>>>> I like AvoidStarImport, RedundantImport, UnusedImports, and (most >>> >>>>> related to >>> >>>>> this question) ImportOrder. >>> >>>>> >>> >>>>> Any thoughts? >>> >>>>> >>> >>>>> Avery >>> >>>>> >>> >>>>> On 6/29/12 8:23 AM, Alessandro Presta wrote: >>> >>>>> >>> >>>>>> Hi all, >>> >>>>>> >>> >>>>>> Kind of a silly concern, but nevertheless: >>> >>>>>> >>> >>>>>> IntelliJ IDEA does a great job at optimizing imports for you. >>>While >>> >>>>>> doing >>> >>>>>> so, it also insists in reorganizing them following some logic. >>> >>>>>> Since it's not nice to have a patch dirtied by imports reordering >>> >>>>>>every >>> >>>>>> time a different person touches a class, it could be a good idea >>>to >>> >>>>>> come up >>> >>>>>> with a convention and configure our IDEs accordingly. >>> >>>>>> >>> >>>>>> Example (blank lines matter): >>> >>>>>> >>> >>>>>> org.apache.giraph.* >>> >>>>>> >>> >>>>>> org.* >>> >>>>>> >>> >>>>>> com.* >>> >>>>>> >>> >>>>>> javax.* >>> >>>>>> java.* >>> >>>>>> >>> >>>>>> Or any variation you prefer. >>> >>>>>> >>> >>>>>> If there is agreement we can update the code conventions. >>> >>>>>> >>> >>>>>> Alessandro >>> >>>>>> >>> >>>>>> >>> >> >>> >> >>> >>> >