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 <[email protected]> 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" <[email protected]> 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 <[email protected]> >>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" <[email protected]> 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 <[email protected]> >>> 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" <[email protected]> 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 <[email protected]> >>> >>>>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 >>> >>>>>> >>> >>>>>> >>> >> >>> >> >>> >>> >
