Beware , I have seen intellij reformatting screwing up javadocs and failing the "ant precommit"
On Tue, Mar 10, 2015 at 11:59 PM, Erick Erickson <[email protected]> wrote: > bq: I honestly don't know how I feel about such a 'complete' approach > > Well, join the club ;). Borrowing from Martin Fowler's "refactoring" > book, it's often an anti-pattern to muck with code that you're not > working on. OTOH, this is a "broken window" problem, the more bad > formatting that creeps in the more likely people will pattern their > own code after it. > > Frankly, the only time I've ever seen absolutely uniform formatting is > in cases where it's part of the checkin process and not voluntary at > all. > > But we can take a whack at resetting the bar. > > On Tue, Mar 10, 2015 at 10:50 AM, Mark Miller <[email protected]> > wrote: > > I honestly don't know how I feel about such a 'complete' approach, but I > > will say we have made such sweeping patch breaking changes before. > > > > - Mark > > > > On Tue, Mar 10, 2015 at 1:44 PM Erick Erickson <[email protected]> > > wrote: > >> > >> Let's re-open the "let's reformat the entire code base" topic again. > >> Actually, I'd be happy to volunteer to do this if > >> > >> 1> we reached consensus on whether or not it's a good thing. > >> 2> we reached consensus on what to reformat. For instance, I can > >> convince IntelliJ to reformat any directory of files. So it'd be > >> possible to reformat, say, just the Solr code. Or just the cloud > >> sub-folder. Or..... > >> 3> we reached consensus on when to do any part of this. The last thing > >> I'd want to do is screw up someones large complex branch under > >> development, but we could approach this piecemeal. Say open a JIRA > >> "Reformat the solr/core/src/test directory", give people a chance to > >> object before doing it, etc. > >> 4> I'd be happy to do the process in the Lucene code base too, but > >> since I'm personally rarely in that code I'd just as happily leave > >> that out of the discussion, up to the guys who _are_ in that code IMO. > >> > >> FWIW, > >> Erick > >> > >> On Mon, Mar 9, 2015 at 9:50 AM, Mike Drob <[email protected]> wrote: > >> > For Eclipse you can get it but only automatically on a save. > Preferences > >> > > > >> > Java > Editor > Save Actions. > >> > If you don't like the changes that it makes, I've found that you can > >> > undo > >> > and save again, and it won't re-format. > >> > > >> > On Mon, Mar 9, 2015 at 11:38 AM, Mark Miller <[email protected]> > >> > wrote: > >> >> > >> >> Interesting - never seen such a thing with Eclipse - anyone else? > >> >> > >> >> I just select the new block of code and shift + control + F. Not bad, > >> >> but > >> >> would love to have that option as well. > >> >> > >> >> I usually avoid fixing extra formatting in my patches, but for some > of > >> >> the super violations (someone just uses a complete different idea of > >> >> code > >> >> formatting) I'd rather it be fixed than worry about diffs. This type > of > >> >> thing proliferates and lately it feels like it's been going down > hill. > >> >> > >> >> - Mark > >> >> > >> >> On Mon, Mar 9, 2015 at 10:00 AM Erick Erickson > >> >> <[email protected]> > >> >> wrote: > >> >>> > >> >>> Ishan: > >> >>> > >> >>> Don't know which IDE you use, but IntelliJ has an "only vcs changed > >> >>> code" or some such when reformatting that I find _very_ useful. > It's a > >> >>> bit dangerous because the _last_ thing you want to do is reformat > >> >>> entire files, makes it really hard to look at diffs but I find the > >> >>> ability to reformat just what's changed great!. > >> >>> > >> >>> Best, > >> >>> Erick > >> >>> > >> >>> On Mon, Mar 9, 2015 at 12:41 AM, Ishan Chattopadhyaya (JIRA) > >> >>> <[email protected]> wrote: > >> >>> > > >> >>> > [ > >> >>> > > >> >>> > > https://issues.apache.org/jira/browse/SOLR-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14352639#comment-14352639 > >> >>> > ] > >> >>> > > >> >>> > Ishan Chattopadhyaya edited comment on SOLR-6673 at 3/9/15 7:40 > AM: > >> >>> > > -------------------------------------------------------------------- > >> >>> > > >> >>> > Apologies for the inconsistent formatting; I'll keep this in mind > >> >>> > :-) > >> >>> > Thanks for calling it out! > >> >>> > > >> >>> > Updated the patch with changes going to SolrLogLayout, adding the > >> >>> > MDC > >> >>> > values in this format: > >> >>> > > >> >>> > [core] [collection] [shard] [replica] > >> >>> > > >> >>> > > >> >>> > > >> >>> > was (Author: ichattopadhyaya): > >> >>> > Apologies for the inconsistent formatting; I'll keep this in mind > >> >>> > :-) > >> >>> > Thanks for calling it out! > >> >>> > > >> >>> > Updated the patch with changes going to SolrLogLayout, adding the > >> >>> > MDC > >> >>> > values in this format: > >> >>> > [%X{core}] [%X{collection}] [%X{shard}] [%X{replica}] > >> >>> > > >> >>> > > >> >>> >> MDC based logging of collection, shard etc. > >> >>> >> ------------------------------------------- > >> >>> >> > >> >>> >> Key: SOLR-6673 > >> >>> >> URL: > >> >>> >> https://issues.apache.org/jira/browse/SOLR-6673 > >> >>> >> Project: Solr > >> >>> >> Issue Type: Improvement > >> >>> >> Reporter: Ishan Chattopadhyaya > >> >>> >> Assignee: Noble Paul > >> >>> >> Labels: logging > >> >>> >> Attachments: SOLR-6673.patch, SOLR-6673.patch, > >> >>> >> SOLR-6673.patch, log4j.properties, log4j.properties > >> >>> >> > >> >>> >> > >> >>> >> In cloud mode, the many log items don't contain the collection > >> >>> >> name, > >> >>> >> shard name, core name etc. Debugging becomes specially difficult > >> >>> >> when many > >> >>> >> collections/shards are hosted on the same node. > >> >>> >> The proposed solution adds MDC based stamping of collection, > shard, > >> >>> >> core to the thread. > >> >>> >> See also: SOLR-5969, SOLR-5277 > >> >>> > > >> >>> > > >> >>> > > >> >>> > -- > >> >>> > This message was sent by Atlassian JIRA > >> >>> > (v6.3.4#6332) > >> >>> > > >> >>> > > >> >>> > > --------------------------------------------------------------------- > >> >>> > To unsubscribe, e-mail: [email protected] > >> >>> > For additional commands, e-mail: [email protected] > >> >>> > > >> >>> > >> >>> > --------------------------------------------------------------------- > >> >>> To unsubscribe, e-mail: [email protected] > >> >>> For additional commands, e-mail: [email protected] > >> >>> > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- ----------------------------------------------------- Noble Paul
