Hi Mark et al, thank you for approaching the topic from the requirements side, this is needed to engineer poweful features for ArgoUML! I have not much time in the next weeks, but I can contribute with some hints on the (opposite?) technical side: we have worked with Velocity already. This template engine is also used by AndroMDA. Since we use Antlr, we are also aware of StringTemplate, another template engine. But with velocity, I know of at least two working examples that generate Java code from templates+model, both of them as ArgoUML modules:
* http://argouml-modulegenerator.tigris.org/ (my baby) * a template base Java generator by Andreas Rückert (I have the sources, but will not give them away without talking to him) Maybe it's too early to talk about the concrete libs to use, but I just wanted to let you know that there's some experience. Just go aheas with the concept! (OK, I'm a little bit worried who will later implement it, do you think someone will volunteer?) Regards, Thomas -------- Original-Nachricht -------- > Datum: Thu, 1 Sep 2011 07:49:50 -0700 > Von: Mark Fortner <[email protected]> > An: [email protected] > Betreff: Re: [argouml-dev] Templated Code Generation > Hi Linus, > It should be pretty easy to have template-specific file naming patterns. > I've started creating a model based on our discussions and I'll see if I > can load that onto the wiki this weekend. > > Mark > > > On Thu, Sep 1, 2011 at 7:43 AM, Linus Tolke Tigris <[email protected]> > wrote: > > > *Hello Mark! > > * > > * > > * > > *In my current project we have the header files and c++ files in the > same > > directory. In other projects I have seen them in two different > directories. > > * > > * > > * > > * /Linus* > > > > > > Den onsdagen den 31:e augusti 2011 skrev Mark Fortner: > > > > Hi Linus, > >> In ArgoPrint I have a TemplateMetaFile object which contains things > like a > >> file naming template. We could use a similar approach for code > generation > >> templates. > >> > >> It's been a while since I've written any C++. If you're generating > code > >> do you typically put the headers in one directory and the > implementations in > >> another directory? Perhaps splitting things up into an API and an SPI > >> directory? > >> > >> Mark > >> > >> > >> On Wed, Aug 31, 2011 at 11:03 AM, Linus Tolke Tigris > <[email protected]>wrote: > >> > >>> Great Mark! > >>> > >>> For filenames, I am also thinking C++ where each class has a .h file > and > >>> a .cpp file i.e. two separate templates or a single template that > generates > >>> two files. I want to see this to be determined among the set of > templates. I > >>> assume this is easily fixed. > >>> > >>> I agree that it is best to put reverse engineering aside. It is great > >>> that we state this up front. It simplifies things a lot. > >>> > >>> /Linus > >>> > >>> > >>> 2011/8/31 Mark Fortner <[email protected]> > >>> > >>>> > >>>> Hi Linus, > >>>> I'll definitely move the results of the discussion into a wiki page. > >>>> > >>>> > >>>>> I miss two things but it might be my lack of knowledge of what is > >>>>> included in the template engines. > >>>>> > >>>>> - In the template it shall be able to express filename or > filenames > >>>>> to be used. > >>>>> > >>>>> I don't know if the template itself should know about the filename, > but > >>>> you can definitely pass a file name to the templating engine. There > are two > >>>> use cases here: > >>>> > >>>> > >>>> - *Straight template-based generation*: you have a class, and an > >>>> output directory, and a template -- the template engine uses this > data to > >>>> determine where what to write and where to write it. Determining > the output > >>>> directory and classname is rather straight-forward: > >>>> > "${outputdir}/${packageName.toPath()}/${className}.${fileExtension}" > >>>> - *Project-based generation*: you have a domain class, a project > >>>> directory, and a template -- the correct directory is determined > based on > >>>> the fact that it's a domain class, it's a Grails project (or some > other > >>>> framework), and we know what the project root directory is. > Something like > >>>> > "${projectRoot}/grails-app/domain/${packageName.toPath()}/${className}.groovy" > >>>> > >>>> > >>>>> - Re-generation, importing manual changes from previously > generated > >>>>> files or reverse engineering. Shall this be addressed? Do the > template > >>>>> engines mentioned address this? > >>>>> > >>>>> In my mental model, language support = reverse engineering + code > >>>> generation, and for the time being, I'd be satisified if we just had > >>>> modifiable templates for code generation. I'm not completely > dissatisfied > >>>> with reveng at the moment, there are just a few bits that are need to > be > >>>> updated to properly support some features in the java language. So > I'd > >>>> rather put reveng to the side for the time being and focus on code > >>>> generation. My personal feeling is that projects that are small and > >>>> well-defined are more likely to be worked on by volunteers with > limited > >>>> available time and we should probably try to keep this as minimal as > >>>> possible. > >>>> > >>>> Mark > >>>> > >>> > >>> > >> > > ------------------------------------------------------ > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2833966 > > To unsubscribe from this discussion, e-mail: > [[email protected]]. > To be allowed to post to the list contact the mailing list moderator, > email: [[email protected]] -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2833991 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
