Package, deploy and install subtemplates independently

[aalmiray]

Based on the following use case: the griffon-mybatis-plugin requires 2 additional configuration files to work, Datasource.groovy and Mybatis.groovy. Additionally, domain classes and mapper files should be provided. All of these files follow a standard structure, so it makes sense to create them using templates.

The thing is that this plugin is applied to a project that has been already initialized using a different lazybones template (griffon-swing-java for example). You may also use this plugin with different toolkit/language combinations, thus packaging its templates with the griffon templates makes no sense.

What if subtemplates could be packaged and deployed in a standalone fashion? Installing a subtemplate would be a matter of locating the zip in a configured repo, download it and place it under $project/.lazybones. Thus means the "install-subtemplate" command (suggested name, change it if too cheesy) will work successfully only when invoked inside a project that was initialized using Lazybones (check can be performed by testing for the presence of the .lazybones directory).

[pledbrook]

Sub templates are structurally no different to normal ones. The key difference is that the generate command doesn't automatically unpack the template in the project directory and the context/environment for the post-install script is different. That means a template could act as a normal one or a sub-template depending on how it's activated.

I think there's no issue with hosting sub-templates in the same way as normal templates. The question then becomes how to ensure that pure sub-templates (ones that can't work effectively with create) are ignored by create, list, and info. An alternative repository is an option, but that means extra work for template authors and you'd have to add the extra repositories to the user's Lazybones configuration.

I see a couple of solutions:

1. Use a naming convention (as already happens during the build) to identify and filter out pure sub-templates. Note that dual-use templates wouldn't match the naming convention but could still be installed as sub-templates.
2. Double down on Bintray and use attributes to identify pure sub-templates.

At this point, I prefer 1 simply because I think it would require less work and is consistent with the behaviour of the Gradle plugin. On the downside, authors may dislike having to prefix template names with subtmpl-.

[aalmiray]

I prefer option 1 too as it doesn't tie templates to an specific repository option.

[aalmiray]

The following questions and issues arose during the implementation of #147:

• do we list remote sub-templates? (I sure hope so)
• should the download command place the sub-templates into the local .lazybones dir only?
• if sub-templates are cached globally ($USER_HOME/.lazybones/sub-templates) they should be listed by the list command too.
• caching of sub-templates must be made explicitly, e.g lazybones install foo-subtemplate (local) vs. lazybones install foo-subtemplate --cache.
• is it worth changing the subtemplate naming pattern to <name>-subtemplate-<version>.zip ?
• applying a sub-template follows this workflow:
  • match local subtemplate first
  • match global subtemplate second
  • fail if no match