service protocol build control

[kggilmer]

Issue #, if available: smithy-lang/smithy-kotlin#306

Description of changes:

• Allows to specify services to exclude in addition to inclusion for SDK generation
• Allows to specify protocols to include or exclude for services in SDK generation

Testing Done

I wrote this unit test to verify functionality but didn't include it since it's build code. Unsure of where tests would go for that.

class MembershipTest {
    @Test
    fun `it handles defined memberships`() {
        val unit = parseMembership("+a, +b, -c")

        assertTrue(unit.isMember("a"))
        assertTrue(unit.isMember("b"))
        assertFalse(unit.isMember("c"))
        assertFalse(unit.isMember("f"))
        assertFalse(unit.isMember(""))
    }

    @Test
    fun `it handles implicit memberships`() {
        val unit = parseMembership("-a, -b,-c")

        assertFalse(unit.isMember("a"))
        assertFalse(unit.isMember("b"))
        assertFalse(unit.isMember("c"))
        assertTrue(unit.isMember("f"))
        assertTrue(unit.isMember(""))
    }

    @Test
    fun `it handles conflicts`() {
        Assertions.assertThrows(IllegalArgumentException::class.java) {
            parseMembership("-a,    +a")
        }
    }
}

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[ianbotsf]

Very nice.

[aajtodd]

Nice! Couple suggestions but LGTM.

I wrote this unit test to verify functionality but didn't include it since it's build code. Unsure of where tests would go for that.

@ianbotsf @kggilmer Tagging both of you for visibility on Gradle functionality...

If you wanted to you could abstract this away into buildSrc which would allow tests. buildSrc allows custom code that is compiled BEFORE gradle configures the project. All types/functions/tasks/etc in buildSrc are made available to every gradle build script that is part of the project. People use this all the time to define library versions or custom tasks they want re-used, etc. It can also be used to define custom plugins (although more and more people are using composite builds for custom plugins).

Example from toolkits repo: https://github.com/aws/aws-toolkit-jetbrains/tree/master/buildSrc
Example from kotlinx.coroutines repo: https://github.com/Kotlin/kotlinx.coroutines/tree/master/buildSrc

[aajtodd]

question

should we retain + as optional? It would maintain the current behavior and make e.g. generating a handful of services less ceremonious aws.services=+lambda,+s3,+iam

[kggilmer]

Yeah I was thinking about that too. I went back and forth but slightly favor requiring requiring the plus for these reasons:

1. generally speaking less configuration variance is easier to maintain over time (very weak admittedly in this case)
2. the + self-documents the feature that exclusions are also available.
3. it may be less confusing when reasoning about the rules if the ex/in-lusion is explicit.

IMHO these are a bit stronger than the convenience argument

[aajtodd]

suggestion

When unspecified all services found in the directory specified by the `modelsDir` property ...

[aajtodd]

nit

Example ~ prefix on all these seems redundant

[aajtodd]

fix

The intent of this section was to document the available build properties. The new section you added with the examples is fine and can remain as is but I still think we ought to document the available properties in one place.

[kggilmer]

Sure, I added a table that describes all available properties directly in this section.

[kggilmer]

Regarding the buildSrc idea, it's great! I added a follow-on issue I'll work on once the important release tasks are complete: https://github.com/awslabs/smithy-kotlin/issues/312