t;>>>>>>>>>>> garydgreg...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> So do static imports ALL come before normal imports or are
>>>>>>>>>>>&g
t;>>
>>>>>>>>>>>> Like this:
>>>>>>>>>>>>
>>>>>>>>>>>> import static org.junit.Assert.assertNotNull;
>>>>>>>>>>>> import static org.juni
t;>>>>>>>> import static org.junit.Assert.assertTrue;
>>>>>>>>>>>
>>>>>>>>>>> import java.util.List;
>>>>>>>>>>> import java.util.Map;
>>>>>>>>
ption;
>>>>>>>>>>
>>>>>>>>>> or like that:
>>>>>>>>>>
>>>>>>>>>> import java.util.List;
>>>>>>>>>> import java.util.Map;
>>>>>>>>
.Assert.assertTrue;
>>>>>>>>>
>>>>>>>>> import org.apache.logging.log4j.LogManager;
>>>>>>>>> import org.apache.logging.log4j.Logger;
>>>>>>>>> import org.apache.logging.log4j.LoggingE
og4j.Logger;
>>>>>>>> import org.apache.logging.log4j.LoggingException;
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, May 17, 2014 at 5:15 AM, Remko Popma >&g
t;>>>>>>> import org.apache.logging.log4j.LoggingException;
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, May 17, 2014 at 5:15 AM, Remko Popma >>>
y 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;
>
essor:
>>>>> 41: import static javax.tools.Diagnostic.Kind.ERROR;
>>>>> 42: import static javax.tools.StandardLocation.CLASS_OUTPUT;
>>>>>
>>>>> // all other static imports are in test classes:
>>>>>
>>>>>
t;>>>>> 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
>>>
ld 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
>>>> stat
g.junit.Assert.*
>>>>>> org.hamcrest.CoreMatchers.* // fluent interface would no longer be
>>>>>> fluent without static imports
>>>>>> org.easymock.EasyMock.* // similar to org.junit.Assert.* IMHO
>>>>>>
>>>>>> i
t;>> 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 th
>>>> 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 };"
t;
>>>>>> // 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.E
rt 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 };"
>>>>>
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
ean. 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
t;> 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 t
of this being a test class for Levels.
>>
>>
>>
>> On Sat, May 17, 2014 at 1:46 PM, Ralph Goers
>> 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.*
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
>
};"
>>>> 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, Ral
make an exception for org.junit.Assert.*
>>>>
>>>> Ralph
>>>>
>>>> On May 16, 2014, at 2:53 PM, Gary Gregory
>>>> wrote:
>>>>
>>>> I import most general (java, javax) to most specific (com) with org in
>>>> bet
ote:
>>>
>>>> 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
> > 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,
at 2:53 PM, Gary Gregory 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
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
>&g
regory
>>> 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
t; Ralph
>>>
>>> On May 16, 2014, at 2:53 PM, Gary Gregory
>>> 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
gt; 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 D
;>> 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/
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 f
Original message ----
>> From: Remko Popma
>> Date:05/17/2014 05:15 (GMT-05:00)
>> To: Log4J Developers List
>> Subject: Re: [proposal] import guidelines
>>
>> Regarding static imports, I propose that we:
>> 1) only use them in test classes
>>
ort stars in some
> source files and not others?
>
> Gary
>
>
> Original message
> From: Remko Popma
> Date:05/17/2014 05:15 (GMT-05:00)
> To: Log4J Developers List
> Subject: Re: [proposal] import guidelines
>
> Regarding static impor
formatter to only use static import stars in some
> source files and not others?
>
> Gary
>
>
> Original message
> From: Remko Popma
> Date:05/17/2014 05:15 (GMT-05:00)
> To: Log4J Developers List
> Subject: Re: [proposal] import guidelines
>
>
How do you tell your IDE formatter to only use static import stars in some
source files and not others?
Gary
Original message From: Remko Popma
Date:05/17/2014 05:15 (GMT-05:00)
To: Log4J Developers List
Subject: Re: [proposal] import guidelines
Regarding static imports
ly. 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 o
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 muc
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] i
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". Wh
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".
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
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 .
44 matches
Mail list logo
