Ahhh, Ok, thanks for the information. That's right. If exists a vote, no way.
Checking the svn there is a jsf 1.1 branch here: http://svn.apache.org/repos/asf/myfaces/commons/branches/jsf_11/ And the trunk is the jsf 1.2 branch: http://svn.apache.org/repos/asf/myfaces/commons/trunk/ But if this is the case I don't feel very good using myfaces builder plugin unpack goal. There are about 12 or more files to be shared, so it's not a big deal maintaining as two trunks. Actually the version number of commons is 0.0.1-SNAPSHOT. It should be 1.2.0-SNAPSHOT, for keep simple the identification of which version is compatible. According to this layout, tomahawk12 should depends of myfaces-commons-1.2.0-SNAPSHOT, but tomahawk11 do not depends with 1.1 commons branch. regards Leonardo Uribe On Tue, Jun 17, 2008 at 12:10 PM, Andrew Robinson < [EMAIL PROTECTED]> wrote: > 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 > >>> > > >>> > > >> > >> > > >
