I found some spotless warn, so I repaired them by running "mvn spotless:apply".
Then I executed "mvn spotless:check" locally, and the build succeeded, but there were still spotless warn after submitting PR https://github.com/apache/hbase/pull/4417. I just found this discussion, so before the end of the discussion, can we not focus on spotless warn? Thanks, Tao Li Peter Somogyi <[email protected]> 于2022年5月10日周二 23:57写道： > I noticed that the spotless license formatting removed some of the license > extensions where the origin of the code was mentioned, credited. > One example is AbstractByteRange [1] which is from Protobuf. > > Are we fine with these removals? > Can someone comment on this who is more familiar with licensing guidelines? > > [1] > > https://github.com/apache/hbase/commit/9c8c9e7fbf8005ea89fa9b13d6d063b9f0240443#diff-f5806f14849a23b9265b022f3f330b80d08bcc10fcf69d8ee2e1b0d5af266d52 > > Thanks, > PEter > > On Mon, May 2, 2022 at 4:32 PM Nick Dimiduk <[email protected]> wrote: > > > Ah! Pay heed to the version of the spotless plugin. There was a version > > upgrade between what was in the pom file on my feature branch vs. on the > > target branch. > > > > On Mon, May 2, 2022 at 4:21 PM Nick Dimiduk <[email protected]> wrote: > > > > > Now that spotless has landed, here's something to help you get your > > > outstanding PRs over the hump. It's not perfect, but maybe it'll help > > you. > > > > > > First, get the latest upstream changes and apply the latest spotless > > > configuration to your working branch, > > > > > > $ git fetch origin $targetbranch > > > $ git checkout $featurebranch > > > $ git checkout origin/$targetbranch -- > > > dev-support/hbase_eclipse_formatter.xml dev-support/eclipse.importorder > > > dev-support/license-header > > > > > > After that, find the parent commit of your changes and drop that value > > > into the ratchedFrom field of pom.xml, > > > > > > $ git rev-parse $featurebranch^ > > > > > > Then you can spotless:apply , selectively ammend your commit with the > > > results (be sure to omit the files you altered in staging the spotless > > > env), and then rebase. This assumes you have only a single commit on > your > > > $featurebranch. if you have more changes, you need the parent of your > > first > > > changes on the branch. > > > > > > But I may be missing something. the above isn’t perfect, especially > with > > > javadocs in the likes of HBaseTestingUtility.java that I didn’t touch > in > > my > > > original feature branch. My version of spotless appears to disagree > with > > > the committed changes, I see conflicts like: > > > > > > <<<<<<< HEAD > > > * @return A Table instance for the created table. n > > > ======= > > > * @return A Table instance for the created table. > > > * @throws IOException > > > >>>>>>> 811cfba133 (HBASE-26648 Improve fidelity of RegionLocator > spans) > > > > > > and > > > > > > <<<<<<< HEAD > > > * nnnnn * @return A region on which you must call > > > * {@link HBaseTestingUtility#closeRegionAndWAL(HRegion)} when done. > n > > > ======= > > > * @param tableName > > > * @param startKey > > > * @param stopKey > > > * @param isReadOnly > > > * @param families > > > * @return A region on which you must call {@link > > > HBaseTestingUtility#closeRegionAndWAL(HRegion)} > > > * when done. > > > * @throws IOException > > > >>>>>>> 811cfba133 (HBASE-26648 Improve fidelity of RegionLocator > spans) > > > > > > Good luck, > > > Nick > > > > > > On 2022/03/15 13:17:32 "张铎(Duo Zhang)" wrote: > > > > I've filed HBASE-26617 a while ago and recently I implemented a PR > for > > > > master branch. > > > > > > > > https://github.com/apache/hbase/pull/4214 > > > > > > > > The PR is a bit large because it will also format the pom, the actual > > > > changes are here > > > > > > > > > > > > > > https://github.com/apache/hbase/pull/4214/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R2673 > > > > > > > > In the PR I make use of the eclipse formatter and import order file > to > > > > format our java file. For pom, I just use most of the default > > formatter, > > > > the only exception is to expand empty element. > > > > > > > > The spotless plugin support setting a ratchetFrom option, which could > > be > > > a > > > > commit or a tag. Only files changed after this commit will be > > formatted, > > > so > > > > we can avoid generating a very big patch when running spotless:apply. > > > > > > > > So after we get this in, before submitting a PR, you can just type > mvn > > > > spotless:apply, then most of the checkstyle issues will be solved > > > > automatically. And we could also add a spotless:check step in our pre > > > > commit job, to make sure we run spotless:apply before submitting a > PR. > > > > > > > > Just tell me what you think about the above plan. Suggestions are > > always > > > > welcomed. > > > > > > > > Thanks. > > > > > > > > > >
