myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From simon <simon.kitch...@chello.at>
Subject Re: [myfaces commons] discussion about reorganization of this project is required!
Date Tue, 17 Jun 2008 18:07:33 GMT
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
> <andrew.rw.robinson@gmail.com> 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
>         
>         <andrew.rw.robinson@gmail.com> 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
>         <lu4242@gmail.com> wrote:
>         >>
>         >>
>         >> On Mon, Jun 16, 2008 at 6:16 PM, Andrew Robinson
>         >> <andrew.rw.robinson@gmail.com> 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
>         <lu4242@gmail.com> 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
>         <matzew@apache.org>
>         >>> > wrote:
>         >>> >>
>         >>> >> On Fri, Jun 6, 2008 at 1:06 PM, Mike Kienenberger
>         <mkienenb@gmail.com>
>         >>> >> 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 <lu4242@gmail.com>
wrote:
>         >>> >> >>
>         >>> >> >>
>         >>> >> >>
>         >>> >> >> On Fri, Jun 6, 2008 at 8:54 AM, Paul Spencer
>         <paulsp@apache.org>
>         >>> >> >> 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
>         >>> >
>         >>> >
>         >>
>         >>
>         >
>         
> 


Mime
View raw message