Part 3: Per variant maven classpath support

[arunkumar9t2]

Succeeded by #89

Proposed Changes

Continuing from #44 this change further implements generating multiple maven_installs in WORKSPACE by introducing new Variant<T> suite of classes. Done in #57

Variant is a new abstraction to represent both Android and Jvm variants and currently abstracts Configuration parsing and supports largely moving away from ConfigurationDataSource implementation earlier. The new Variant APIs currently answers the following questions:

• What variants should we migrate in a given Gradle project? VariantBuilder helps to answer this information by returning set of Varaint<*>
• From there, we currently use these instances to find configurations and dependencies.
  • Because of this we are able to ensure a particular version of dependency used by a Gradle variant matches in Bazel. For example, debugImplementation('com.x:y-debug) will map to debug_maven@//com_x with alias to y-debug.

In a later stage, we can extend Variant<T> to further represent source set and other information needed for migration. Earlier non flavored migration assumption made #30 difficult, this new structure should largely simplify extending Grazel going forward by making it variant first. Eventually a single Gradle project instance will be migrated as follows. The new structure also makes it bit easier to write unit tests on each stage (added in this PR).

graph LR
    A[Project] --> B[Variants]
    B-->C[Targets]
    C-->D[BUILD.bazel]

Loading

Caveats