Forma Requirements 2023

[michaem]

Here will be description of all requirements for modern Android development with scalable structure and project architecture.
Forma should help build project architecture with stable scalable metrics: build time, weak deps, feature extending for 50-100+ mobile engineers per project.

Killer metrics of Forma are STP:

• Providing scalable to your project
• Carefully to your build time
• Boost your performing and TTM

[michaem]

Build System requirements

1. Used easy setup project structure from settings.gradle
Prefered auto-generatation from existed module structure already

2. Provided dependencies management and them versions control
Now deps provided from buildSrc paradigm and versionsCatalog features

3. SImple plugging Forma tools for outer projects
Just describe your artifactory/nexus/maven repo and directly pass credentions to them, if necessary

4. Doesn't use buildSrc paradigm
Forma themself provides deps, versions, changes to all project-subprojects and carefully for cache

5. Shortly and clearly plugged other root pluggins
You can easy plug root pluggins sush as: kotlin-stdlib, agp, gradle pluggin and etc. They shared for all subproject

6. Easy applied pluggins for subprojects
Just apply necessary plugging to your module and you're ready (may be some concern with module semantic validation)

7. Easy plugging dependencies for extraPlugins
Forma provided by using simply context '.' plugging any deps from deps-source (p. 2), if it doens't broke module type semantinc restrictions

8. Provided Build Type management
Just describe, what're build types project needs (debug, release, custom) and you'll have it with shrinking rules

9. Scalable multi-module structure
You don't need monolith modules types, such as: androidLibrary. Just using type-safe module types: api, impl, lib, util, you can build scalable multi-module structure, with carefuly for caching, all-ready deps rules between modules (api to api, but impl not to other impl) and build features (compose, androidRes) underhood.

10. Provided declarative building configs
Ofen you need to pass some configs into 3thd part systems, such as analytics for subproject

11. Separated plugging for Forma features
You choose only Forma features, that necessary by plugging them separatly standalone

12. Supported UI/Unit test env for modules

13. Supported flavors configuration

[michaem]

Future changes:

• android is "god module"
• reduce module types count

[stepango]

My current thinking is not to reduce module count but make a single target definition produce multiple gradle projects e.g.
Feature module could be structured in the current way

- feature-a
  - feature-a.build.gradle.kts
  - src
    - main
      - java
        - com.example.feature-a
          - api -- only included in source set of feature-a-api target
          - impl -- only uncluded in source set of feature-a-impl target