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
