Yeah, I agree - if we go the full hog route, we should integrate it into our build.
- Mark On Tue, Mar 10, 2015 at 5:14 PM Erick Erickson <[email protected]> wrote: > 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] > >
