HBASE-22997 Move to SLF4J; addendum

[petersomogyi]

Add MIT to LICENSE.txt

[asf-ci]

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/PreCommit-HBASE-OPERATOR-TOOLS-Build/96/

[busbey]

this should be in the LICENSE file for artifacts we generate that include a copy of slf4j. We don't have it in our source repository, so it should not be in this top level LICENSE.

[petersomogyi]

this should be in the LICENSE file for artifacts we generate that include a copy of slf4j. We don't have it in our source repository, so it should not be in this top level LICENSE.

Does it mean we need to add the MIT license when generating the tarball?

[busbey]

Yes, when we make a binary tarball that includes our dependencies we'll need to include it in that LICENSE.

Do we need to bundle slf4j though? won't it always be available from the hbase instance we're running against?

[petersomogyi]

Do we need to bundle slf4j though? won't it always be available from the hbase instance we're running against?

slf4j-api-1.7.25.jar (the one that we currently include in the hbck2 tarball) is available in the hbase releases. I just checked 2.2.1RC and these files are there:

$ find . -name *slf4j*
./lib/client-facing-thirdparty/slf4j-api-1.7.25.jar
./lib/client-facing-thirdparty/slf4j-log4j12-1.7.25.jar

Based on this I think we can just exclude the slf4j-api when generating the tar.gz file.

[busbey]

👍 I love shipping fewer bits 😸

I assume it'll be there for whatever HBase versions we want to use operator-tools with. The location might change, but since we're always run via the hbase command we should get a classpath that includes it.

[petersomogyi]

Based on the above I'm closing this pull request. The exclusion should happen when we introduce the assembly module.