And here I was hoping to make Uwe stay up for *days* without sleep finding all the gotchas <G>.
Thanks for the response. I'll see if I can update my IntelliJ codestyle appropriately, but probably won't get there 'til this weekend. I'll upload it to the Wiki or attach it to a Jira if nobody beats me to it. Erick On Tue, Nov 10, 2009 at 7:37 PM, Robert Muir <rcm...@gmail.com> wrote: > this was the similar to the discussion we had at apachecon, where i wanted > to create a jira issue as Uwe Schindler<some invisible unicode space> and > suggest a patch to reformat all of contrib! > > (would never attribute such a thing to my name but this formatting issue > consistently gets in my way) > > > On Tue, Nov 10, 2009 at 7:29 PM, Uwe Schindler <u...@thetaphi.de> wrote: > >> Yes this one is new, but it is almost the default Java 1.5 style with >> tabs=2chars and the modified generics formatting. >> >> >> >> I know about the reformatting method in Eclipse, but that would break more >> patches now L (a lot of are already broken). >> >> ----- >> Uwe Schindler >> H.-H.-Meier-Allee 63, D-28213 Bremen >> http://www.thetaphi.de >> eMail: u...@thetaphi.de >> ------------------------------ >> >> *From:* Erick Erickson [mailto:erickerick...@gmail.com] >> *Sent:* Wednesday, November 11, 2009 1:27 AM >> *To:* java-dev@lucene.apache.org >> *Subject:* Re: [jira] Commented: (LUCENE-1257) Port to Java5 >> >> >> >> About formatting. I know the "how to contribute" section of the Wiki warns >> against gratuitous reformatting, but if *someone* with commit privileges >> wanted to, they could format an entire tree in Eclipse from the context >> menu of, say, the contrib directory. It'd have to be coordinated for a >> moment when not too many others were editing the code... >> >> I mention this since we're doing a bunch of non-functional changes for the >> 3.0 release, and it might be a reasonable thing to do so future commits were >> easier to compare, at least after the reformatting was done. As long as >> we're all using the same formatting, it might be worthwhile. >> >> Somebody mentioned uploading a new codestyle.xml for Eclipse. Were there >> any changes or is this just getting the one from SOLR up there? Because I'm >> using IntelliJ.... >> >> Erick >> >> On Tue, Nov 10, 2009 at 7:08 PM, Uwe Schindler (JIRA) <j...@apache.org> >> wrote: >> >> >> [ >> https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776184#action_12776184] >> >> >> Uwe Schindler commented on LUCENE-1257: >> --------------------------------------- >> >> Kay Kay: We only have SuppressWarnings at some places in core, marked with >> a big TODO (will be done when flex indeixng comes). The "wanted" >> @SuppressWarnings are only at places, where generic Arrays are created. >> There is no way to fix this (see Sun Generics Howto). >> >> >> > Port to Java5 >> > ------------- >> > >> > Key: LUCENE-1257 >> > URL: https://issues.apache.org/jira/browse/LUCENE-1257 >> > Project: Lucene - Java >> > Issue Type: Improvement >> > Components: Analysis, Examples, Index, Other, Query/Scoring, >> QueryParser, Search, Store, Term Vectors >> > Affects Versions: 3.0 >> > Reporter: Cédric Champeau >> > Assignee: Uwe Schindler >> > Priority: Minor >> > Fix For: 3.0 >> > >> > Attachments: instantiated_fieldable.patch, >> LUCENE-1257-BooleanQuery.patch, LUCENE-1257-BooleanScorer_2.patch, >> LUCENE-1257-BufferedDeletes_DocumentsWriter.patch, >> LUCENE-1257-CheckIndex.patch, LUCENE-1257-CloseableThreadLocal.patch, >> LUCENE-1257-CompoundFileReaderWriter.patch, >> LUCENE-1257-ConcurrentMergeScheduler.patch, >> LUCENE-1257-DirectoryReader.patch, >> LUCENE-1257-DisjunctionMaxQuery-more_type_safety.patch, >> LUCENE-1257-DocFieldProcessorPerThread.patch, LUCENE-1257-Document.patch, >> LUCENE-1257-FieldCacheImpl.patch, LUCENE-1257-FieldCacheRangeFilter.patch, >> LUCENE-1257-IndexDeleter.patch, >> LUCENE-1257-IndexDeletionPolicy_IndexFileDeleter.patch, >> LUCENE-1257-iw.patch, LUCENE-1257-MTQWF.patch, >> LUCENE-1257-NormalizeCharMap.patch, LUCENE-1257-o.a.l.util.patch, >> LUCENE-1257-org_apache_lucene_document.patch, >> LUCENE-1257-org_apache_lucene_document.patch, >> LUCENE-1257-org_apache_lucene_document.patch, >> LUCENE-1257-SegmentInfos.patch, LUCENE-1257-StringBuffer.patch, >> LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, >> LUCENE-1257-TopDocsCollector.patch, LUCENE-1257-WordListLoader.patch, >> LUCENE-1257_analysis.patch, LUCENE-1257_BooleanFilter_Generics.patch, >> LUCENE-1257_contrib_benchmark.patch, LUCENE-1257_contrib_benchmark_2.patch, >> LUCENE-1257_contrib_highlighting.patch, LUCENE-1257_contrib_memory.patch, >> LUCENE-1257_contrib_misc.patch, LUCENE-1257_contrib_smartcn.patch, >> LUCENE-1257_javacc_upgrade.patch, LUCENE-1257_lucil.patch, >> LUCENE-1257_lucli.patch, LUCENE-1257_messages.patch, >> LUCENE-1257_more_unnecessary_casts.patch, >> LUCENE-1257_MultiFieldQueryParser.patch, >> LUCENE-1257_o.a.l.queryParser.patch, LUCENE-1257_o.a.l.store.patch, >> LUCENE-1257_o_a_l_demo.patch, LUCENE-1257_o_a_l_index_test.patch, >> LUCENE-1257_o_a_l_index_test.patch, LUCENE-1257_o_a_l_search.patch, >> LUCENE-1257_o_a_l_search_spans.patch, >> LUCENE-1257_org_apache_lucene_index.patch, >> LUCENE-1257_org_apache_lucene_index.patch, >> LUCENE-1257_precendence_parser.patch, LUCENE-1257_queryParser_jj.patch, >> LUCENE-1257_swing_wikipedia_wordnet_xmlqp.patch, >> LUCENE-1257_unnecessary_casts.patch, LUCENE-1257_unnnecessary_casts_2.patch, >> lucene1257surround1.patch, lucene1257surround1.patch, >> shinglematrixfilter_generified.patch >> > >> > >> > For my needs I've updated Lucene so that it uses Java 5 constructs. I >> know Java 5 migration had been planned for 2.1 someday in the past, but >> don't know when it is planned now. This patch against the trunk includes : >> > - most obvious generics usage (there are tons of usages of sets, ... >> Those which are commonly used have been generified) >> > - PriorityQueue generification >> > - replacement of indexed for loops with for each constructs >> > - removal of unnececessary unboxing >> > The code is to my opinion much more readable with those features (you >> actually *know* what is stored in collections reading the code, without the >> need to lookup for field definitions everytime) and it simplifies many >> algorithms. >> > Note that this patch also includes an interface for the Query class. >> This has been done for my company's needs for building custom Query classes >> which add some behaviour to the base Lucene queries. It prevents multiple >> unnnecessary casts. I know this introduction is not wanted by the team, but >> it really makes our developments easier to maintain. If you don't want to >> use this, replace all /Queriable/ calls with standard /Query/. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> >> >> > > > > -- > Robert Muir > rcm...@gmail.com >
