[
https://issues.apache.org/jira/browse/LUCENE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839202#action_12839202
]
Shai Erera commented on LUCENE-2285:
------------------------------------
Ok I see the problem now - because there are so many files, I didn't see while
applying the patch, that there are errors (mismatch) on some files, therefore
the patch wasn't applied to them, hence the compile errors. I apply the patch
w/ eclipse. The problematic files are tests in the analyzers package, and I
suspect it's an encoding issue. My source encoding is UTF-8, yet still when I
apply the patch I see different characters on the source and patch file. Not
sure where the problem is. The patch file which I downloaded is UTF-8 as well,
and TestArabicAnalyzer (for example) contains the correct characters in Arabic
(in both the patch file and my checkout copy). Yet still when I apply the patch
eclipse doesn't read it as UTF-8 ...
Uwe, how about if we do this issue in multiple commits? I.e., commit what
you've done so far (which is what we agree on), then I can update, review the
remaining warnings and we continue from there? Anyway after you commit this
there will be warnings, and over time more warnings will creep in, so we'll
need to do some cleanup again :). Is that acceptable?
> Code cleanup from all sorts of (trivial) warnings
> -------------------------------------------------
>
> Key: LUCENE-2285
> URL: https://issues.apache.org/jira/browse/LUCENE-2285
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Shai Erera
> Assignee: Uwe Schindler
> Priority: Minor
> Fix For: 3.1
>
> Attachments: LUCENE-2285.patch, LUCENE-2285.patch, LUCENE-2285.patch
>
>
> I would like to do some code cleanup and remove all sorts of trivial
> warnings, like unnecessary casts, problems w/ javadocs, unused variables,
> redundant null checks, unnecessary semicolon etc. These are all very trivial
> and should not pose any problem.
> I'll create another issue for getting rid of deprecated code usage, like
> LuceneTestCase and all sorts of deprecated constructors. That's also trivial
> because it only affects Lucene code, but it's a different type of change.
> Another issue I'd like to create is about introducing more generics in the
> code, where it's missing today - not changing existing API. There are many
> places in the code like that.
> So, with you permission, I'll start with the trivial ones first, and then
> move on to the others.
--
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
