Leonardo Uribe schrieb: > > On Wed, Apr 16, 2008 at 12:33 PM, Mike Kienenberger > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > Another alternative to option 1 is to #parse($fileName) or > #include($fileName). > You can specify filename externally. This is probably the best > solution so long as the contents of the file included can be included > "as-is". > > > The only problem with this solution is that you cannot do something > like this: > > faces-config-base.xml > > <faces-config> > <application> > <!-- custom code --> > </application> > </faces-config> > > and include only the application part (what I want because is more > clear for the developer). I have implemented option 1, anyway, using > #parse or #include is also available. Yes, the original plugin could take a full config file, and extract the children of the document root for merging into the final result. That was a little cleaner. I don't know enough about velocity to know if there is a way to achieve that.
I guess a builder-plugin utility class could be written to take a filename as input, and return the content of the root element as a string. Then that could be called from the velocity template. > > Right now generation of faces-config, .tld (or any config file you > want), component classes and tag classes works. Now I'm doing some big > tests (use it in myfaces 1.1 and generate faces-config, .tld, and tag > classes, then probe it on tomahawk generating all the stuff). > > The only part that I want to enhance of this plugin is that is very > common that component generation can be done fully (an example is > javax.faces.component.html classes minus HtmlDataTable). The question > is how to add the definition of this component without creating a > .java file and annotations or doclets to do it (maybe do a part that > use groovy .....). My first idea is create a package scope .java class > like _HtmlCommandButton and add the needed stuff, but this file is > included by the compiler to the jar (does not a big problem, since has > not side effects). So I'm looking a cleaner way to do this. > > suggestions are welcome I'm ok with package-scoped classes for this case. I think it is clear to developers what is going on, which is more important than saving a few kb in the resulting jar. But of course the maven-jar-plugin could be configured to exclude these empty classes when building the jarfile if this is important. In addition, if javadoc is generated with package-scope enabled, then we get some helpful documentation about what is going on. For java1.5, it is possible to write a "package.java" file. This is intended to replace "package.html"; it allows package docs to be written as javadoc, rather than an html fragment. It also allows package-scope annotations to be added, which can be introspected at runtime. This would be a possible place to put annotations that don't have a real class to be attached to. Of course this does result in another .class file in the jar, but that didn't seem to bother Java's architects. Does the meta-data for these auto-generated components really have *no* properties that can be derived from introspection of a java class? One reason for the annotation-based approach is that properties can be determined by analysing code rather than simply accepting string data entered by the user. That allows at least some of the config to be checked by the compiler, supported during refactoring, etc. If a project uses the "real" annotations (rather than javadoc annotations) then it becomes even more useful to have this info expressed via .java files (rather than a .xml config file or similar). Regards, Simon
