You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Andrew Robinson <an...@gmail.com> on 2007/12/03 20:40:31 UTC
Re: MyFaces JSF Commons Project
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 <ma...@apache.org> wrote:
> On Nov 29, 2007 5:57 PM, Scott O'Bryan <da...@gmail.com> 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
>
Re: MyFaces JSF Commons Project
Posted by Matthias Wessendorf <ma...@apache.org>.
The current state is not that it is done for JSF 1.1 only.
We just started the two classes with that :-)
The switch to JSF 1.2 is very cheap, since it is via config.
-M
On Dec 3, 2007 8:47 PM, Mike Kienenberger <mk...@gmail.com> wrote:
> If you're going to support 1.1, support 1.4. Otherwise, just stick
> with JSF 1.2.
>
> I know where I do my primary JSF work, the major holdup has been JDK
> 1.5, which was only recently adopted, not JSF 1.2, per se.
>
> I'm personally good with JSF 1.2 only, though, for this new project.
>
>
> On Dec 3, 2007 2:43 PM, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi!
> > > +1 on JSF 1.2 only
> > > +0.5 on 1.1 support with JDK 1.5 required on both.
> > > -1 on 1.1 w/ 1.4
> > >
> > +1 on that view!
> >
> > Ciao,
> > Mario
> >
> >
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: MyFaces JSF Commons Project
Posted by Mike Kienenberger <mk...@gmail.com>.
If you're going to support 1.1, support 1.4. Otherwise, just stick
with JSF 1.2.
I know where I do my primary JSF work, the major holdup has been JDK
1.5, which was only recently adopted, not JSF 1.2, per se.
I'm personally good with JSF 1.2 only, though, for this new project.
On Dec 3, 2007 2:43 PM, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > +1 on JSF 1.2 only
> > +0.5 on 1.1 support with JDK 1.5 required on both.
> > -1 on 1.1 w/ 1.4
> >
> +1 on that view!
>
> Ciao,
> Mario
>
>
Re: MyFaces JSF Commons Project
Posted by Scott O'Bryan <da...@gmail.com>.
+1 for me too. I think the current JSF commons is already set up for
1.1 though...
Scott
Mario Ivankovits wrote:
> Hi!
>> +1 on JSF 1.2 only
>> +0.5 on 1.1 support with JDK 1.5 required on both.
>> -1 on 1.1 w/ 1.4
>>
> +1 on that view!
>
> Ciao,
> Mario
>
>
Re: MyFaces JSF Commons Project
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> +1 on JSF 1.2 only
> +0.5 on 1.1 support with JDK 1.5 required on both.
> -1 on 1.1 w/ 1.4
>
+1 on that view!
Ciao,
Mario
Re: MyFaces JSF Commons Project
Posted by Matthias Wessendorf <ma...@apache.org>.
> 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 <da...@gmail.com>:
> >
> > > 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 <ma...@apache.org>
> > > >>>> wrote:
> > > >>>>> On Nov 29, 2007 5:57 PM, Scott O'Bryan <da...@gmail.com> 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
Re: MyFaces JSF Commons Project
Posted by Matthias Wessendorf <ma...@apache.org>.
That looks good.
On Dec 5, 2007 6:16 PM, Scott O'Bryan <da...@gmail.com> 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 <da...@gmail.com> 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 <v....@inexso.de> 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 <da...@gmail.com>:
> >>>>
> >>>>
> >>>>
> >>>>> 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 <ma...@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On Nov 29, 2007 5:57 PM, Scott O'Bryan <da...@gmail.com> 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
Re: MyFaces JSF Commons Project
Posted by Scott O'Bryan <da...@gmail.com>.
I guess the other option is to take a more segmented approach (like for
configurators) and rate the minimum requirements for each module
separately. But I kind of like the idea of not including a bunch of
different jars if we can help it.
Scott
Scott O'Bryan 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 <da...@gmail.com> 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 <v....@inexso.de> 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 <da...@gmail.com>:
>>>>>
>>>>>
>>>>>
>>>>>> 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
>>>>>>>>>> <ma...@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Nov 29, 2007 5:57 PM, Scott O'Bryan <da...@gmail.com>
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>
>
Re: MyFaces JSF Commons Project
Posted by Scott O'Bryan <da...@gmail.com>.
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 <da...@gmail.com> 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 <v....@inexso.de> 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 <da...@gmail.com>:
>>>>
>>>>
>>>>
>>>>> 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 <ma...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Nov 29, 2007 5:57 PM, Scott O'Bryan <da...@gmail.com> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>
>>>
>>>
>>
>
>
>
>
Re: MyFaces JSF Commons Project
Posted by Matthias Wessendorf <ma...@apache.org>.
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 <da...@gmail.com> 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 <v....@inexso.de> 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 <da...@gmail.com>:
> >>
> >>
> >>> 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 <ma...@apache.org>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> On Nov 29, 2007 5:57 PM, Scott O'Bryan <da...@gmail.com> 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
Re: MyFaces JSF Commons Project
Posted by Scott O'Bryan <da...@gmail.com>.
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 <v....@inexso.de> 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 <da...@gmail.com>:
>>
>>
>>> 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 <ma...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Nov 29, 2007 5:57 PM, Scott O'Bryan <da...@gmail.com> 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
>
>
>
Re: MyFaces JSF Commons Project
Posted by Matthias Wessendorf <ma...@apache.org>.
On Dec 5, 2007 10:40 AM, Volker Weber <v....@inexso.de> 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 <da...@gmail.com>:
>
> > 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 <ma...@apache.org>
> > >>>> wrote:
> > >>>>> On Nov 29, 2007 5:57 PM, Scott O'Bryan <da...@gmail.com> 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
Re: MyFaces JSF Commons Project
Posted by Volker Weber <v....@inexso.de>.
Hi,
why should a jsf1.1 extension library require java1.4 support?
tobago requires java1.5.
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
commons-validator. Also many util classes should be able to work in
jsf1.1 and jsf1.2 without changes.
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 <da...@gmail.com>:
> 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 <ma...@apache.org>
> >>>> wrote:
> >>>>> On Nov 29, 2007 5:57 PM, Scott O'Bryan <da...@gmail.com> 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
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>
Re: MyFaces JSF Commons Project
Posted by Scott O'Bryan <da...@gmail.com>.
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 <ma...@apache.org>
>>>> wrote:
>>>>> On Nov 29, 2007 5:57 PM, Scott O'Bryan <da...@gmail.com> 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
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: MyFaces JSF Commons Project
Posted by Paul Spencer <pa...@apache.org>.
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 <ma...@apache.org> wrote:
>>>> On Nov 29, 2007 5:57 PM, Scott O'Bryan <da...@gmail.com> 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
>>>>
>>>
>>
>>
>
>
Re: MyFaces JSF Commons Project
Posted by Scott O'Bryan <da...@gmail.com>.
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 <ma...@apache.org> wrote:
>>> On Nov 29, 2007 5:57 PM, Scott O'Bryan <da...@gmail.com> 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
>>>
>>
>
>
Re: MyFaces JSF Commons Project
Posted by Paul Spencer <pa...@apache.org>.
+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 <ma...@apache.org> wrote:
>> On Nov 29, 2007 5:57 PM, Scott O'Bryan <da...@gmail.com> 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
>>
>