On Tue, Feb 5, 2013 at 9:30 AM, Hans Dockter <[email protected]>wrote:
> We had a couple of discussions around this in the past. Tim Berglund > proposed and started to work on a Github based templating mechanism 6 > months ago or so. We should try to gather the use cases and move forward > from there. > > Here is what the Maven archetype plugin is providing: > > - > archetype:generate<http://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html> > creates > a Maven project from an archetype: asks the user to choose an archetype > from the archetype catalog, and retrieves it from the remote repository. > Once retrieved, it is processed to create a working Maven project. > - > archetype:create-from-project<http://maven.apache.org/archetype/maven-archetype-plugin/create-from-project-mojo.html> > creates > an archetype from an existing project. > - > archetype:crawl<http://maven.apache.org/archetype/maven-archetype-plugin/crawl-mojo.html> > search > a repository for archetypes and updates a catalog. > > The archetypes are obviously parameterized and you can fill in the > parameters either from a console or from a properties file. The archetype > has input files which live in a jar. In the metadata file for a specific > archetype you then basically specify a bunch of copy operations where the > files of the jar are copied and the tokens in those files are replaced with > the parameters. The result is the template project. > > - You might have large binaries as part of your template where I think > Github is not a good place to store them. I easily see enterprise scenarios > where this is the case. > - We want to anyhow improve the generic Gradle configuration mechanisms, > e.g. make it very easy to specify that properties are retrieved from the > console. > - With auto-apply and improved generic property handling that might take > us a long way to a templating solution. A template would be just a Gradle > plugin with some resources. The only thing we would additionally need is > some metadata per template for building a catalog. > > 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. Hans > The cool thing with the above solution is that we could also somehow > integrate those template plugins with our language plugins. The language > plugins for example define many of the conventions that make up the project > template for this language. You don't want to define them a second time in > the template but rather ask the language plugin for them. >
