On Dec 5, 2007 10:40 AM, Volker Weber <[EMAIL PROTECTED]> wrote: > Hi, > > why should a jsf1.1 extension library require java1.4 support?
+1 > > tobago requires java1.5. Trinidad is also requiring Java5. like in Tobago land, we have a retro-weaver profile in the pom. > > it is totally fine running jsf 1.1 on a java 1.6 environment. > > I don't know the details of jsf 1.2 spec, but it seems to me that the > api for javax.faces.convert.Converter is the same, so why must we > differ between 1.1 and 1.2 in the commons-converter? Same for API is same. the "impl" is little different; ConverterTag is deprecated; good folks would use ConverterELTag (same for validator) > 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
