> the "impl" is little different; > ConverterTag is deprecated; > good folks would use ConverterELTag > (same for validator)
which are generated classes (that depend on a JSF 1.1 TAG or a JSF 1.2 one). Which means that can be done via param (which is now "hard-coded" in the POM). -M > > commons-validator. Also many util classes should be able to work in > > jsf1.1 and jsf1.2 without changes. > > yes "common" helper method, will work > if the are not using things like invokeOnComponet(), for instance > > -M > > > > > > Note: I'm speaking about the application-developer part of commons, > > not of the component/library-developer part. > > > > > > Regards, > > Volker > > > > > > 2007/12/5, Scott O'Bryan <[EMAIL PROTECTED]>: > > > > > Right, I totally agree. The point is that, currently, Tomahawk, Tobago, > > > and Trinidad 1.1 are NOT currently dependent on commons. And > > > introducing support for 1.1 in the commons now would mean that commons > > > would have to support Java 1.4 and JSF 1.1 pretty much forever. > > > > > > My proposal is basically that we leave the current 1.1 compatible > > > renderkits as they are, maybe allowing some common filters and > > > converters depending on what people think is needed. The other commons > > > could then be used as projects tackle 1.2 and the commons could be used > > > to ease and unify that development effort. > > > > > > Scott > > > > > > Paul Spencer wrote: > > > > Scott, > > > > My concern is when components, like Tomahawk, become dependent on JSF > > > > Commons, then they will inherit the dependencies of JSF Commons. If a > > > > component in JSF Commons is not intended to be used with JSF 1.1, or > > > > none of JSF 1.1 components, like Tomahawk, require the commons > > > > component, then I have no objection for a non-JSF 1.1. compliant > > > > dependency. > > > > > > > > Paul Spencer > > > > > > > > Scott O'Bryan wrote: > > > >> Cool, I was hoping we had one. :) Paul, you mind if I ask you some > > > >> questions about this? > > > >> > > > >> I can totally understand the want/need for the converters and > > > >> validators to be ported to 1.1 (and thus need 1.4 support), but what > > > >> about the utilities? Currently Trinidad, Tomahawk, and Tobago > > > >> support JDK 1.1 and therefore their adoption of the common utilities > > > >> would be slow if not non-existant. I know that the logic I'm trying > > > >> to introduce, although it could be used in JSF 1.1 environments, > > > >> really becomes most useful when dealing with JSF 1.2 and the portlet > > > >> bridge. I also wouldn't think that things like unified multi-part > > > >> form processing would be likely to make it into current 1.1 > > > >> renderkits since it would require a lot of code to be rewritten and > > > >> may not be backward compatible. > > > >> > > > >> Scott > > > >> > > > >> Paul Spencer wrote: > > > >>> +1 on JSF 1.2 only > > > >>> +1 on 1.1 support with JDK 1.5 required on both. > > > >>> +1 on 1.1 w/ 1.4 > > > >>> I have projects I support on HP-UX that are currently running > > > >>> JDK 1.4. > > > >>> > > > >>> Paul Spencer > > > >>> > > > >>> Andrew Robinson wrote: > > > >>>> I would go for: > > > >>>> > > > >>>> +1 on JSF 1.2 only > > > >>>> > > > >>>> This is open source, so no one is required to use it and embracing > > > >>>> 1.2 > > > >>>> is only going to help the development community move forward. > > > >>>> > > > >>>> +0.5 on 1.1 support with JDK 1.5 required on both. > > > >>>> > > > >>>> Just because the specification supports 1.4 does mean libraries have > > > >>>> to. JDK 1.5 has been out plenty long enough for companies to adopt > > > >>>> it. > > > >>>> If they cannot adopt it, they should be willing to forgo new > > > >>>> libraries > > > >>>> and functionality > > > >>>> > > > >>>> -1 on 1.1 w/ 1.4 > > > >>>> > > > >>>> This is too much work and will really hold nicer features back (I > > > >>>> also > > > >>>> would have no interest in developing and testing it personally). > > > >>>> > > > >>>> Just my $.02 > > > >>>> > > > >>>> -Andrew > > > >>>> > > > >>>> On Nov 29, 2007 10:06 AM, Matthias Wessendorf <[EMAIL PROTECTED]> > > > >>>> wrote: > > > >>>>> On Nov 29, 2007 5:57 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > > > >>>>>> Hey everyone, > > > >>>>>> > > > >>>>>> I'm going to try to put together a proposal for some items it add > > > >>>>>> to the > > > >>>>>> jsf commons fairly soon for your purusal. First off, however, > > > >>>>>> I'd like > > > >>>>>> some technical information on this project as it may effect how the > > > >>>>>> project is set up. > > > >>>>>> > > > >>>>>> 1. Which version of JSF will be the minimum for this project? > > > >>>>>> One of my > > > >>>>>> proposals involves needing an ExternalContextWrapper and the > > > >>>>>> version of > > > >>>>>> JSF does make a difference. I, personally, would like to see > > > >>>>>> this based > > > >>>>>> off 1.2 but if we need a 1.1 Faces Commons then I would recommend > > > >>>>>> both a > > > >>>>>> 1.1 and a 1.2 branch. > > > >>>>> here we go; > > > >>>>> my understanding is, that 1.1 is a must > > > >>>>> > > > >>>>>> 2. What is the minimum JDK we are going to use for this project. > > > >>>>>> My > > > >>>>>> preference would be J2SE 5 for the build. I could even live with > > > >>>>>> making > > > >>>>>> sure that code can be compiled with J2SE 5 in 1.4 compatibility > > > >>>>>> mode but > > > >>>>>> I think we need to be able to support generics at the very > > > >>>>>> least. Of > > > >>>>>> course if we're basing the commons project off of JSF 1.2, J2SE5 > > > >>>>>> is a > > > >>>>>> no-brainer. :) > > > >>>>> JSF 1.1 => java1.4 > > > >>>>> JSF 1.2 => JDK5 > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> -- > > > >>>>> Matthias Wessendorf > > > >>>>> > > > >>>>> further stuff: > > > >>>>> blog: http://matthiaswessendorf.wordpress.com/ > > > >>>>> sessions: http://www.slideshare.net/mwessendorf > > > >>>>> mail: matzew-at-apache-dot-org > > > >>>>> > > > >>>> > > > >>> > > > >>> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > -- > > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
