Are there any Eclipse settings that I can just import that match all the
various code formatting rules that we have for this project? If not, would
there be value in creating these settings so we can share them?
I've really grown attached to having Eclipse just auto-format my code when
I save and I've been trying to not have Eclipse format this log4j code.
Every once in a while I forget, and then I have to undo all the auto
formatting that just happened. That can be a little bit of a pain if I
don't notice right away. I don't know why, but my fingers have a mind of
their own: they keep hitting Ctrl+Shift+F and Ctrl+Shift+O.
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
>>
>>
>>
>
--
Bruce Brouwer
about.me/bruce.brouwer
[image: Bruce Brouwer on about.me]
<http://about.me/bruce.brouwer>
