Hi Leonardo, I am of a contrary opinion to Matthias on the checkin issue - if it helps the developer, the generated source-code can and should be checked in. However, it is necessary that the files are re-generated on every build (so we do not get out of sync between file and configuration).
I see two possibilities for integrating the generated classes with the changes by the developer: 1) we do an abstract component base class, very clean, however, it will not work for MyFaces-API 2) we generate code between markers only, let the rest to be edited by the developer - this will also work with the API, but is less clean. In any case - the template approach is really where I dislike the current maven-faces-plugin-approach, this really sucks and any of the two options above is better. I personally think we can go with option 1 only - there are not so many API classes, and changes in the API are not ocurring too often. If there is more time left, we can think about optionally implementing 2 as well. Could the Trinidad team live with option 1, even though the generated files would then be checked in? regards, Martin On 1/30/08, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > To summarize: > > The objective is to look if we can generate component, tag, > faces-config and facelets files using > a better approach than the actual behavior of myfaces-faces plugin. > > > The full idea could be this: > > > > - Create an abstract component class that contains all info. > > - Create some files where we can get the additional info. > > - Generate a component class that extends from this abstract class. > > - Generate tag, add info to faces-config and tld based on this info. > > > > This suppose a hard work but this approach could be easier than the > > actual behavior. > > This idea could be a possible way to avoid xml files and use abstract > component classes > and annotations like Mario suggested. > > > For sure, I thought we can generate the stuff and then commit the > > generated files, so no need to regenerate for each build, just when > > something in the component config changed. > > > Yep, this just works nicely if we go the abstract component route, no? > else you'll lose all changes you applied on the generated code. > > If we can use abstract component classes with annotations, It is > possible that we can > avoid template classes, because all custom code should be on the > abstract component class. > > > > > IMO, the best solution is where the code checked in to svn *compiles*. > > IDE auto-completion, refactoring, all the other tools that work only with > > *real* code will then be usable again. > > > > > > Ok, why not have the generated base-classes in the source of your compiler? > > If you redirect the generated classes to src/main/java, you have this. > > regards > > Leonardo Uribe > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
