| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is introducing a few changes to use the Java compiler
from errorprone:
- add the --java_langtools flag to the shell tests so
we do the tests with the same java compiler tooling than
Bazel, and
- added the langtools the bootclasspath of the JavaBuilder
tests.
- tagged some tests and deactivated them on travis OSX
because they either requires Java 8 or a lot of disk
space.
To do the same change on a local install, one must:
- change the source and target versions to 7 in the
tools/jdk:toolchain target,
- use the .travis/jdk7.WORKSPACE file instead of the
default Bazel workspace (it contains a maven_jar
refering to the errorprone's java compiler tools), and
- set the JAVA_VERSION environent variable to "1.7".
The .travis/build.sh script does just that when under OS X.
--
Change-Id: Idb466cf47cf7df35a34fb0dd8d186628aae0cba7
Reviewed-on: https://bazel-review.googlesource.com/#/c/1520/
MOS_MIGRATED_REVID=96011123
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It extracts Zip/Unzip methods of ijar in a separate
library. A zipper binary is provided to test that
implementation outside. Note that this implementation
does not compute CRC-32 and unzip will complain on
file zipped with it (but Java won't complain).
The error handling has been replaced to use proper error
reporting instead of launching abort()'s allover the place
so ijar's zip library can be used outside of ijar.
Finally, support for ZIP preamble has been added to
handle self-extractable ZIP files.
--
Change-Id: I833034b4c0054925bada75102fe040db875da789
Reviewed-on: https://bazel-review.googlesource.com/#/c/1371/
MOS_MIGRATED_REVID=94656262
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ijar tests were a bit bloated so using our shell test framework
to separate those tests into individual function and enable sharding.
The ijar tests are still ~70s on a macbook with a SSD drive (compared
to ~140s before).
Those 70s are spent in tests that write big files and test ijar
behavior with those big files. In those tests, disk IOs dominate
time. Timing the various operation gave that jaring the 2.2Gb large
file takes ~17s each time (operation we do twice). Simply creating
that file takes approximatively 10s. Reducing the number of
operations in that test would reduce significantly its duration.
Unfortunately, that would reduce the coverage of the test.
--
Change-Id: Idc817ab32b78b69bde8dd95ddedbcf6b9f12ee3f
MOS_MIGRATED_REVID=92723971
|
|
--
MOS_MIGRATED_REVID=88210083
|