[
https://issues.apache.org/jira/browse/LUCENE-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-7788:
-----------------------------------
Attachment: gradle_only.patch
Status: Open (was: Open)
I'm in a bit of an awkward spot, my fork has a ton of changes unrelated to just
incorporating Gradle. So I'm attaching a separate patch that only contains the
gradle bits in the hope that [~dweiss] (or anyone more gradle-knowledgable
than me) will take a peek at it. If it's OK (or at least a good place to
start), I'll fold it into my fork for the next commit. Which will be Real Soon
Now, like Friday.
Please don't bother with how the check actually works, all I'm really asking
for is whether this looks like something that doesn't violate Gradle norms too
violently.
NOTE: Checking file paths rather than projects for inclusion/exclusion is
temporary, going by project at this point is too big a chunk. I'll change it to
be project-based before I'm done.
> fail precommit on unparameterised log messages and examine for wasted
> work/objects
> ----------------------------------------------------------------------------------
>
> Key: LUCENE-7788
> URL: https://issues.apache.org/jira/browse/LUCENE-7788
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Christine Poerschke
> Assignee: Erick Erickson
> Priority: Minor
> Attachments: LUCENE-7788.patch, LUCENE-7788.patch, gradle_only.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> SOLR-10415 would be removing existing unparameterised log.trace messages use
> and once that is in place then this ticket's one-line change would be for
> 'ant precommit' to reject any future unparameterised log.trace message use.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
