If you want ideas, you should check out Ratpack (a web framework for Groovy or Java) and the way the Ratpack.groovy DSL looks.
* Convention over configuration: implicit defaults for everything so the hello world example is very simple. If you try to create a new Java project in Gradle, not by copying and pasting or having the IDE autogenerate something for you, you're going to have a bad time.
* Whenever you do want to add something, there is a clear place within the structure of the root ratpack{} closure to add it. The port goes under serverConfig, routes go under handlers, etc. You don't set the port under the routing handlers, that would make no sense. Very different than build.gradle which feels like a flat list of unrelated tasks.
* Support for both anonymous code and for code which has been factored out. Of course Gradle supports this (factoring out buildscript dependencies instead of a flat build.gradle) but the experience makes you feel like you're playing around with Frankenstein's monster so hardly anybody ever does so.
* Documentation provides examples through tests, which clearly show both the code and the expected outcome, and which Ratpack prioritized being able to express in a concise manner precisely so that it could be used for documentation purposes.
Could Ratpack have gotten rid of the root ratpack{} closure, the serverConfig and handlers and registry closures? Technically yes, they're not needed to namespace their children. But it would be so much less understandable.
* Convention over configuration: implicit defaults for everything so the hello world example is very simple. If you try to create a new Java project in Gradle, not by copying and pasting or having the IDE autogenerate something for you, you're going to have a bad time. * Whenever you do want to add something, there is a clear place within the structure of the root ratpack{} closure to add it. The port goes under serverConfig, routes go under handlers, etc. You don't set the port under the routing handlers, that would make no sense. Very different than build.gradle which feels like a flat list of unrelated tasks. * Support for both anonymous code and for code which has been factored out. Of course Gradle supports this (factoring out buildscript dependencies instead of a flat build.gradle) but the experience makes you feel like you're playing around with Frankenstein's monster so hardly anybody ever does so. * Documentation provides examples through tests, which clearly show both the code and the expected outcome, and which Ratpack prioritized being able to express in a concise manner precisely so that it could be used for documentation purposes.
Could Ratpack have gotten rid of the root ratpack{} closure, the serverConfig and handlers and registry closures? Technically yes, they're not needed to namespace their children. But it would be so much less understandable.