Use Gradle @Nested annotation?

[bitspittle]

Kobweb's Gradle blocks are nested, e.g.

kobweb {
   index { ... }
}

kobwebx {
   markdown { ... }
}

We're doing this manually right now using nested ExtensionAware.create calls but I just learned about the @Nested annotation. Maybe that can clean up the code a bit?

[bitspittle]

According to ChatGPT4, the way we're writing block logic in Kobewb (via ExtensionAware) is actually the preferred approach:

---

Using the ExtensionAware and extensions API is a more modern approach to defining extensions and nested configurations in Gradle, especially when using the Kotlin DSL. This is often preferred for several reasons:

1. Immutability & Laziness: By using properties (like Property<String>) from Gradle's API, you can make your extensions and tasks lazy-configured. This means configuration won't be evaluated until it's necessary, leading to faster configuration times.

2. Default Values & Convention: With properties, you can easily provide default values or conventions, making it easier for users of your plugin.

3. Better Kotlin DSL Interoperability: Your approach is more idiomatic for the Kotlin DSL. It makes using the plugin more natural for projects written in the Kotlin DSL.

4. Flexibility: By using the extensions API, you can dynamically add or modify nested blocks, giving more flexibility in structuring your plugin's configuration DSL.

Now, should you prefer this over @Nested? Here are some thoughts:

• For tasks, @Nested is still relevant. When you define a custom task with nested properties that should be taken into account for up-to-date checks, the @Nested annotation is what you'd use.

• For extensions, especially when targeting both Groovy DSL and Kotlin DSL users, the ExtensionAware approach can be more versatile and idiomatic.

In summary:

• If you're defining extensions and aiming for idiomatic Kotlin DSL support, the ExtensionAware approach can be more appropriate.

• If you're defining tasks with nested properties that should be considered for task input, the @Nested approach is the way to go.

That said, always consider the needs of your users and the context in which your plugin will be used. Depending on the user base and their preferences, one approach might be more advantageous than the other.