BTW, I believe a vote was already taken on commons, and the result was that commons would be JSF 1.2 only with a 1.1 branch if ppl. wanted to create one.
With this in mind, I am strongly -1 for the 1.2 code using 1.1 artifacts. On Mon, Jun 16, 2008 at 5:24 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > > > On Mon, Jun 16, 2008 at 6:16 PM, Andrew Robinson > <[EMAIL PROTECTED]> wrote: >> >> How about moving the JSF version to a folder? >> >> commons-utils/ >> commons-11/myfaces-commons-converters >> commons-11/myfaces-commons-validators >> commons-12/myfaces-commons-converters >> commons-12/myfaces-commons-validators >> >> Just makes for a cleaner structure IMO and makes it look less like 1.2 >> support is the bastard child of JSF 1.1. >> >> If a different name were made, I would suggest 1.2 is the default and >> 1.1 gets the exception as it is now legacy / deprecated. > > Ok, let's use this layout. Only we have to remember that the idea is use > myfaces builder plugin unpack goal to share 1.1 code with 1.2 like in > tomahawk right now, because one objective is reduce the amount of files and > code to be maintained. > >> >> -Andrew >> >> On Mon, Jun 16, 2008 at 4:56 PM, 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 >> > >> > > >
