aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/android/DataBinding.java
Commit message (Collapse)AuthorAge
* Add configuration for android data binding v2.Gravatar corysmith2018-08-06
| | | | | RELNOTES: None PiperOrigin-RevId: 207592136
* Inline static functions.Gravatar corysmith2018-08-06
| | | | | RELNOTES: None PiperOrigin-RevId: 207570533
* Add AndroidResources processing to the DataBindingContext.Gravatar corysmith2018-08-06
| | | | | RELNOTES: None PiperOrigin-RevId: 207564798
* Move maybeAddProvider to be part of the EnabledDataBindingContext.Gravatar corysmith2018-08-06
| | | | | RELNOTES: None PiperOrigin-RevId: 207553449
* Moved all external calls to isDataEnabled to DataBindingContext and made it ↵Gravatar corysmith2018-08-03
| | | | | | | private. RELNOTES: None PiperOrigin-RevId: 207335684
* Reduce and centralize databinding context instances.Gravatar corysmith2018-08-03
| | | | | | | Due to some of the vagaries of skylark and multiple entry points, the databinding context is currently updated by the parse action. RELNOTES: None PiperOrigin-RevId: 207333111
* Introduce the DataBindingContext interface as part of centralizing the data ↵Gravatar corysmith2018-08-03
| | | | | | | binding processing pipeline. RELNOTES: None PiperOrigin-RevId: 207312398
* Automated rollback of commit ce8f52060e2cf1e5a49a522039f0cba2a340f7e3.Gravatar cushon2018-07-25
| | | | PiperOrigin-RevId: 206102499
* Expose the UsesDataBindingProvider to Skylark (as UsesDataBindingInfo).Gravatar Googler2018-07-17
| | | | | RELNOTES: none. PiperOrigin-RevId: 205032841
* Automated rollback of commit f4a3dd9b8124dc7b2795f89e6700881b66371e4f.Gravatar lberki2018-07-12
| | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks //devtools/blaze/integration:{[]_test_test,gdp_validation_test} and at leats //contentads/supermixer/server:supermixer . *** Original change description *** Refactor handling of API generation in JavaPluginInfoProvider Instead of keeping two copies of state for the API-generating and non-API-generating cases, create a 'JavaPluginInfo' abstraction to contain all state for each case, and then keep two copies in the top-level JavaPluginInfoProvider provider. This will make it easier and less error-prone to add additional state to the provider. PiperOrigin-RevId: 204258844
* Refactor handling of API generation in JavaPluginInfoProviderGravatar cushon2018-07-11
| | | | | | | | | | | | Instead of keeping two copies of state for the API-generating and non-API-generating cases, create a 'JavaPluginInfo' abstraction to contain all state for each case, and then keep two copies in the top-level JavaPluginInfoProvider provider. This will make it easier and less error-prone to add additional state to the provider. PiperOrigin-RevId: 204151605
* Pass AndroidDataContext to remaining non-ActionBuilder codeGravatar asteinb2018-05-22
| | | | | | | | | | | | Now that the AndroidDataContext is passed everywhere, we can begin modifying action builders. This includes removing Label information from Proguard artifact paths. getUniqueDirectoryArtifact() already included label earlier in the path, so this information was redundant anyway. RELNOTES: none PiperOrigin-RevId: 197576210
* Make java_common.compile's javacopt handling consistent with native Java rulesGravatar cushon2018-04-25
| | | | | | | | | | | Compilations performed by java_common.compile now use the javacopts in the java_toolchain by default, instead of requiring them to be explicitly retrived using java_common.default_javac_opts, for consistency with the native rules. java_common.compile(javac_opts=...) can still be used to pass additional javacopts. RELNOTES: Make java_common.compile now uses java_toolchain javacopts by default; explicitly retrieving them using java_common.default_javac_opts is unnecessary. PiperOrigin-RevId: 194254098
* Add methods to parse resources without assetsGravatar asteinb2018-04-03
| | | | | | | | | | | | | | - Add ParsedAndroidResources to wrap AndroidResources and resource parsing output. - Implement parse() method in AndroidResources, and support for it elsewhere - Move some supporting methods to the right place (setting up an aapt2 sdk for tests goes to the base test rule, and creating a dummy DataBinding zip goes to the DataBinding class). - Tests for new parse() method, including support for getting a test RuleContext instance RELNOTES: none PiperOrigin-RevId: 191436027
* Rename LocalResourceContainer to AndroidResources and remove asset code from itGravatar asteinb2018-03-29
| | | | | | | | | | | | | As part of decoupling Android resources and assets, rename LocalResourceContainer to AndroidResources and remove asset code from it. Some general asset and manfiest code still remains and will be dealt with in future changes. Remove LocalResourceContainer from the ParsingActionBuilder, since it's always used to build the ResourceContainer that is subsequently passed in. RELNOTES: none PiperOrigin-RevId: 190945260
* Automatic formatting cleanup of Android *.java files.Gravatar jingwen2017-12-18
| | | | | RELNOTES: None. PiperOrigin-RevId: 179425421
* Build databinding annotation processor in host configuration.Gravatar ajmichael2017-11-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Also, add a fake databinding processor target. Bazel users will need to do something like this: # WORKSPACE local_repository( name = "databinding", path = "./databinding", ) bind( name = "databinding_annotation_processor", actual = "@databinding//:annotation_processor", ) # databinding/BUILD java_plugin( name = "annotation_processor", ... ) ... https://github.com/bazelbuild/bazel/issues/2694 RELNOTES: None PiperOrigin-RevId: 175975110
* 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
* Move RuleConfiguredTarget to lib.analysis.configuredtargets.Gravatar gregce2017-09-19
| | | | | | This is a trivial change with a large file footprint. PiperOrigin-RevId: 169169864
* Cleanup some databinding code that was messed up by ↵Gravatar ajmichael2017-09-19
| | | | | | | https://github.com/bazelbuild/bazel/commit/b30b3de23a7fa01b8290ace0e688d75405689825 RELNOTES: None PiperOrigin-RevId: 169169249
* Remove concept of "processorFlags" from Bazel.Gravatar ajmichael2017-09-14
| | | | | | | They are just normal javacopts. The only user was Android databinding, so now we just merge databindings javacopts in with the rest of javacopts in AndroidCommon. RELNOTES: None PiperOrigin-RevId: 168578013
* Fix NullPointerException when enable_data_binding is omitted.Gravatar gregce2017-06-26
| | | | | | | | | DataBinding.isEnabled has outdated logic that enabled data binding for a rule even if only its deps use data binding. It's now required for all rules up the dependency chain to explictily enable data binding. RELNOTES: None. PiperOrigin-RevId: 159998478
* Expose Bazel's Android data binding support to users.Gravatar gregce2017-04-18
| | | | | | | | | | | | The logic is already in Bazel but wasn't available to build rules. This change makes it available, but still requires data binding's {build|run}time libraries to be checked into appropriate depot spots for everything to work. Followup changes will make those libraries easily available. Issue: #2694 PiperOrigin-RevId: 153359861
* Make Android data binding rules explicitly depend on the runtime library.Gravatar gregce2017-04-13
| | | | | | | | | Before this change Bazel was adding this implicitly. But that wasn't working properly with --incremental_dexing. And that implementation is a lot messier and bug-prone vs. just including it as a standard dependency. Issue: #2694 PiperOrigin-RevId: 152956638
* Upgrade Android data binding integration to work with newest libraries.Gravatar gregce2017-04-06
| | | | | | | | | | | This change makes Bazel work with data binding runtime libraries 1.3.1 and buildtime libraries 2.3.1. The biggest change is to configure the annotation processor with javac annotation processor flags ("-Aflag=value") instead of directly through annotations in a template Java file. PiperOrigin-RevId: 152282448
* Stop Bazel from crashing on data-bound Android libraries with no resources.Gravatar Greg Estren2017-03-16
| | | | | | | | | | These libraries don't produce data binding outputs on resource processing (since there's nothing to process). Their only role is to pass through the outputs of their deps. -- PiperOrigin-RevId: 150251921 MOS_MIGRATED_REVID=150251921
* Tune naming of Android data binding metadata files.Gravatar Greg Estren2017-02-20
| | | | | | | | | | | | | | | | This puts Bazel in line with the paths actually produced by the data binding resource processor. This difference matters when the library name doesn't match the package name (the build fails without this change). I started writing a shell integration test to check this end-to-end. But staging all the data binding support libs and their deps is a mess. Too much so, IMO. -- PiperOrigin-RevId: 147868538 MOS_MIGRATED_REVID=147868538
* Clean up RuleContext's attribute access API.Gravatar Greg Estren2016-12-02
| | | | | | | | | | | | | | | All calls now go through RuleContext.attributes(), which guarantees both native and aspect-supplied attributes are checked. For aspect attributes, only type queries are supported (e.g. "does this attribute exist?", "what is its type?"). Not value queries. This is because the code this is cleaning up accesses aspect attributes through a String->Attribute map, which doesn't include values. If ever needed we could further extend with something more robust. -- MOS_MIGRATED_REVID=140771242
* Adds internal data binding support to Bazel, although thisGravatar Greg Estren2016-11-21
is not yet exposed at the user level. (https://developer.android.com/topic/libraries/data-binding/index.html). See comments in DataBinding.java for the high-level overview of how this works. This does not yet work with --experimental_use_parallel_android_resource_processing. Exposing this at the user level additionally requires: 1) making the data binding support libraries available at an expected place in the depot 2) Opting in android_binary / android_library rules through a new "enable_data_binding" attribute. -- MOS_MIGRATED_REVID=139797558
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-30 14:56:13 +0000