That looks good. On Dec 5, 2007 6:16 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > Yeah I agree. > > So to summarize here is what I'm understanding from people: > > Common Converters > * JDK 1.5 > * Should work on either JSF 1.1 & JSF 1.2 > > Common Validators > * JDK 1.5 > * Should work on either JSF 1.1 & JSF 1.2 > > Common Utilities > * JDK 1.5 > * Should work on either JSF 1.1 & JSF 1.2 > > Common Utilities 1.2 > * JDK 1.5 > * JSF 1.2+ > > Is that basically what we're looking at? > > Scott > > > Matthias Wessendorf wrote: > > yes, some APIs have changed; > > > > my point was just, that for "trivial" things (like the > > validators/converters), > > the API is same, the generated artifacts are *dependent* to the particular > > Faces version. > > > > -M > > > > On Dec 5, 2007 5:34 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > > > >> I've also noticed that things with the externalContext also do not work > >> properly because the ExternalContext api's have changed. I suspect > >> anything that relies on the new functionality in externalContext or any > >> of the other API's for that matter will have trouble porting back. > >> > >> Scott > >> > >> > >> Matthias Wessendorf wrote: > >> > >>> 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
