Please see here: http://www.nabble.com/-VOTE--Commons-API-JSF-1.2-only-tp14178115p14180119.html
The consensus was to have commons be JSF 1.2 and a separate branch for JSF 1.1 if desired. Therefore, we should place the 1.1 code in a separate location and the main trunk folders should be JSF 1.2 only. Here was the result vote for JSF 1.2 being the trunk: Vote summary +1: Andrew Robinson Mike Kienenberger Simon Lessard Bruno Aranda Cagatay Civici Grant Smith Mario Ivankovits Scott O'Bryan Paul Spencer -0.9: Volker Weber (not official vote) Bernd Bohmann (was -1, but then got a "I'm fine if we are starting with 1.2 only" response) In keeping with the Apache process the vote should be honored and JSF 1.1 folders should not included in the trunk. On Tue, Jun 17, 2008 at 6:35 AM, Andrew Robinson <[EMAIL PROTECTED]> wrote: > 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 >>> > >>> > >> >> >
