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

Reply via email to