Part 2: Initial work on Variant API

[arunkumar9t2]

Proposed Changes

Branched off from #45 to reduce total diff. This contains the new Variant API as described in the other PR that help categorize variants and their configurations accounting for flavors and build types.

VariantBuilder will help construct set of Variant which can be used by rest of the code to infer and start migration

No changes in the generated code yet, will follow up with part 3.

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

Testing

Add tests for new classes.

[roscrazy]

Great works.