[
https://issues.apache.org/jira/browse/SOLR-14920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17497771#comment-17497771
]
Erick Erickson commented on SOLR-14920:
---------------------------------------
How brave do you want to be? Has anyone found anything that's totally
objectionable or incorrect yet? If we haven't, and we have some faith that
executing enough tasks will eventually flush out all the gotchas (see a few
below) then why go slow?
Another way to phrase it is whether anyone's seen spotless do something we
can't live with after we execute all the relevant tasks?
Just for yucks, I took a fresh pull of Solr, then removed the
targetExcludes from the spotless task except for hdfs. Then I ran
spotlessApply on it all. All tests pass with about 3,371 files changed. Is
there any real benefit in hand-checking each and every change when balanced
off against this effort dragging on?
We could just make the mass change and check it all in after we can build,
test, and run all the tasks that might be affected. I'd like to give folks
a heads up and maybe an opportunity to clean some things up first. The
beauty of this is that it's pretty trivial to actually do, it'd take about
a day, most of that running tests. Now that I've been down the path once,
it should be quick...
That would also allow a single commit that could be rolled back in the
worst case. Well, I guess four commits considering the three
.git-blame-ignore-revs.
I did find a few problems, all were easily fixable:
1. the file:
solr/core/src/test/org/apache/solr/response/transform/TestSubQueryTransformer.java
where spotless barfed, but that was due to the license text being repeated
part way through the imports. Once I deleted that (and left the one at the
top of the file of course), spotless worked fine.
2. there were a few places where the reformatting caused "empty <code>
block found" due to it putting a <code> block in the javadoc at the end of
a line and the remainder ("@Logger</code>") on the next line. I changed the
wording a bit to make that not break across the line.
3. there were some weirdly formed links in the javadocs, not a big deal
just had to move some double quotes around.
4. some comment splits made the validateLogCalls flag some
"questionable" items that really weren't, again easily fixed.
5. javadocs generated from LogListener.java has an extensive <code>
section that would _not_ make it through some of the doc checks since
somehow (not Spotless' fault) a </div> tag got inserted. I managed to get
around all that by using <pre> in place of the <code> tag.
6. These fixes are a bit hacky but they work...
So, now that I've been through the process once, I'll volunteer to make a
new fork of solr (apparently some things got moved around lately) and put
it up for perusal. In particular, anyone who knows enough about the
publishing process (docs, ref guide, etc) to give them a spin would be
helpful. Then we can discuss.....
Since I'm starting over, and since it's toward evening, I won't have that
up until tomorrow....
Thoughts?
> Format code automatically and enforce it in Solr
> ------------------------------------------------
>
> Key: SOLR-14920
> URL: https://issues.apache.org/jira/browse/SOLR-14920
> Project: Solr
> Issue Type: Improvement
> Reporter: Erick Erickson
> Priority: Major
> Labels: codestyle, formatting
> Time Spent: 8h
> Remaining Estimate: 0h
>
> See the discussion at: LUCENE-9564.
> This is a placeholder for the present, I'm reluctant to do this to the Solr
> code base until after:
> * we have some Solr-specific consensus
> * we have some clue what this means for the reference impl.
> Reconciling the reference impl will be difficult enough without a zillion
> format changes to add to the confusion.
> So my proposal is
> 1> do this.
> 2> Postpone this until after the reference impl is merged.
> 3> do this in one single commit for reasons like being able to conveniently
> have this separated out from git blame.
> Assigning to myself so it doesn't get lost, but anyone who wants to take it
> over please feel free.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
