Hi Bernd, On Thu, 2008-03-13 at 03:31 -0700, Bernd Bohmann (JIRA) wrote: > Generate Components, JSP Tags from annotations
Well, it seems like rewriting build systems is the trendy topic this month :-) I wondered why you were smiling this afternoon while tapping away on your keyboard; now I know. As there are now several people (you, myself, leonardo) working on new build ideas, perhaps we (and anyone else interested) should pool our ideas together? Do you perhaps have any design documents describing how your new build system works? I have had an initial look at the code, but am not currently completely clear how things fit together. Of course I haven't had any time to write up docs either; and I'm still experimenting (committing on a branch, rather than committing to trunk as you are doing). The commits you made touch a lot of code; it seems to me that they include patches for several unrelated things including adding ajax support, making UIPanel a NamingContainer, etc. Is this right? I see some of the patch is removing saveState/restoreState methods, which I presume is because these methods will be auto-generated later. But I don't see removal of any Tag classes, which I would have expected given the title of this commit. Is this coming later or have I misunderstood something? Here's some points/questions I have after reading the code: (1) You appear to be using ".stg" files as templates for code generation. Does this stand for "org.antlr.stringtemplate.StringTemplateGroup"? http://www.stringtemplate.org/doc/api/org/antlr/stringtemplate/StringTemplateGroup.html Why did you choose this as a templating engine? Is it better than Velocity or xslt for this task, or because you are more familiar with it? (2) The CreateComponentAnnotationVisitor class appears to be using the StringTemplateGroup files to generate output. The CreateComponentAnnotationProcessor class first "visits" each annotated object, effectively gathering needed metadata. Then CreateComponentAnnotationVisitor.process is then invoked to iterate over the gathered data and apply it to the template. The createRenderer method generates a renderer java file, and the createTag method generates a tag java file. (3) You appear to be using the info from the annotations pretty directly to generate the artifacts. Tag annotations contain the information used to generate Tag classes etc. This is really not very different from what I would like to achieve with the work I am doing. And really not too different from what the current trinidad-derived build process currently does either. The issue I have is that the trinidad-based approach is very tightly coupled to the concept that the input is an xml file in almost-faces-config.xml format. Sadly, I just cannot plug into it to provide an alternative way of building metadata. And it looks to me like your code is also very tightly coupled to the concepts of the sun APT processor, and again cannot be extended to allow other ways of building the metadata. What I would like to see (and am working towards) is a neutral format in the middle (see ComponentModel, RendererModel, etc classes). Then anything can populate this model (apt annotations, xml or doclet-tags). The code just implements ModelBuilder and then fetches the data however it wants. And equally I hope to have a simple ModelProcessor interface. Then multiple different implementations of that can exist, eg one that uses .stg files to generate classes, or one that uses velocity to generate facelets-taglib.xml files, or ... Of course the common metadata representation would need to be carefully chosen. For example, I would hope to avoid explicitly modelling "tag" information; I regard that as something that can be derived from information about the hand-written classes rather than something that classes should explicitly declare. Therefore I would not personally have a TagModel class. However that can certainly be debated, and there is room for compromise I'm sure. Unfortunately, I cannot see how to apply the Tobago approach to myfaces core, tomahawk, trinidad etc. The newly committed tobago code is very tightly tuned to the needs of tobago at the moment. And in addition, I'm really not convinced about the use of APT. But with the architecture I described above, that doesn't matter. Different front-ends (apt, qdox, xml) can be used while still the rest. Is this an approach that you think would be beneficial to Tobago, or would you prefer to keep tobago's build solution separate and tuned exclusively for Tobago? Regards, Simon
