On Feb 5, 2013, at 7:24 AM, Hans Dockter <[email protected]> wrote:
> Just to be more specific: > > - Auto-applying a plugin will be our retrieval mechanism > - Our upcoming plugin discovery/directory mechanism will provide the template > catalog. > - Our generic enhanced property mechanism (e.g. retrieve properties from > console, file, keystore, swing UI, ...) will define the parameters of the > template. > - Our copy task would be the templating mechanism. > - Our upcoming pluging plugin will make it very easy to publish a new > template plugin or any other plugin. > > This will give simplicity, utmost power and flexibility and a low learning > curve to the templating mechanism. And we don't need to do _anything_ > template specific. 1. Han's email of clarification makes sense and does bring clarity. This is great stuff to look forward to. 2. Luke… thanks for sharing the g8 approach… I like it and will likely use it for workshop setups in the future. 3. Having the maven like archetype stuff will no doubt add value… however I feel like it falls short… the challenge is someone has to have a complete picture of what they want in order to jump start to the right archetype… so… if you are looking to start a Spring MVC project, with Sitemesh, with Gradle, with Spock, etc. then you need to generate from the closest matching template. What would be better (and more challenging to say the least) is to add templates features to your project. so you gen a starting gradle java web project… then you decide.. you know this would be better as a Spring MVC project… so you "apply" an additional templates feature. then you are like… I really would like to add site mesh to this…. and so on. What I see people doing is… generating out to what they think they want… say Spring MVC and Gradle. then they realize they would really like sitemesh or spock… so they generate another project using an appropriate template, then copy and paste what they want to their primary project. just thoughts… ken
