Composite templates

[aalmiray]

The use case is for an #opendolphin project where the client portion may be a Griffon project and the server side may be a Spring Boot project. It makes no sense for the opendolphin project to duplicate all options provided by those other templates.

What if there was a "master" template (opendolphin) that creates its own project structure, then delegates to the dependent templates (griffon-- and spring-actuator-boot for example). This feature may be related to lazybones' ability to be embedded (with itself in this case as it seems).

[pledbrook]

So would the Griffon and Spring Boot parts not be separate sub-projects? Regardless, the current workaround is for the README of the OpenDolphin template to specify the commands that the user should run afterwards to create the appropriate Griffon and Spring Boot parts.

One option that could work is to add a method on LazybonesScript that allows one template to install another.

[aalmiray]

Sort of. Both Griffon and Spring Boot projects are supposed to be subprojects of the overall opendolphin projects. The current workflow would be

• create opendolphin multi project build using opendolphin template
• cd client; create griffon project
• cd server; create spring-boot project
• manually edit root build.gradle, settings.gradle and children gradle.properties to wire things up

I'd prefer if most of those steps were to be automated

[pledbrook]

Hmmm...would that last step require programmatic changes to source files after they've been generated? Or would the wiring happen through straightforward parameterisation, i.e. variable substitution into template files at project creation time?

[aalmiray]

Most likely after generation of subproject files. This means the root template must remain in control and be able to perform additional tasks after delegating to other templates. thus branching out to delegate templates cannot be a terminal operation.

[pledbrook]

I feel that issue #141 is the solution to this particular problem.