Ben Liblit

This is closely related to issue #236, or might even be the same thing.

When I first split these dependencies into `api` versus `implementation`, I took a minimalist approach: `implementation` everywhere possible, `api` only where required. My reasoning was that under-exposure of transitive dependencies...

My guess is that this code was implemented with Java’s covariant array subtyping relation in mind: https://docs.oracle.com/javase/specs/jls/se12/html/jls-4.html#jls-4.10.3. But subtyping is not the same thing as subclassing, as the language specification...

Agreed. Perhaps obsolete, but certainly out-of-date.

I double checked, and unfortunately `hyperref.sty 2016/05/21 v6.83p` really is what Fedora 28 is shipping. This is not some leftover old version I was accidentally picking up from elsewhere on...

Apparently there is *already* a [bug report requesting that Fedora ship a newer `hyperref`](https://bugzilla.redhat.com/show_bug.cgi?id=1436737). The problem described in that bug report might even be the same problem we are grappling...

Confirmed. Current `acmart` from GitHub fails with `hyperref 2016/05/21 v6.83p` as shipped by Fedora 28, but succeeds with newer `hyperref 2018/02/06 v6.86b` [downloaded from CTAN](https://ctan.org/tex-archive/macros/latex/contrib/hyperref). Interestingly, the older `acmart 2016/05/30...

See also projectlombok/lombok#3097, which finds the same problem using direct `javac` compilation: no IDE, no plugin, just the Java compiler.

No other WALA jar files include their dependencies. Is there some reason that this one must? If yes, then should this jar include _all_ transitive dependencies, or only the subset...

This behavior is probably not an `XMLResolver` bug _per se_: if the `SchemaFactory` chooses not to call the resolver, that’s not something the resolver caused or can correct. That being...