I added some instructions on how to help out here: https://issues.apache.org/jira/browse/LUCENE-9570
spotless.gradle has a long list of projects that need to be reviewed. You can pick a small one and take it from there. Dawid On Wed, Dec 23, 2020 at 8:07 AM Dawid Weiss <[email protected]> wrote: > > It is currently limited to a subset of the code - reformatted the code > that's already formatted, so a no-ip. See exclusions in > spotless.gradle. You need to add the module there and then perhaps > limit to a single package so that the diff is not too overwhelming. > > > On Tue, Dec 22, 2020 at 11:58 PM David Smiley <[email protected]> wrote: > > > > I tried to use this on master for a particular module lucene/spatial-extras > > to see what happens. I ran "gw tidy" and it ran the tasks but did nothing > > discernable. Any clues what to do? > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > > > On Tue, Dec 22, 2020 at 1:58 PM Dawid Weiss <[email protected]> wrote: > >> > >> Yeah - those single-line comments that were broken are mostly because > >> they were just too long to fit in a single line. Other blocks (with > >> shorter single-line > >> comments) were just fine. > >> > >> I've seen a couple other oddities resulting from //-type comments > >> inside statements > >> or right after variable declarations. These are wrapped in an > >> unintuitive way too. > >> I moved a few (so that they appeared before the variable) but > >> otherwise didn't want > >> to change too much. Like I said - these things can be corrected/ moved > >> later on (and reformatted). > >> > >> > it's not always easy to coordinate sweeping changes while others > >> > continue to mess around! > >> > >> True. That's why I wanted to have it done fairly quickly so that we > >> can just move on. I'll finish > >> one or two modules myself to get the corner cases right and then I'll > >> probably ask for help. > >> Viewing the diff a package-at-a-time takes fairly little effort (5-10 > >> minutes) and it'd help enormously > >> if we could somehow parallelise this effort over multiple people. I'll > >> let you all know when I think > >> it's ready; a day or two should be enough for me. > >> > >> Dawid > >> > >> On Tue, Dec 22, 2020 at 7:12 PM Michael Sokolov <[email protected]> wrote: > >> > > >> > Yes, that is what I saw; line breaking choices that are different than > >> > what I would manually have chosen. I don't mean to sound negative - > >> > this is a nice improvement that gets us away from having to fuss about > >> > indentation and other formatting. Even regarding these line breaks, it > >> > is sensible to have the control to insist that single-line comments > >> > are not merged where block comments are merged and reflowed, so we'll > >> > learn to adapt to its rules and get things looking the way we want. > >> > Thanks, Dawid for pushing ahead with this, it's not always easy to > >> > coordinate sweeping changes while others continue to mess around! > >> > > >> > -Mike > >> > > >> > On Tue, Dec 22, 2020 at 12:49 PM Dawid Weiss <[email protected]> > >> > wrote: > >> > > > >> > > > I see it there - yes, it makes some occasional widows, and sometimes > >> > > > fails to join up consecutive single-line comments (I think you > >> > > > mentioned this elsewhere) but I can live with it :) > >> > > > >> > > I review those diffs manually (for now at least). Some things are > >> > > indeed > >> > > more verbose but I think they can be lived with (or corrected manually > >> > > at a later time). > >> > > > >> > > Single-line comments leave (typographical) widows when a long > >> > > single-line comment is broken because it exceeds line length. > >> > > To me the formatter intentionally doesn't treat consecutive > >> > > single-line comments as a block; it breaks long single-lines but > >> > > doesn't reflow them. So: > >> > > > >> > > // really really long comment on a single line > >> > > // that looks like this > >> > > > >> > > could be broken into: > >> > > > >> > > // really really long comment on a single > >> > > // line > >> > > // that looks like this > >> > > > >> > > I've seen examples when a reflow would actually corrupt the content of > >> > > the message so I guess no solution is ideal. If it's a block comment > >> > > then it should be a /* */ - then (again, I think) the content > >> > > undergoes a reflow. > >> > > > >> > > All this said, I think overall it's doing a great job, especially with > >> > > inconsistencies around operators, indents, javadoc etc. Sometimes it > >> > > tends to be verbose with method calls that have an insane number of > >> > > parameters (lining up over multiple lines). I've grown used to it - > >> > > it's really something you just live with after a while. And when it's > >> > > particularly bothersome, I just reformat the code somehow to have > >> > > fewer arguments, break long arithmetics into smaller local variables, > >> > > etc. This can be done gradually at a later time. > >> > > > >> > > So far I am pretty happy with what I've seen in those diffs though. > >> > > > >> > > Dawid > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
