| Age | Commit message (Collapse) | Author |
|---|
|
Dagger 2.29.1
Bug: 173800389
Test: m checkbuild
Change-Id: I826b8571bb972339bd5bd89ca2c23912f4eae2d9
|
|
RELNOTES=Update macro and README with instructions for Bazel users.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=315389535
|
|
Android transforms are not applied for JUnit tests which breaks when using
the Hilt Plugin and its transform. This CL adds a new custom test transform
task just for tests so that transformed classes are used in Android JUnit tests.
The task does not transform test sources, therefore temporarily allow specifying
a base class in @AndroidEntryPoint that will be used even if the superclass
validation option is given to the processor. This helps us still have test-only
Android Entry Points.
Closes https://github.com/google/dagger/pull/1811
RELNOTES=n/a
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=309143731
|
|
Dagger 2.23.1
Bug: 135055683
Test: treehugger
Change-Id: I156d4a37bca95fdef66df71f5abdc93027d1e4c1
|
|
Closes https://github.com/google/dagger/pull/1268
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=243314246
|
|
This resets the state of the source tree to match upstream 2.22.1,
plus Android-specific files.
Bug: 130306229
Test: m checkbuild
Change-Id: I24d365a842a62f7fa70560981ca509e92ec8b7ce
Merged-In: I24d365a842a62f7fa70560981ca509e92ec8b7ce
Exempt-From-Owner-Approval: cherry pick
(cherry picked from commit c005ec5aefd8dc1c8adcaf8193ed172abe07fdc9)
|
|
The Maven infrastructure is not being removed in this CL. We will build and test with both Maven and Bazel until we have a successful release to Maven Central using bazel-built artifacts and automated tools to generate poms/ship to Central.
This CL does not address any of the scripts in util/ like publishing snapshots or generating javadoc. It also does not reorganize files into a more traditional bazel project structure.
Open questions:
- What should we do about shading?
- Right now, only auto-common is shaded. If we shade it, should we remove it from the deps of the compiler POM, since other users don't need it to build?
- How should we implement shading? One idea is to make a unified jar of the bazel-built compiler and auto-common, and then use jarjar to rename classes.
- What should we do with dagger-gwt? I'm not a GWT expert but it seems that we could recreate that jar with a genrule + jarjar
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144448160
|
|
Fixes google/dagger#514
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140385921
|
|
longer relevant now that members injectors call static methods to inject inherited members. Specifically, it is no longer necessary to have parent injector requests, or to strip them away if their parent's injector uses a no-op strategy. It's still necessary to generate MembersInjector implementations for superclasses that have injection sites, but that logic moves from BindingGraph.Factory.Resolver to InjectBindingRegistry.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=107776384
|
|
Bug: 24848946
Change-Id: I1b359bbbf8b07de1f84f3b7dfd263a58f0fd439b
|
|
|
|
|
|
configuration works in (at least) intellij.
|
|
|
|
|
|
|
