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 >
