The import order is now:

...
import java.util.Map;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;
import static org.junit.Assert.assertTrue;
import org.apache.logging.log4j.Level;
...

This looks different from what I thought we had in mind...



On Tue, May 20, 2014 at 10:26 PM, Gary Gregory <garydgreg...@gmail.com>wrote:

> Commit done with new import guidelines.
>
> Gary
>
>
> On Mon, May 19, 2014 at 11:42 PM, Ralph Goers 
> <ralph.go...@dslextreme.com>wrote:
>
>> 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<http://www.manning.com/bauer3/>
>>>>>>>>>> JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>> 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<http://www.manning.com/bauer3/>
>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>> 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<http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> 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<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> 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<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> 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<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Reply via email to