AFAIK, the ijar (for "interface jar") is a standard JAR, with standard *.class files *except* that the method bodies and private members have been stripped out (and timestamps are normalized too). That way, if you change a method implementation, or a private member (add/remove private field or method, change private method signature, add/remove private inner class), the resulting ijar won't change. Any *.java compiled against such a *.class would produce the exact same *.class, so by checking the ijar checksum you can determine whether a dependency has changed in a way that would require recompiling the code. You'd however use the "normal" jar checksum to determine whether to re-run tests (Maven unconditionally re-runs tests, but neither Bazel nor Gradle, they avoid re-running them if the inputs haven't changed), as implementation matters in determining the outcome (whether the tests pass or fail).
On Wed, Oct 4, 2017 at 4:27 PM Russell Gold <russell.g...@oracle.com> wrote: > Does this iJar have more information than a regular JAR? If not, what is > the benefit? If so, where is this information coming from? > > The closest thing I can think of is the new Java 9 module system, which > defines what is visible; presumably, that information would be useful in > such a determination. > > > On Oct 4, 2017, at 12:38 AM, Farid Zakaria <farid.m.zaka...@gmail.com> > wrote: > > > > I was combing through Bazel <https://bazel.build> (google's build tool) > and > > found a concept called iJar > > <https://github.com/bazelbuild/bazel/tree/master/third_party/ijar> > > iJar is basically a stripped out version of the Jar removing everything > but > > the public method signatures (very stripped out byte code jar). > > > > Their build tool uses iJars in determining if upstream dependencies can > be > > skipped to be rebuilt. The idea being: if the interface (iJar) of the > > current project hasn't changed (SHA), there's no need to rebuild upstream > > dependencies since any possible method they'd have used did not change. > > > > My guess is this would be a good way to speed up "-amd" > > (also-make-dependents) by quickly stopping the build based on the iJar. > > > > Could this be done as a maven extension? > > > > Farid Zakaria > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >