bq: You can provide a standard command line way to fix the formatting, or check it as a part of precommit so that we enforce it as new code comes in.
This wold be _sweet_! Especially if we could do this on a directory-by-directory basis, or even on a file-by-file basis (through the magic of Ant and/or scripting?). It would be much less discouraging to know that once something was cleaned up, it wouldn't backslide. we already have IDE styles files for several IDEs, so part of it would be a matter of making the astyle options match what's in the IDE and going from there. And to be clear, I'm also sympathetic to the "not mandate this". I'm also sympathetic to not having to re-hash this every couple of years. So maybe I shouldn't have brought it up ;) On Tue, Mar 10, 2015 at 1:54 PM, Ramkumar R. Aiyengar <[email protected]> wrote: > Without commenting on if we should do it (personally I am for it, but I am > also sympathetic to people who feel it's excessive to mandate it), if we are > going down this road, might be worth looking at standalone tools like astyle > which do this rather than an IDE. Some advantages: > > * You can easily codify the rules needed instead of coming up with a > configuration for each IDE we use. We could still provide that configuration > but there's at least a golden spec to go by than depending on IDEs as they > evolve. > > * You can provide a standard command line way to fix the formatting, or > check it as a part of precommit so that we enforce it as new code comes in. > > 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]
