Leo, I will start adding the base exporterListener to commons after your refactoring. Thanks.
On Tue, Jun 17, 2008 at 1:56 AM, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > Hi > > I'll start to refactor myfaces-commons to the new proposed layout (I'm not > started this yet because it was necessary check the actual state of > converters and validators and solve some related issues): > > myfaces-commons-converters > myfaces-commons-converters12 > myfaces-commons-validators > myfaces-commons-validators12 > myfaces-commons-utils > > It could be good if we have also a: > > myfaces-commons-examples > > As a simple web app with all examples related to myfaces commons stuff > (converters and validators). I is obvious to have this project, so I don't > think this require a vote. > > The list of components that should be moved to this location are this: > > mcc:convertBoolean > mcc:convertDateTime > mcc:convertNumber > mcv:validateCompareTo > mcv:validateCSV > mcv:validateISBN > mcv:validateUrl > mcv:validateCreditCard > mcv:validateEmail > mcv:validateRegExpr > > validateEqual should be deprecated because validateCompareTo it is better > (according to the suggestion of Mike), so this validator should stay on > tomahawk. The rest of converters and validators only be referenced by > tomahawk tld (so myfaces-commons becomes a tomahawk dependency). > > Suggestions are welcome > > regards > > Leonardo Uribe > > On Fri, Jun 13, 2008 at 9:24 PM, Matthias Wessendorf <[EMAIL PROTECTED]> > wrote: > >> On Fri, Jun 6, 2008 at 1:06 PM, Mike Kienenberger <[EMAIL PROTECTED]> >> wrote: >> > I'd recommend not migrating t:validateEqual across to myfaces-commons. >> > t:validateEquals is a special case of t:validateCompareTo, and, if I >> > recall correctly, the code in validateEquals is not as flexible as the >> > code in validateCompareTo. There's no point in maintaining the >> > inferior limited version in the reorganization. >> >> +1 >> >> > >> > On 6/6/08, Leonardo Uribe <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> >> >> On Fri, Jun 6, 2008 at 8:54 AM, Paul Spencer <[EMAIL PROTECTED]> >> wrote: >> >> > Leonardo Uribe wrote: >> >> > >> >> > > >> >> > > Hi >> >> > > >> >> > > I'll start to upgrade component from sandbox to tomahawk. >> >> > > >> >> > > The first item on my list of todos is move this converters and >> >> validators >> >> > > (first check and solve possible issues on JIRA) >> >> > > >> >> > > s:convertBoolean >> >> > > s:convertDateTime >> >> > > s:convertNumber >> >> > > s:validateCompareTo >> >> > > s:validateCSV >> >> > > s:validateISBN >> >> > > s:validateUrl >> >> > > >> >> > > Please note that long time ago this upgrade was approved, but this >> was >> >> not >> >> > > applied due to code generation discussion. >> >> > > >> >> >> <file:///C:/GSOC/workspace/tomahawk-compgen/oldsandbox-site/tlddoc/s/validateUrl.html> >> >> > > >> >> > > >> >> > > Actually on tomahawk exists this validators: >> >> > > >> >> > > t:validateCreditCard >> >> > > t:validateEmail >> >> > > t:validateEqual >> >> > > t:validateRegExpr >> >> > > >> >> > > The idea is that all this converters and validators be on >> >> myfaces-commons. >> >> > > But originally tomahawk is 1.1 compatible, and there was comments >> about >> >> > > commons should have 1.1 and 1.2 converters and validators. If this >> is >> >> true, >> >> > > tomahawk should refer myfaces commons converters and validators on >> its >> >> tld, >> >> > > and have dependecies to commons (if false this is valid only for >> 1.2). >> >> > > >> >> > > >> >> > >> >> > +1 for true. The thought of maintaining 2 sets of converts/valdiators >> is >> >> unnerving. >> >> > >> >> > >> >> > >> >> > > The new unpack plugin allow us to manage this issues more easily, >> >> enforcing >> >> > > just the necessary files to maintain. >> >> > > >> >> > > In order to be consistent with this intentions my first approach >> would >> >> be: >> >> > > >> >> > > 1. Use this layout for myfaces-commons: >> >> > > >> >> > > myfaces-commons-converters >> >> > > myfaces-commons-converters12 >> >> > > myfaces-commons-validators >> >> > > myfaces-commons-validators12 >> >> > > myfaces-commons-utils >> >> > > >> >> > > 2. Use myfaces-builder-plugin for this stuff. >> >> > > >> >> > > 3. Refer converters and validator from commons to tomahawk tld (the >> >> > > intention is avoid changes on existing applications). >> >> > > >> >> > > >> >> > I suggest deprecating the existing converters/validators. >> >> > >> >> >> >> Good idea but needs some concensus about this. Deprecate means do not >> >> exclude it but refer the users to myfaces commons. >> >> >> >> > >> >> > >> >> > > Suggestions are welcome >> >> > > >> >> > > >> >> > >> >> > o What is the impact on the other components, i.e. >> Trinidad/Tobago/...? >> >> > >> >> >> >> no impact, myfaces commons does not have any release yet and does not >> have >> >> dependencies with anything (the idea of this discussion is organize >> this >> >> stuff and make a release of this!). >> >> >> >> > >> >> > o Is this to be included in Tomahawk 1.1.7? >> >> > >> >> >> >> yes >> >> > >> >> > o How long do you expect this to take, i.e. days/weeks/months/... ? >> >> > (I am only asking to set expectation on release schedules) >> >> > >> >> >> >> days, at max weeks >> >> >> >> > >> >> > o Where is the "new unpack plugin" documented? >> >> > >> >> >> >> >> http://myfaces.apache.org/build-tools/plugins/myfaces-builder-plugin/unpack-mojo.html >> >> >> >> There is more doc on the source code (the site has not been updated, >> but >> >> this doc is fine). This is a work in progress. >> >> >> >> >> >> > >> >> > >> >> > > regards >> >> > > >> >> > > Leonardo Uribe >> >> > > >> >> > > >> >> > >> >> > >> >> > Paul Spencer >> >> > >> >> >> >> >> > >> >> >> >> -- >> Matthias Wessendorf >> >> further stuff: >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> mail: matzew-at-apache-dot-org >> > > -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
