[
https://issues.apache.org/jira/browse/HBASE-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14285273#comment-14285273
]
Sean Busbey commented on HBASE-12808:
-------------------------------------
This is a great addition. Personally, I don't think adding ~6 minutes to
HadoopQA will break us and I'd rather catch compatibility problems early. If we
really needed to optimize, we could do a follow on to grab already built jars
from tags that look like release versions (or use the equivalent of git archive
to avoid a full clone).
A few things I'd like to see addressed before commit.
# I'm on a mac and I rely on homebrew to get real tooling. Homebrew won't put
gnu getopts on the path because Apple ships BSD getopts and it doesn't want to
muck with something that might break assumptions in extant parts of OSX. It'd
be great if the script allowed for an env variable to set the path to getopt,
so that I can easily specify gnu getopt for just this script.
# attempting to build an RC after running the compat checker will fail RAT
because of files that are in dev-support/compatibility.
{code}
dev-support/compatibility/annotations
dev-support/compatibility/javaACC/doc/Changes.html
dev-support/compatibility/javaACC/doc/Descriptor.html
dev-support/compatibility/javaACC/doc/Options.html
dev-support/compatibility/javaACC/doc/Readme.html
dev-support/compatibility/javaACC/japi-compliance-checker.pl
dev-support/compatibility/javaACC/Makefile.pl
dev-support/compatibility/report/0.99.2_branch-1.0_compat_report.html
{code}
We can solve this issue either with an exclusion in the rat plugin config, or
moving these things into a target/ subdirectory. I like the latter approach
because it matches expectations for things that will be ignored by both git and
rat.
# related to the above, the source tarball built from our RC instructions
includes everything under dev-support/compatibility, including the two
checkouts. It will also include the javaACC source if rat excludes the
compatibility directory. It looks like the assembly blindly includes everything
under dev-support rather than making use of the exclusion list that covers the
modules. This is a problem already in the code base, i.e. if you follow the
instructions under dev-support/jenkins-tools it will include target/ dirs
provided you've removed the jenkins-client module. So maybe it should be its
own ticket.
> Use Java API Compliance Checker for binary/source compatibility
> ---------------------------------------------------------------
>
> Key: HBASE-12808
> URL: https://issues.apache.org/jira/browse/HBASE-12808
> Project: HBase
> Issue Type: Improvement
> Components: test
> Reporter: Dima Spivak
> Assignee: Dima Spivak
> Attachments: HBASE-12808_v1.patch, HBASE-12808_v2.patch,
> HBASE-12808_v3.patch
>
>
> Following [~busbey]'s suggestion in HBASE-12556, I've spent some time playing
> with the [Java API Compliance
> Checker|http://ispras.linuxbase.org/index.php/Java_API_Compliance_Checker]
> and think it would be a great addition to /dev-support. I propose that we use
> it to replace the JDiff wrappers we currently have there (since it does what
> JDiff does and more), and look into putting up automation at
> builds.apache.org to run the tool regularly (e.g. latest release of a
> particular branch vs. latest commit of that same branch).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
