Niclas Hedhman a écrit : > Gang, > After the presentation in Romania, one of the feedbacks received was that > it is too hard to get going with Qi4j. Not only does it require quite a > steep learning curve to grasp Qi4j itself, but it is tedious to set up a > working build for a new project. > > So, I want to create something similar to Maven Archetypes, but with much > better understanding of Qi4j structures. > > I have created a branch for this; Gradle_archetype_toolchain > Name was set before I realize what I want to do, but Gradle will be the > first supported build system, but I think at least Maven should also be > supported, and possibly be able to create Eclipse Workspaces and IntelliJ > projects as well. > > Problem domain; > + Support Pre-packaged application structures, i.e. templating > + Support creation/removal of all Qi4j primary types, Application, Layer, > Module, Composites > + Support weaving in custom code, so generation can occur more than once. > + Support generation to many different build tools. > > Solution domain; > * Strong domain model, which is kept in an entity store and modified > interactively or via scripting > * Set of commands for manipulating the model > * The entire entity store can be used as a "template" for new projects > * Generators will use the model and generate the structures > * Commands are also used to start generation > > Example Use-case 1 > Developer Alex want to use Qi4j for a RESTful server application. He isues > the 'create-project' command and selects the 'rest-server' application > type, and the tool creates a operational skeleton application that serves a > 'Hello, Zest' response from http://localhost:8080/ > > > WDYT? I think this is a good idea.
>From a community point of view, it would be good to both support few official archetypes and allow easy creation/distribution/usage of others from outside the Apache Zest project. > + Support weaving in custom code, so generation can occur more than once. For me that's a tricky part. But maybe you have something in mind? Sandro Martini a écrit : > What do you think on implementing these features with Gradle plugins ? > Just for info, Grails 3 has been rewritten and all developer-related > features are now on top of Gradle (with custom gradle plugins, to make > available shell commands and other developer-related stuff) so maybe > something like this could be good even here ... If we wrap all this in a simple facade api then we can have command lines, gradle/maven/whatever plugins and even start thinking about IDE plugins. Jiri's and Michael's Tower concept looks more like build/assembly automation focused, it seems we'll learn more about it soon :) My 2 cents, /Paul
