I think we used to have instruction lying around that described how to
use https://github.com/lvc/japi-compliance-checker (not like that has
any influence on what Sean used, though :D)
Corey Nolet wrote:
Sean- is this what you were using [1]?
[1] https://java.net/projects/jascc
On Thu, Jan 22, 2015 at 2:25 PM, Christopher<[email protected]> wrote:
Various ITs timed out. I'll have to re-run on a more reliable machine.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Jan 21, 2015 at 7:50 PM, Corey Nolet<[email protected]> wrote:
I did notice something strange reviewing this RC. It appears the
staging
repo doesn't have hash files for the detached GPG signatures
(*.asc.md5,
*.asc.sha1). That's new. Did you do something special regarding this,
Corey? Or maybe this is just a change with mvn, or maybe it's a change
with
the staging repo? It's not an issue... the GPG signature doesn't need
to
also be hashed... it's just different and unexpected.
I did update maven to the newest version. Other than that, I haven't done
anything different int he release process.
I could not complete a full build, because I had IT test timeouts with
timeout.factor=2.
Which IT tests were timing out for you?
On Jan 21, 2015 6:22 PM, "Christopher"<[email protected]> wrote:
I did notice something strange reviewing this RC. It appears the
staging
repo doesn't have hash files for the detached GPG signatures
(*.asc.md5,
*.asc.sha1). That's new. Did you do something special regarding this,
Corey? Or maybe this is just a change with mvn, or maybe it's a change
with
the staging repo? It's not an issue... the GPG signature doesn't need
to
also be hashed... it's just different and unexpected.
Other checks I ran:
GPG signatures on all the artifact files were good, so were the md5 and
sha1 hashes.
Every jar artifact has a corresponding source/javadoc jar.
The git commit matches that specified in the META-INF/MANIFEST.MF for
each
jar
The lib directory contains the same jars as those signed/hashed.
The branch matches the tag matches the source tarball contents.
I could not complete a full build, because I had IT test timeouts with
timeout.factor=2.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Jan 21, 2015 at 6:03 PM, Keith Turner<[email protected]>
wrote:
I also ran the compliance checker tool. The only other changes were
in
o.a.a.core.data.KeyValue. But that class is not listed as part of
public
API. The changes showed up in the report because the class was in
data
package.
On Wed, Jan 21, 2015 at 6:01 PM, Christopher<[email protected]>
wrote:
On Wed, Jan 21, 2015 at 11:05 AM, Sean Busbey<[email protected]
wrote:
On Wed, Jan 21, 2015 at 6:57 AM,<[email protected]> wrote:
I concur. This change makes the version of this release 1.7.0.
We
either
need to change the version or remove the method. Good catch.
Out
of
curiosity, did you find this by visual inspection or with a
tool?
While I have many eyes, they don't generally get spent on
comprehensive
code reviews. ;)
I used the Java API Compatibility Checker.
Was that the only violation?
(Also, -1 for the same reason.)
