On Thu, 2008-04-03 at 20:29 -0400, Kito D. Mann wrote: > Thanks for the explanation, Leonardo. I’m guessing that the Trinidad > plugin isn’t generic enough to be used outside of Trinidad?
No, the Trinidad plugin could be used elsewhere. In fact it has been used to build the myfaces-core 1.2.0 and 1.2.2 releases. Work was then done to rename it to "myfaces-faces-plugin" just for tidiness (not released yet, but probably "late beta" state as it's mostly a rename of existing code). Some work was then done to start converting Tomahawk to use this (beta) plugin. But then there was a lot of discussion on the dev list; some people (particularly me) did not think the trinidad-plugin approach was very elegant, and did not want it to spread across the whole set of myfaces projects. You can see the discussion in the mail archives, and more info here: http://wiki.apache.org/myfaces/MyfacesBuilderPlugin As there was reasonable support for an alternative "annotation-driven" approach, I created a prototype implementation. People seem reasonably happy with the approach, and Leonardo is now doing some great work extending the initial code (in particular, adding the "back end" part). This new plugin is 95% new code, with just a little bit borrowed from the trinidad plugin project. At some point I guess there will need to be an official vote on which plugin will be used for myfaces core 1.1, core1.2 and tomahawk. *If* the "myfaces-builder-plugin" is chosen, then the Trinidad team will need to decide whether to stay with their existing plugin or change over. Tobago has its own plugin for similar purposes; their approach is much more like the myfaces-builder-plugin proposal than the trinidad-plugin approach. Again, it would be up to the Tobago team to decide whether to try to join forces or not. Regards, Simon > > From: Leonardo Uribe [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 03, 2008 7:50 PM > To: MyFaces Development; [EMAIL PROTECTED] > Subject: Re: MyfacesBuilderPlugin > > > > > > > On Thu, Apr 3, 2008 at 11:31 AM, Kito D. Mann <[EMAIL PROTECTED]> > wrote: > > Is the MyfacesBuilderPlugin completely separate from the Trinidad > Maven Plugins? > > > > Actually is a branch developed inside build-tools. There is no > official vote yet about if this plugin will be used on trinidad, since > myfaces-faces-plugin (or maven-faces-plugin on trinidadbuild) are > working and works very well. Theorically, after a votation this plugin > could be used on myfaces and tomahawk. > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Kito D. Mann - Author, JavaServer Faces in Action > http://www.virtua.com - JSF/Java EE consulting, training, and > mentoring > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and > info > phone: +1 203-653-2989 > fax: +1 203-653-2988 > > > > From: Leonardo Uribe [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 02, 2008 9:53 PM > To: MyFaces Development > Subject: Re: MyfacesBuilderPlugin > > > > > Hi > > I have a design question. I'm working on generate component > tag classes using velocity. > > In this part it is common to found some situations when you > need utility methods. There are several methods > to do this: > > 1) Implementing this methods on a java class, and use the > following code using a macro file on inside the template: > > ## [[[[[ Setting Utility Classes to use ]]]]] > ## > #set($utils = > $classes.forName("org.apache.commons.lang.StringUtils").newInstance()) > > In this case, we can copy > org.apache.myfaces.buildtools.maven2.plugin.faces.util.Util > form myfaces-faces-plugin and use it > inside the templates. like this > > $utils.lowerCase($field.getAttributeValue("name")) > > 2) Use a file to create velocity macros and implement this > here. Inside we need to use StringUtils like in (1), but from > the point of view of the template designer, He/she doesn't see > this. > > 3) Create methods on each Model and XXXMeta. Sometimes this is > unavoidable (like getting the properties from a component) and > is more clean. For example: > > package ${component.tagPackage}; > > public class ${component.tagName}{ > > #foreach( $property in ${component.propertyList} ) > //getter and setter methods > #end > } > > This two methods (getTagPackage and getTagName and derived > properties of tagClass). > > What option could be better? If no suggestions, I will go for > option 1 and 3. > > regards > > Leonardo Uribe > > On Wed, Apr 2, 2008 at 3:07 PM, Leonardo Uribe > <[EMAIL PROTECTED]> wrote: > > > > On Wed, Apr 2, 2008 at 2:49 AM, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > > > > I'm not quite clear what your description above means. I think > we are > talking about the same thing, but just to be clear this is how > I would > see it working: > > == for goal build-metadata: > > start with an empty model > for each jarfile containing a META-INF/myfaces-metadata.xml > file > read that myfaces-metadata.xml file > add the resulting objects into the model[1] > run the ModelBuilder for the current project, which adds more > objects to > the model > save the model into META-INF/myfaces-metadata.xml in the > current project > > An alternative would be to do the merging just at the xml > level, then > build a model from the resulting merged xml file. That also > seems > reasonable. > > == for other goals (eg generate faces.xml, generate tag > classes): > start with an empty model > read META-INF/myfaces-metadata.xml for the current project > only > add the resulting objects to the model > pass the model object to the appropriate generator class[3] > > [1] Hmm..might need to somehow detect and handle duplicate > data. > > > > Yes, duplicated data is the problem. > > > > > In particular, tomahawk will depend on both > myfaces-api and > myfaces-impl. But the META-INF/myfaces-metadata.xml > file will have a > copy of all the data from the myfaces-metadata.xml > contained in > myfaces-api jarfile. So if *all* jars in the classpath > are processed, > the data from myfaces-api.jar will be processed twice. > > > Tomahawk sandbox depends on tomahawk core and myfaces api. > Tomahawk > core depends of myfaces api only (because it should be > compatible with jsf ri, no > impl dependences should be present). So the problem ilustrated > here raises on sandbox. > > > > > Options I see are > (a) don't worry; the data will just be identical > > > Right. > > > > > (b) check that if a model object is being overwritten, > the new data is > identical > (c) have the plugin configured with an explicit list > of jars to process > metadata from. Then in the pom it must be configured > so that > myfaces-impl is processed and myfaces-api is ignored. > Then make it an > error for the same model object to be defined twice. > (d) have a myfaces-metadata.xml file *not* include > data inherited from > parent projects. That's cleaner in a way, but means > that when processing > other goals we cannot just load the metadata file from > the local project > but need to merge in all the ancestor projects too. > Ecch. > (e) in the myfaces-metadata.xml, somehow mark entries > with the jarfile > they came from. > > > Really, the option that likes me more is (e). One option to do > this is create a > modelId parameter (for components and other stuff inside > Model), assigned on the pom as a param. > This param can be used in several situations: > > (a) In tomahawk core, we need to generate a hierarchy of tag > classes for myfaces api components. > >From this classes, tomahawk tag classes inherit. Note we need > to change package for myfaces > api component tag classes group (only html components). One > option is give the possibility to apply a XSTL > filter to myfaces-metadata.xml that do this. > (b) Specify that some goal should be applied to a specific > group of components, identified with a modelId. > > > > I will test this ideas and see what happen. > > regards > > Leonardo Uribe > > > > > > > >
