Hi, On Jan 30, 2008 8:46 PM, Martin Marinschek <[EMAIL PROTECTED]> wrote: > 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
I lost the context a bit, during cutting text from reply emails. I have to search for this original email. I get it like this: -stupid abstract class is generated -logic (like the one from the templates) comes to compoent class, that extends the stupid guy ? why check in the stupid guy ? > 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? I don't know, yet. If 101% is working fine, perhaps. If 99% is working, for sure not :-) would be good to have a wiki, that start to document the "proposal" -M > > 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 > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
