aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/java/OneVersionCheckActionBuilder.java
Commit message (Collapse)AuthorAge
* Add a ruleError when one version enforcement is requested without the requisiteGravatar Googler2018-04-09
| | | | | | | | | one_version_whitelist attribution on the java_toolchain. Fixes bazelbuild/bazel#4682 RELNOTES: n/a PiperOrigin-RevId: 192181587
* @AutoCodec some more classes needed for large Java builds.Gravatar janakr2018-03-25
| | | | PiperOrigin-RevId: 190392567
* Move CommandLine, CommandLineItem, and ParamFileInfo from ↵Gravatar tomlu2018-02-15
| | | | | | | | | lib.analysis.actions -> lib.actions. These are fundamental types that want to sit alongside types like Spawn. RELNOTES: None PiperOrigin-RevId: 185887971
* Allow CustomCommandLine's mapFn to expand each object into multiple items.Gravatar tomlu2018-02-01
| | | | | | This is needed to migrate JavaCompileAction away from CustomMultiArgv. PiperOrigin-RevId: 184136486
* Adjust blaze to allow for integration of one-version checking inside Google. ↵Gravatar Googler2017-11-10
| | | | | | | This feature is not yet available for Bazel users. RELNOTES: n/a PiperOrigin-RevId: 175226288
* Replace all usages of Blaze's Preconditions class with guava.Gravatar tomlu2017-11-09
| | | | | | | | Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own. This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually. PiperOrigin-RevId: 175033526
* Support multiple command lines / params files in SpawnAction.Gravatar tomlu2017-09-15
| | | | | | This is necessary for the upcoming Skylark implementation of param files. PiperOrigin-RevId: 168744486
* Inline CustomCommandLine methods that can be expressed using VectorArg.Gravatar tomlu2017-09-12
| | | | | | This whole CL was done using IDE refactoring tools and should be safe. PiperOrigin-RevId: 168275575
* Improve CustomCommandLine interface.Gravatar tomlu2017-08-22
| | | | | | | | | | | | | | | | In converting SpawnAction.Builder (multi-thousand line CL) users directly to CustomCommandLine I didn't like the resulting loss of readability, and the methods didn't feel very discoverable. Unless it's very convenient and readable to use CustomCommandLine, people will resort to non-memory efficient patterns by default. I'm holding that CL for this, which should offer a nicer interface. This CL removes VectorArg from the API contact surface area, instead creating 64 overloads for every valid combination of parameters. Pretty sad, but the methods dispatch straight to internal helper methods so it's mostly boilerplate to the tune of +400 LOC. Other changes: * Change ImmutableCollection -> Collection and copy the args directly into the internal args vector. Saves on collection object overhead and saves users from having to create immutable copies. * Change some names, notably add -> addAll for collection methods * Create additional missing overloads * Fix JavaDoc RELNOTES: None PiperOrigin-RevId: 165943879
* Stop using CustomMultiArgv in OneVersionCheckActionBuilder.Gravatar tomlu2017-08-22
| | | | PiperOrigin-RevId: 165925128
* Add more type safety to CustomCommandLine.Gravatar tomlu2017-08-16
| | | | | | | | | | | | Allowing add(Object) is too loose and can easily lead to programmer mistakes. Because of type erasure, we can't use the same overload name for (eg.) add(NestedSet<String>) and add(NestedSet<Artifact>). The API is overhauled to use the same terms everywhere, eg. "add", "addPaths", "addExecPaths". This is similar to how it used to be a few CLs ago. The API is overhauled to make sure it's consistent for all types. While tedious, the facade methods immediately dispatch to internal helpers, so implementation wise it's not too heavy. While large, this CL is almost entirely an automated refactor. PiperOrigin-RevId: 165358287
* Inline @Deprecated methods in CustomCommandLine.Gravatar tomlu2017-08-11
| | | | | | | | | Apart from updating CustomCommandLineTest this CL is entirely automated. We also sneak in a rename of addFormat -> addFormatted. RELNOTES: None PiperOrigin-RevId: 164870140
* Compute progress message lazily in spawn action.Gravatar tomlu2017-08-03
| | | | | | | | | | Consumers using spawn action builder now have access to handy overloads that behind the scene do a lazy String.format. In 95% of cases progress messages are expressible as 0, 1, or 2 argument String.formats. This saves memory because the format string is constant and shared between all actions, and the captured subjects are usually live on the heap anyway (eg. labels). Skylark still computes its progress messages eagerly. If we want similar savings there I'd have to follow up with a Skylark proposal. PiperOrigin-RevId: 164068816
* Detect one version violations while building android_binary targetsGravatar Googler2017-07-14
| | | | PiperOrigin-RevId: 161910195
* Add the option for warning-level enforcement of One Version violations. This ↵Gravatar Googler2017-05-04
| | | | | | updates --experimental_one_version_enforcement from a boolean flag to a 3-state enum (OFF, WARNING, ERROR). PiperOrigin-RevId: 154978203
* Install support for checking for 'one version' correctness of java_binaryGravatar Googler2017-02-10
rules: If the collection of jars for a java_binary contain more than one instance of the same class, one of them will be arbitrarily loaded at runtime. This is problematic if the instances of the class are not identical, as methods or fields from one class version might be missing in the other, leading to runtime failures when methods are missing. This change adds an experimental flag to enable one version enforcement. The actual enforcement tool will come later. -- PiperOrigin-RevId: 147166361 MOS_MIGRATED_REVID=147166361