And by the way, better remember that there will soon be a JSF2.0
branch..
On Tue, 2008-06-17 at 12:57 -0500, Leonardo Uribe wrote:
> 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
> >>> >
> >>> >
> >>
> >>
> >
>
>
