Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Part 2: Initial work on Variant API #57

Merged
merged 4 commits into from
Feb 3, 2023
Merged

Conversation

arunkumar9t2
Copy link
Contributor

@arunkumar9t2 arunkumar9t2 commented Feb 3, 2023

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.

Class hierarchy

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.

@arunkumar9t2 arunkumar9t2 added the enhancement New feature or request label Feb 3, 2023
@arunkumar9t2 arunkumar9t2 self-assigned this Feb 3, 2023
Copy link
Contributor

@roscrazy roscrazy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great works.

@arunkumar9t2 arunkumar9t2 merged commit c1e03bd into master Feb 3, 2023
@arunkumar9t2 arunkumar9t2 deleted the refactor-versions-part1 branch February 3, 2023 18:49
akshay-grabtaxi pushed a commit that referenced this pull request Jun 28, 2023
* Initial work on `Variant` API

* Add tests for `VariantBuilder`

* Revert code style changes

* Fix tests
akshay-grabtaxi pushed a commit that referenced this pull request Jun 28, 2023
* Initial work on `Variant` API

* Add tests for `VariantBuilder`

* Revert code style changes

* Fix tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants