PLAM

PLAM – PLugin for Android Modularisation, simplifying architectural tasks and verifying dependencies between different module types.

Easy to use

If you are just starting a new project, that’s all build script code you will need:

//project build.gradle.kts
import com.pwssv67.plam.*

plugins {
    id("com.android.application") version "8.0.0" apply false
    id("org.jetbrains.kotlin.android") version "1.8.10" apply false
    id("com.android.library") version "8.0.0" apply false
    id("io.github.pwssv67.plam") version "0.2.2" apply false
}

configure {
    appConfig {
        namespace = "com.sample.app"
        compileSdk = 33

        defaultConfig {
            applicationId = "com.sample.app"
            minSdk = 26
        }
    }
}

//app build.gradle.kts
import com.pwssv67.plam.*

androidApp(
    dependencies = listOf( //possible list of dependencies
        impl("androidx.core:core-ktx:1.10.1"),
        impl("androidx.lifecycle:lifecycle-runtime-ktx:2.6.1"),
    ) + listOf(
        testImpl("junit:junit:4.13.2")
    )
)

Keeping track of module types

There are currently four module types:

• App – for app itself, as build endpoint, accumulating all other dependencies. Can be used only in other Apps. Can use anything.
• FeatureAPI – feature API or signature, like starting params needed for feature. Has the same role as an interface to an actual implementation: for dependency inversion. Can use only libraries.
• FeatureImpl – feature actual implementation. Can only be used in App module. Can use other feature’s APIs and libraries
• Library – widely used code, like network requests, design components, etc. Can be added to any module.

Dependency type check before builds

It analyzes the declared dependencies between modules and validates whether they comply with these predefined rules. If a module attempts to declare an unsupported dependency, the plugin will automatically fail the build and provide clear error messages to help you identify and resolve the issue.

Minimal boilerplate

You can write all common configuration code once, in root build.gradle.kts, and only change necessary parts for each module (like namespace or IDs)

Typical module structure

flowchart TD
    A{App}
    B([Network Library])
    C([Design Library])
    D(Feature 1 API)
    E(Feature 2 API)
    F[Feature 1 Implementation]
    G[Feature 2 Implementation]

    A --> F & G
    F --> D & B & C & E
    G --> E & C 

For the sake of simplicity, App’s dependencies to features’ APIs are omitted.

Use Samples

Sample project

GitHub

View Github