hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Busbey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12808) Use Java API Compliance Checker for binary/source compatibility
Date Wed, 21 Jan 2015 07:11:35 GMT

    [ 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)

Mime
View raw message