aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/java/proto/JavaLiteProtoAspect.java
Commit message (Collapse)AuthorAge
* Add exports attribute to proto_library.Gravatar twerth2018-08-14
| | | | | | | Note that it is currently only used by the java_proto_library family of rules (if enabled per flag). RELNOTES: None PiperOrigin-RevId: 208601730
* Add manifestProtoOutput produced during Java compilation to the OutputJar so ↵Gravatar Googler2018-07-30
| | | | | | | that it can be accessed in Skylark. One example where this is used is in Android IDL processing where the manifestProtoOutput is used to split out the Android IDL generated Java classes from the overarching outputJar produced by the android_library rule. RELNOTES: none PiperOrigin-RevId: 206580880
* [Reland] Accept proto paths relative to proto_source_root as direct ↵Gravatar Googler2018-07-09
| | | | | | | | | | | | | | | dependencies. This is a reland of https://github.com/bazelbuild/bazel/commit/5deca4cf88f5568771f2c836a9b8c693b88bd749. This will make protoc see as direct dependencies the .proto files that were included using the proto_source_root flag. Until now, Bazel passed to protoc the direct dependencies of a target as the path relative to the WORKSPACE, which made it fail when a shorter path, relative to the package was used. Progress on #4544. RELNOTES: None. PiperOrigin-RevId: 203808292
* Expose aspect actions from Skylark.Gravatar tomlu2018-06-22
| | | | | | | | | | | Like with providers, consumers get a merged view of all actions from the merged configured target (all other aspects + the base target). I had to rejig the aspect value / configured aspect to be symmetric with rule configured targets. I do not expect significant memory bloat from this. All lists / maps already existed, only extra fields have been added. RELNOTES: Expose aspect actions provider to Skylark. PiperOrigin-RevId: 201697923
* Make java_toolchain attribute Environment aware.Gravatar dbabkin2018-06-18
| | | | | RELNOTES:none: PiperOrigin-RevId: 200988244
* Normalize parameter name commentsGravatar cushon2018-04-27
| | | | PiperOrigin-RevId: 194512971
* Add getters to JavaCompilationArgsProviderGravatar cushon2018-04-24
| | | | | | | | | | for direct, transitive, and full compile-time jars; runtime jars; and instrumentation metadata. These are trivial wrappers around the corresponding getters on the recursive and non-recursive JavaCompilationArgs objects. This is a no-op refactoring in preparation for flatting JavaCompilationArgs into JavaCompilationArgsProvider. PiperOrigin-RevId: 194047064
* Add BuildConfiguration to ConfiguredTargetAndTarget and rename it to ↵Gravatar janakr2018-03-10
| | | | | | ConfiguredTargetAndData. We want to get BuildConfiguration out of ConfiguredTarget because it uses >800K when serialized. PiperOrigin-RevId: 188600002
* PiperOrigin-RevId: 186532302Gravatar ahumesky2018-02-21
|
* Accept proto paths relative to proto_source_root as direct dependencies.Gravatar elenairina2018-02-20
| | | | | | | | | | | This will make protoc see as direct dependencies the .proto files that were included using the proto_source_root flag. Until now, Bazel passed to protoc the direct dependencies of a target as the path relative to the WORKSPACE, which made it fail when a shorter path, relative to the package was used. Progress on #4544. RELNOTES: None. PiperOrigin-RevId: 186294997
* Add "proto_source_root" flag to proto_library.Gravatar elenairina2018-02-16
| | | | | | | Fixes #4544. RELNOTES: Add "proto_source_root" flag to proto_library. PiperOrigin-RevId: 185997723
* Pass --target_label, --injecting_rule_kind to all java compile actions.Gravatar tomlu2018-02-14
| | | | | | | | JavaBuilder and friends will write this into the manifest of the produced jars to assist with add_dep commands, when strict_deps is violated. This will obviate the need for blaze to pass jar owners on the command line. PiperOrigin-RevId: 185763422
* Move common proto aspect logic to a new class.Gravatar elenairina2018-02-12
| | | | PiperOrigin-RevId: 185369902
* Stop allowing generic LateBoundDefault value types. Such types are always ↵Gravatar janakr2018-02-02
| | | | | | | | either a Label or a List<Label>. We can easily enforce this through static type checking, so do it. This will help with LateBoundDefault serialization, since we don't have to serialize an arbitrary object. PiperOrigin-RevId: 184347100
* Change ConfiguredAspectFactory.create signature to take in aGravatar mjhalupka2018-01-31
| | | | | | | ConfiguredTargetAndTarget instead of a ConfiguredTarget. This is to assist in deprecating ConfiguredTarget.getTarget(). PiperOrigin-RevId: 184043491
* Add neverlink support to java_common.compile.Gravatar elenairina2018-01-31
| | | | | | | Fixes #3735. RELNOTES: java_common.compile supports neverlink PiperOrigin-RevId: 184017410
* Move all code to lookup JavaRuntimeInfo to static methods onGravatar John Cater2018-01-23
| | | | | | | JavaRuntimeInfo. Change-Id: Ic338dc9b3e5efa2fee92dba722a46cab743db40c PiperOrigin-RevId: 182919931
* Remove package loading from JvmConfigurationLoader .Gravatar lberki2018-01-10
| | | | | | | | | | | | | This should not cause a user-visible change: --{host_,}javabase was already required to point to a java_runtime_suite / java_runtime rule, the only change is that we now enforce it differently. If anything, this makes Bazel more lenient in that it now accepts Skylark rules that provide JavaRuntimeInfo, but I doubt anyone does that, since it does not work at HEAD. RELNOTES: None. PiperOrigin-RevId: 181444563
* Remove code that used to support --javabase=<absolute path>.Gravatar lberki2018-01-08
| | | | | | | | | This is the first step in removing package loading from JvmConfigurationLoader (I didn't want to add the rest into this change because it's technically possible to access ctx.fragments.jvm even though it contains no fields, so removing that is an incompatible change) and it's also possible that removing error reporting from JvmConfigurationLoader causes some subtle changes in behavior. Baby steps. Now that the hard part is done, there is no need to rush. RELNOTES: None. PiperOrigin-RevId: 181143978
* Change cfg(HOST) to cfg(HostTransition.INSTANCE).Gravatar gregce2017-12-21
| | | | | | Preparatory step for removing ConfigurationTransition.HOST. PiperOrigin-RevId: 179838374
* Create the output source jar in java_common.compileGravatar elenairina2017-11-29
| | | | | | | | | | | | | | | | | and expose transitive source jars to Skylark. Initial change was rolled back (unknown commit). java_common.compile wouldn't fill the JavaRuleOutputJarsProvider when there was only one input source jar. Fixed that and added test (there was one before, but didn't check this particular provider). Slightly refactor java classes to take in specific host javabase inputs and host java executable for creating the source jar, instead of always relying on fetching them from native java rules specific attributes. Creating the output source jar in java_common.compile makes the behavior more similar to java_library. Exposing the transitive_source_jars to Skylark helps with the Skylark migration from the old 'java' provider to JavaInfo. Progress on #2614. RELNOTES: transitive_source_jars is now exposed on JavaInfo. PiperOrigin-RevId: 177311138
* Automated rollback of commit a6ed4c01d374bcf98bf39c1efc12a0f4f20fe313.Gravatar elenairina2017-11-27
| | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks //javatests/com/google/devtools/intellij/blaze/plugin/aspect/java/soygenrule:SoyGenruleTest *** Original change description *** Create the output source jar in java_common.compile and expose transitive source jars to Skylark. Slightly refactor java classes to take in specific host javabase inputs and host java executable for creating the source jar, instead of always relying on fetching them from native java rules specific attributes. Creating the output source jar in java_common.compile makes the behavior more similar to java_library. Exposing the transitive_source_jars to Skylark helps with the Skylark migration fr... *** RELNOTES: None. PiperOrigin-RevId: 177015958
* Create the output source jar in java_common.compileGravatar elenairina2017-11-24
| | | | | | | | | | | | | | | and expose transitive source jars to Skylark. Slightly refactor java classes to take in specific host javabase inputs and host java executable for creating the source jar, instead of always relying on fetching them from native java rules specific attributes. Creating the output source jar in java_common.compile makes the behavior more similar to java_library. Exposing the transitive_source_jars to Skylark helps with the Skylark migration from the old 'java' provider to JavaInfo. Progress on #2614. RELNOTES: transitive_source_jars is now exposed on JavaInfo. PiperOrigin-RevId: 176844750
* Return JavaInfo providers only once in Java rules.Gravatar elenairina2017-10-11
| | | | | | | Previously the java rules returned some providers twice: once as regular providers and once wrapped in JavaInfo (e.g. JavaCompilationArgsProvider). This is unnecessary, inefficient and error prone. JavaInfo should be the only way of returning these providers. RELNOTES: None. PiperOrigin-RevId: 171663550
* Expose JavaRuleOutputJarsProvider in java_common.provider, when available.Gravatar Googler2017-09-28
| | | | | | | | | | | | I'm not attempting to fix b/65618333 here, just handling one case currently breaking users (JavaInfo created via java_common.compile). My temporary workaround attempt to expose this information in the soy custom rule failed (unknown commit) -- to fix users we really need java_common changes. RELNOTES: Expose output jars and jdeps in java_common.provider, when available. PiperOrigin-RevId: 170236096
* LateBoundDefault: enforce access to a single fragment (or none).Gravatar mstaib2017-09-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, there is no way to enforce that LateBoundDefaults only access the fragments that they declare. This means that LateBoundDefaults can fail to declare fragments at all, or declare the wrong ones, and still have no troubles. But when trimming, these fragments must be declared, because otherwise they will not necessarily be available. This change refactors LateBoundDefault to declare a single fragment type, not a set. All existing LateBoundDefaults use sets with a single element or no elements at all for their set of fragment classes, so this does not limit anything being done currently. To account for LateBoundDefaults which do not use configuration at all, typically those which only want to access the configured attribute map, it is possible for Void to be the fragment class which is requested. To account for LateBoundDefaults which need to access methods of the BuildConfiguration instance itself, it is possible for BuildConfiguration to be the fragment class which is requested; however, this is unsafe, so it is only a temporary state until a way to do this without also giving access to all of the fragments can be added. Drive-by refactoring: LateBoundDefaults' values are now typed. All actual production LateBoundDefaults were Label or List<Label> typed, through the LateBoundLabel and LateBoundLabelList subclasses. These subclasses have been removed, and LateBoundDefault has two type parameters, one for the type of its input, and one for the type of its output. RELNOTES: None. PiperOrigin-RevId: 169242278
* Move RuleConfiguredTarget to lib.analysis.configuredtargets.Gravatar gregce2017-09-19
| | | | | | This is a trivial change with a large file footprint. PiperOrigin-RevId: 169169864
* Defer expansion of certain proto command line string arguments.Gravatar tomlu2017-08-10
| | | | | | | Memory is saved by sharing the format string and label object instances, instead of constructing new strings for each action. RELNOTES: None PiperOrigin-RevId: 164731899
* PiperOrigin-RevId: 163848560Gravatar carmi2017-08-02
|
* Provide CcLinkParamsStore from java_xxx_proto_library rules.Gravatar carmi2017-08-02
| | | | | RELNOTES: None PiperOrigin-RevId: 163838735
* Automated rollback of commit 7d0200703cfa207d6577d84bee45ca185d240dfa.Gravatar carmi2017-07-25
| | | | | | | | | | | | SKIP_KOKORO: Kokoro is out of quota. *** Reason for rollback *** Causes memory regression, somehow: b/63934093 *** Original change description *** PiperOrigin-RevId: 163023580
* PiperOrigin-RevId: 162771369Gravatar carmi2017-07-24
|
* Update the default values for the C++ and Java late-bound attributes to the ↵Gravatar janakr2017-07-10
| | | | | | correct //tools/cpp:toolchain and //tools/jdk:jdk. PiperOrigin-RevId: 161227981
* Automated rollback of commit 68b9a7e2dc17e32b194238d287e79bee1ba035b9.Gravatar cushon2017-06-26
| | | | | | | | | *** Reason for rollback *** The depot is fixed RELNOTES: None. PiperOrigin-RevId: 160115070
* Move WrappingProviderHelper into static class in WrappingProvider.Gravatar Googler2017-06-20
| | | | | | Cuts down on file count and makes it easier to find these methods. PiperOrigin-RevId: 159560422
* Create a general WrappingProvider concept and use for java_proto_library and ↵Gravatar Googler2017-06-20
| | | | | | | | | | | | friends. The wrapping provider contains its own provider map containing any providers that may conflict. This can be used generally for any aspect that wants to override its base providers (during migration), and due to the generality we should be able to cut down on code size and complexity. Once we have this, we can more easily and uniformly bind aspects to Skylark for aspect-on-aspect functionality. The Skylark providers can be instantiated with a wrapping provider if one is present, or fall through to the base target if they aren't. We will also likely save a bit of memory from cutting down on wrapping classes. PiperOrigin-RevId: 159461325
* Automated g4 rollback of commit da56606563ee9df438db93392f681bf2abb4ac97.Gravatar brandjon2017-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | NO_SQ=Only failing TAP targets in our project are from an unrelated bug. *** Reason for rollback *** Initially we thought this broke just a few builds that were fixed in the depot. The scope is wider than that, affecting at least these two targets: [] [] There are hundreds of other failures in the TGP results that we haven't traced to a cause yet, but it's troubling that this CL was implicated twice in the small sampling I did. [] *** Original change description *** Use JavaCompilationArtifacts instead of JavaCompilationArgs to store Java compilation artifacts. Round-tripping through JavaCompilationArgs loses dependency information that upstream compilations use to optimize compile time classpaths. PiperOrigin-RevId: 159154375
* Use JavaCompilationArtifacts instead of JavaCompilationArgsGravatar cushon2017-06-08
| | | | | | | | to store Java compilation artifacts. Round-tripping through JavaCompilationArgs loses dependency information that upstream compilations use to optimize compile time classpaths. PiperOrigin-RevId: 158360995
* Add a source_jars variable to OutputJar.Gravatar Irina Iancu2017-03-08
| | | | | | | | | | | Having a correlation between an output jar and a source jar is not enough. There may be situations when an output jar is generated from more source jars, not just one. We need this flexibility especially in Skylark for the java sandwich, when the user can compile multiple source jars. -- PiperOrigin-RevId: 149510534 MOS_MIGRATED_REVID=149510534
* Restrict aspects visible to other aspects according to their advertised ↵Gravatar Dmitry Lomov2017-02-15
| | | | | | | | providers. -- PiperOrigin-RevId: 147526961 MOS_MIGRATED_REVID=147526961
* Remove the ability for an aspect to propagate a different aspect.Gravatar Dmitry Lomov2017-01-20
| | | | | | | | | This functionality is never used, have never been exposed to Skylark and is a continuous pain to maintain and test. -- PiperOrigin-RevId: 145079832 MOS_MIGRATED_REVID=145079832
* Add the output_licenses attribute to java_toolchain and make Bazel use it ↵Gravatar Lukacs Berki2017-01-17
| | | | | | | | when it's reached through a :java_toolchain attribute. -- PiperOrigin-RevId: 144638966 MOS_MIGRATED_REVID=144638966
* Consolidate host javabase input lookupGravatar Liam Miller-Cushon2017-01-12
| | | | | | -- PiperOrigin-RevId: 144257691 MOS_MIGRATED_REVID=144257691
* Advertise java Skylark provider from java proto aspects.Gravatar Googler2017-01-10
| | | | | | | | The skylark provider is bound as "proto_java" to avoid collisions with the base, which is called "java". -- PiperOrigin-RevId: 143960605 MOS_MIGRATED_REVID=143960605
* When a strict proto dep violation occurs, tell the user what they should fix.Gravatar Carmi Grushko2016-12-05
| | | | | | -- PiperOrigin-RevId: 140912072 MOS_MIGRATED_REVID=140912072
* Allow aspects to specify multiple sets of required providers to match ↵Gravatar Rumou Duan2016-12-01
| | | | | | | against rules. Aspects can attach to a rule if at least one set of required providers are present on the rule. -- MOS_MIGRATED_REVID=140605023
* Make it easier to use protos in Bazel out of the box.Gravatar Carmi Grushko2016-11-29
| | | | | | | | | java_xxx_proto_library rules now look for toolchains in the external repo @com_google_protobuf_xxx//:xxx_toolchain This still requires getting protobuf's GitHub repository to build with Bazel. -- MOS_MIGRATED_REVID=140420903
* Provide AspectDescriptor to ConfiguredAspect.Gravatar Dmitry Lomov2016-11-29
| | | | | | | | Also clean up the setting of aspect name in ConfiguredAspect and AspectDefintion - it is now obtained from the AspectClass. -- MOS_MIGRATED_REVID=140357052
* Alias proto_library's produce a descriptor set that contains all srcs of its ↵Gravatar Carmi Grushko2016-11-23
| | | | | | | | | | | dependencies. (alias proto_library's are those with a deps attribute but no srcs attribute) RELNOTES: Alias proto_library's produce a descriptor set that contains all srcs of its dependencies. -- MOS_MIGRATED_REVID=139940475
* Changing constructor of JavaCompilationHelper and removingGravatar Irina Iancu2016-11-16
| | | | | | | | | | | | | BaseJavaCompilationHelper. Changed JavaCompilationHelper constructor to take in the object it used to construct itself: java toolchain, a host javabase and a jacoco instrumental. Because the objects are now directly passed to the constructor there is no more need anymore for the implicit attribute suffix, that was used to construct these objects. I also removed BaseJavaCompilationHelper as it was only used to create an ijar action and only had one class extend it (JavaCompilationHelper). All methods that construct objects (java toolchain, host javabase, jacoco instrumental) were moved to JavaCompilationHelper as static methods and the rest of its method were moved as they were also to JavaCompilationHelper. This is needed in order to pass the right toolchain/host javabase/jacoco instrumental from a Skylark module. The problem arises when a Skylark aspect/rule is created and its attributes will have different labels then a Java native rule/aspect because they must be prefixed with "_" instead of ":", so their value cannot be retrieved in the same default way. -- MOS_MIGRATED_REVID=139310690
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-23 12:49:34 +0000