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
