As in you are correct.

On May 19, 2014, at 8:12 PM, Gary Gregory <garydgreg...@gmail.com> wrote:

> Right what?
> 
> G
> 
> 
> On Mon, May 19, 2014 at 11:08 PM, Ralph Goers <ralph.go...@dslextreme.com> 
> wrote:
> Right
> 
> On May 19, 2014, at 6:30 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
>> Almost:
>> 
>> * imports are sorted java > javax > org > com
>> 
>> Gary
>> 
>> On Mon, May 19, 2014 at 6:39 PM, Remko Popma <remko.po...@gmail.com> wrote:
>> So, do we have consensus now?
>> 
>> * Wildcarts are allowed in static imports, only for junit.Assert, EasyMock 
>> and hamcrest.CoreMatchers.
>> * Static imports come after normal imports
>> * imports are sorted java > javax > com > org
>> 
>> 
>> 
>> 
>> On Mon, May 19, 2014 at 9:51 AM, Remko Popma <remko.po...@gmail.com> wrote:
>> Just those 3 is fine with me. 
>> 
>> Sent from my iPhone
>> 
>> On 2014/05/19, at 9:49, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>> 
>>> I would say only for the 3 Gary listed below.
>>> 
>>> Ralph
>>> 
>>> On May 18, 2014, at 5:36 PM, Remko Popma <remko.po...@gmail.com> wrote:
>>> 
>>>> Thanks! I'll try those settings. 
>>>> 
>>>> Do we have consensus that wildcarts can be used (only) for static imports?
>>>> 
>>>> Remko
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> On 2014/05/19, at 7:38, Gary Gregory <garydgreg...@gmail.com> wrote:
>>>> 
>>>>> You can say this in Eclipse:
>>>>> 
>>>>> #Organize Import Order
>>>>> #Sun May 18 17:18:10 EDT 2014
>>>>> 6=com
>>>>> 5=org
>>>>> 4=javax
>>>>> 3=java
>>>>> 2=\#org.junit.Assert
>>>>> 1=\#org.hamcrest.CoreMatchers
>>>>> 0=\#org.easymock.EasyMock
>>>>> 
>>>>> Where 0 is at the top and 6 at the bottom.
>>>>> 
>>>>> Gary
>>>>> 
>>>>> 
>>>>> On Sun, May 18, 2014 at 5:58 PM, Remko Popma <remko.po...@gmail.com> 
>>>>> wrote:
>>>>> Eclipse will group all static imports together at the top of the import 
>>>>> list. Not sure if this is configurable.
>>>>> 
>>>>> 
>>>>> On Mon, May 19, 2014 at 5:46 AM, Gary Gregory <garydgreg...@gmail.com> 
>>>>> wrote:
>>>>> So do static imports ALL come before normal imports or are they together 
>>>>> with imports for their group (org, com, and so on)?
>>>>> 
>>>>> IOW:
>>>>> 
>>>>> Like this:
>>>>> 
>>>>> import static org.junit.Assert.assertNotNull;
>>>>> import static org.junit.Assert.assertTrue;
>>>>> 
>>>>> import java.util.List;
>>>>> import java.util.Map;
>>>>> 
>>>>> import org.apache.logging.log4j.LogManager;
>>>>> import org.apache.logging.log4j.Logger;
>>>>> import org.apache.logging.log4j.LoggingException;
>>>>> 
>>>>> or like that:
>>>>> 
>>>>> import java.util.List;
>>>>> import java.util.Map;
>>>>> 
>>>>> import static org.junit.Assert.assertNotNull;
>>>>> import static org.junit.Assert.assertTrue;
>>>>> 
>>>>> import org.apache.logging.log4j.LogManager;
>>>>> import org.apache.logging.log4j.Logger;
>>>>> import org.apache.logging.log4j.LoggingException;
>>>>> 
>>>>> Gary
>>>>> 
>>>>> 
>>>>> On Sat, May 17, 2014 at 5:15 AM, Remko Popma <remko.po...@gmail.com> 
>>>>> wrote:
>>>>> Regarding static imports, I propose that we:
>>>>> 1) only use them in test classes
>>>>> 2) always use wildcard static imports
>>>>> 
>>>>> That would match our current usage almost perfectly. We now have a total 
>>>>> of 431 static imports in the project.
>>>>> 
>>>>> // NON-TEST class: remove static import & use qualified name here?
>>>>> PluginProcessor: 
>>>>> 41: import static javax.tools.Diagnostic.Kind.ERROR;  
>>>>> 42: import static javax.tools.StandardLocation.CLASS_OUTPUT;  
>>>>> 
>>>>> // all other static imports are in test classes:
>>>>> 
>>>>> org.junit.Assert.* 
>>>>> org.hamcrest.CoreMatchers.* // fluent interface would no longer be fluent 
>>>>> without static imports
>>>>> org.easymock.EasyMock.* // similar to org.junit.Assert.* IMHO
>>>>> 
>>>>> in LevelTest:
>>>>> import static org.apache.logging.log4j.Level.*; // I would keep this 
>>>>> static import:
>>>>> The test wants to do things like "Level[] levels = new Level[] { TRACE, 
>>>>> DEBUG, INFO, WARN, ERROR, FATAL };"
>>>>> this is short and clean. I don't see a need to remove the static import, 
>>>>> especially in the context of this being a test class for Levels. 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sat, May 17, 2014 at 1:46 PM, Ralph Goers <ralph.go...@dslextreme.com> 
>>>>> wrote:
>>>>> Here is what I have in Intellij - http://imgur.com/wU4Y3wO. I agree with 
>>>>> Remko that we should make an exception for org.junit.Assert.*
>>>>> 
>>>>> Ralph
>>>>> 
>>>>> On May 16, 2014, at 2:53 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
>>>>> 
>>>>>> I import most general (java, javax) to most specific (com) with org in 
>>>>>> between. I think this is the eclipse default. 
>>>>>> 
>>>>>> I want guidelines that eclipse can sort automatically.  This way there 
>>>>>> is no time wasting with manual fiddling. 
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>> 
>>>>>> -------- Original message --------
>>>>>> From: Paul Benedict
>>>>>> Date:05/16/2014 15:12 (GMT-05:00)
>>>>>> To: Log4J Developers List
>>>>>> Subject: Re: [proposal] import guidelines
>>>>>> 
>>>>>> I'd like to throw out something I've grown fond of, which is making 
>>>>>> one's home project the top import priority. For you guys, it would be 
>>>>>> "org.apache.logging.log4j". What I like so much about this choice is 
>>>>>> that it makes eye-balling the use of your own classes very apparent.
>>>>>> 
>>>>>> Paul
>>>>>> 
>>>>>> 
>>>>>> Cheers,
>>>>>> Paul
>>>>>> 
>>>>>> 
>>>>>> On Thu, May 15, 2014 at 12:44 PM, Gary Gregory <garydgreg...@gmail.com> 
>>>>>> wrote:
>>>>>> I propose we use the following guidelines for import statements:
>>>>>> 
>>>>>> https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk/src/ide/eclipse/4.3.2/organize-imports.importorder
>>>>>> 
>>>>>> which in Eclipse looks like this:
>>>>>> 
>>>>>> https://i.imgur.com/04C84XY.png
>>>>>> 
>>>>>> Note that default settings are not reflected in the .importorder file.
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>> -- 
>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>> JUnit in Action, Second Edition
>>>>>> Spring Batch in Action
>>>>>> Blog: http://garygregory.wordpress.com 
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> Blog: http://garygregory.wordpress.com 
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> Blog: http://garygregory.wordpress.com 
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>> 
>> 
>> 
>> 
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com 
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
> 
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

Reply via email to