[jira] [Updated] (LUCENE-9411) Fail complation on warnings, 9x gradle-only

["Erick Erickson (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCENE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erick Erickson updated LUCENE-9411:
-----------------------------------
    Attachment: LUCENE-9411-explicit-warnings.patch
        Status: Reopened  (was: Reopened)

Uwe:

Well, maybe I did understand your suggestion but didn't explain myself clearly ;). Your solution works, and is easy to implement. However, it leaves open the possibility that the new compiler warnings in version X will generate hundreds to thousands of new compiler warnings. How likely that is IDK. I just hope there's not a new warning in version X that's as bad as "rawtypes".

Unfortunately, I don't see any way around that, we'll have to go with listing them explicitly since it's certainly not acceptable to break Jenkins builds for Java 11+ for this. We get a lot of benefit, much of that benefit because of your work to stop using the latest Java for this issue...

8,000 warnings in Solr later I have some evidence if we don't start breaking locally, people won't fix these by checking Jenkins. Lucene was a lot cleaner, still about 100 warnings. 

Mostly I'm whining because it was a boatload of work to clean up the crap we'd accumulated and I doubt I'll be willing to do anything of a similar magnitude when we upgrade to the next version. But that's not the immediate problem.

I think the attached patch is what you're looking for? I'll run check and push it in a bit.

> Fail complation on warnings, 9x gradle-only
> -------------------------------------------
>
>                 Key: LUCENE-9411
>                 URL: https://issues.apache.org/jira/browse/LUCENE-9411
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: general/build
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>            Priority: Major
>              Labels: build
>             Fix For: master (9.0)
>
>         Attachments: LUCENE-9411-explicit-warnings.patch, LUCENE-9411.patch, LUCENE-9411.patch, LUCENE-9411.patch, LUCENE-9411.patch, annotations-warnings.patch
>
>
> Moving this over here from SOLR-11973 since it's part of the build system and affects Lucene as well as Solr. You might want to see the discussion there.
> We have a clean compile for both Solr and Lucene, no rawtypes, unchecked, try, etc. warnings. There are some peculiar warnings (things like SuppressFBWarnings, i.e. FindBugs) that I'm not sure about at all, but let's assume those are not a problem. Now I'd like to start failing the compilation if people write new code that generates warnings.
> From what I can tell, just adding the flag is easy in both the Gradle and Ant builds. I still have to prove out that adding -Werrors does what I expect, i.e. succeeds now and fails when I introduce warnings.
> But let's assume that works. Are there objections to this idea generally? I hope to have some data by next Monday.
> FWIW, the Lucene code base had far fewer issues than Solr, but common-build.xml is in Lucene.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org