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. > > > > > >
