Bernd Bohmann's 1.1 concerns with Commons [was: [VOTE] Commons API JSF 1.2 only]

[Mike Kienenberger <mk...@gmail.com>]

At least in terms of the validators/converters/etc (non-api) parts of
commons, it is not intended that Tobago or any other project depend on
these.   These are additional components made available to the end
users.   So it's true that some small subset of Tobago users won't be
able to use it.   The same is true for Trinidad and Tomahawk users.

I don't think that's reason enough to require that these projects
support JSF 1.1.

I still think the conglomeration of developer-targeted utilities/apis
and end-user-targeted components is a mistake, and I was under the
impression that each of these pieces was independent of each other.
If that's the case, there's no reason why the api/utils
developer-targeted projects can't maintain JSF 1.1 support while
leaving the component end-user-targeted projects at JSF 1.2.

On Dec 5, 2007 5:08 PM, Bernd Bohmann <be...@atanion.com> wrote:
> The tobago codebase will be 1.1 or 1.2 compatible as much as possible.
> If commons only supports 1.2 we are not able to use it in tobago until
> the 1.1 version is only in maintenance mode.
>
> I think it's ok if some parts of commons are 1.2 only.
> I think jdk 1.4 compatibility is not a requirement.(We can provide a
> retrotranslated version)
>
> As far I know some of the tobago users still using 1.1 jsf and not able
> to switch to 1.2 until end of 2008.
>
> Andrew Robinson schrieb:
>
> > As the vote states, if -1, please provide a reason why 1.1 has to be
> > supported. An argument of why not is not enough.
> >
> > On Dec 5, 2007 2:14 PM, Bernd Bohmann <be...@atanion.com> wrote:
> >> -1
> >>
> >> I don't see any reason why a commons fileupload should not support 1.1
> >>
> >> Can someone define what commons API means?
> >>
> >> Is this just a subproject of commons like commons validator or commons
> >> converter?
> >>
> >> Scott O'Bryan schrieb:
> >>
> >>> +1
> >>>
> >>> Mario Ivankovits wrote:
> >>>> +1
> >>>>> Lets make the myfaces commons JSF API an official vote so we can have
> >>>>> a fixed time frame on this decision
> >>>>>
> >>>>> +1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces
> >>>>> commons project
> >>>>> +0 [ ] -- you don't mind supporting a 1.1 trunk in addition to a 1.2
> >>>>> trunk
> >>>>> -1 [ ] -- you feel that 1.1 should be required and why you feel that
> >>>>> it is needed
> >>>>>
> >>>>> My vote: +1
> >>>>>
> >>>>> -Andrew
> >>>>>
> >>>>>
> >>>>
> >>>
> >
>

Re: Bernd Bohmann's 1.1 concerns with Commons [was: [VOTE] Commons API JSF 1.2 only]

[Scott O'Bryan <da...@gmail.com>]

One thing I do agree on is that end-user components belong in the 
renderkits.  I see these utilities as being API's that the renderkit 
developers could use in common.

Scott

Scott O'Bryan wrote:
> Mike, the reason for the API's I'm proposing is to solve a usecase we 
> can't currently support.  Largely because of file uploads (but also 
> some other things as well), it is impossible for two renderkits to 
> somtimes even exist in the same webapplication as each other.
>
> For instance, let's say you use Tobago for one page and Trinidad for 
> another.  If Tobago exists first in your classpath and Trinidad exists 
> second in your classpath, you will only ever be able to us the Tobago 
> multi-part form handling.  By unifying these, it would still be up to 
> the renderkit to have their own file-upload component, it's just the 
> multi-part form handling could be done by the commons.
>
> Furthermore, all of the Renderkits today have a filter 
> implementation.  Renderkits like Trinidad and Tobago are getting away 
> from these as much as possible.  Other then being difficult to 
> configure, Filters do not port well over to Portal's.  Both Tobago and 
> Trinidad have come up with their own methods for doing some of this 
> filter logic inside of custom FacesContextFactories, but this work is 
> error prone, non-trivial, and is subject to the class-path ordering 
> issues I explained earlier.  By unifying the mechanism whereby this 
> wrapping happens, we can concentrate on replacing as much of this 
> legacy "filter" functionality as possible.
>
> Scott
>
> Mike Kienenberger wrote:
>> At least in terms of the validators/converters/etc (non-api) parts of
>> commons, it is not intended that Tobago or any other project depend on
>> these.   These are additional components made available to the end
>> users.   So it's true that some small subset of Tobago users won't be
>> able to use it.   The same is true for Trinidad and Tomahawk users.
>>
>> I don't think that's reason enough to require that these projects
>> support JSF 1.1.
>>
>> I still think the conglomeration of developer-targeted utilities/apis
>> and end-user-targeted components is a mistake, and I was under the
>> impression that each of these pieces was independent of each other.
>> If that's the case, there's no reason why the api/utils
>> developer-targeted projects can't maintain JSF 1.1 support while
>> leaving the component end-user-targeted projects at JSF 1.2.
>>
>> On Dec 5, 2007 5:08 PM, Bernd Bohmann <be...@atanion.com> wrote:
>>  
>>> The tobago codebase will be 1.1 or 1.2 compatible as much as possible.
>>> If commons only supports 1.2 we are not able to use it in tobago until
>>> the 1.1 version is only in maintenance mode.
>>>
>>> I think it's ok if some parts of commons are 1.2 only.
>>> I think jdk 1.4 compatibility is not a requirement.(We can provide a
>>> retrotranslated version)
>>>
>>> As far I know some of the tobago users still using 1.1 jsf and not able
>>> to switch to 1.2 until end of 2008.
>>>
>>> Andrew Robinson schrieb:
>>>
>>>    
>>>> As the vote states, if -1, please provide a reason why 1.1 has to be
>>>> supported. An argument of why not is not enough.
>>>>
>>>> On Dec 5, 2007 2:14 PM, Bernd Bohmann <be...@atanion.com> 
>>>> wrote:
>>>>      
>>>>> -1
>>>>>
>>>>> I don't see any reason why a commons fileupload should not support 
>>>>> 1.1
>>>>>
>>>>> Can someone define what commons API means?
>>>>>
>>>>> Is this just a subproject of commons like commons validator or 
>>>>> commons
>>>>> converter?
>>>>>
>>>>> Scott O'Bryan schrieb:
>>>>>
>>>>>        
>>>>>> +1
>>>>>>
>>>>>> Mario Ivankovits wrote:
>>>>>>          
>>>>>>> +1
>>>>>>>            
>>>>>>>> Lets make the myfaces commons JSF API an official vote so we 
>>>>>>>> can have
>>>>>>>> a fixed time frame on this decision
>>>>>>>>
>>>>>>>> +1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces
>>>>>>>> commons project
>>>>>>>> +0 [ ] -- you don't mind supporting a 1.1 trunk in addition to 
>>>>>>>> a 1.2
>>>>>>>> trunk
>>>>>>>> -1 [ ] -- you feel that 1.1 should be required and why you feel 
>>>>>>>> that
>>>>>>>> it is needed
>>>>>>>>
>>>>>>>> My vote: +1
>>>>>>>>
>>>>>>>> -Andrew
>>>>>>>>
>>>>>>>>
>>>>>>>>               
>>
>>   
>
>

Re: Bernd Bohmann's 1.1 concerns with Commons [was: [VOTE] Commons API JSF 1.2 only]

[Matthias Wessendorf <ma...@apache.org>]

On Dec 5, 2007 11:32 PM, Scott O'Bryan <da...@gmail.com> wrote:
> Mike, the reason for the API's I'm proposing is to solve a usecase we
> can't currently support.  Largely because of file uploads (but also some
> other things as well), it is impossible for two renderkits to somtimes
> even exist in the same webapplication as each other.
>
> For instance, let's say you use Tobago for one page and Trinidad for
> another.  If Tobago exists first in your classpath and Trinidad exists
> second in your classpath, you will only ever be able to us the Tobago
> multi-part form handling.  By unifying these, it would still be up to
> the renderkit to have their own file-upload component, it's just the
> multi-part form handling could be done by the commons.
>
> Furthermore, all of the Renderkits today have a filter implementation.
> Renderkits like Trinidad and Tobago are getting away from these as much
> as possible.  Other then being difficult to configure, Filters do not

oh boy, it's top question, every month;

> port well over to Portal's.  Both Tobago and Trinidad have come up with

same for portlet;

> their own methods for doing some of this filter logic inside of custom
> FacesContextFactories, but this work is error prone, non-trivial, and is
> subject to the class-path ordering issues I explained earlier.  By
> unifying the mechanism whereby this wrapping happens, we can concentrate
> on replacing as much of this legacy "filter" functionality as possible.

I think we discussed (at least in the past) a more unified version of
handling the multi-part-form, w/o filters;

-M

>
> Scott
>
>
> Mike Kienenberger wrote:
> > At least in terms of the validators/converters/etc (non-api) parts of
> > commons, it is not intended that Tobago or any other project depend on
> > these.   These are additional components made available to the end
> > users.   So it's true that some small subset of Tobago users won't be
> > able to use it.   The same is true for Trinidad and Tomahawk users.
> >
> > I don't think that's reason enough to require that these projects
> > support JSF 1.1.
> >
> > I still think the conglomeration of developer-targeted utilities/apis
> > and end-user-targeted components is a mistake, and I was under the
> > impression that each of these pieces was independent of each other.
> > If that's the case, there's no reason why the api/utils
> > developer-targeted projects can't maintain JSF 1.1 support while
> > leaving the component end-user-targeted projects at JSF 1.2.
> >
> > On Dec 5, 2007 5:08 PM, Bernd Bohmann <be...@atanion.com> wrote:
> >
> >> The tobago codebase will be 1.1 or 1.2 compatible as much as possible.
> >> If commons only supports 1.2 we are not able to use it in tobago until
> >> the 1.1 version is only in maintenance mode.
> >>
> >> I think it's ok if some parts of commons are 1.2 only.
> >> I think jdk 1.4 compatibility is not a requirement.(We can provide a
> >> retrotranslated version)
> >>
> >> As far I know some of the tobago users still using 1.1 jsf and not able
> >> to switch to 1.2 until end of 2008.
> >>
> >> Andrew Robinson schrieb:
> >>
> >>
> >>> As the vote states, if -1, please provide a reason why 1.1 has to be
> >>> supported. An argument of why not is not enough.
> >>>
> >>> On Dec 5, 2007 2:14 PM, Bernd Bohmann <be...@atanion.com> wrote:
> >>>
> >>>> -1
> >>>>
> >>>> I don't see any reason why a commons fileupload should not support 1.1
> >>>>
> >>>> Can someone define what commons API means?
> >>>>
> >>>> Is this just a subproject of commons like commons validator or commons
> >>>> converter?
> >>>>
> >>>> Scott O'Bryan schrieb:
> >>>>
> >>>>
> >>>>> +1
> >>>>>
> >>>>> Mario Ivankovits wrote:
> >>>>>
> >>>>>> +1
> >>>>>>
> >>>>>>> Lets make the myfaces commons JSF API an official vote so we can have
> >>>>>>> a fixed time frame on this decision
> >>>>>>>
> >>>>>>> +1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces
> >>>>>>> commons project
> >>>>>>> +0 [ ] -- you don't mind supporting a 1.1 trunk in addition to a 1.2
> >>>>>>> trunk
> >>>>>>> -1 [ ] -- you feel that 1.1 should be required and why you feel that
> >>>>>>> it is needed
> >>>>>>>
> >>>>>>> My vote: +1
> >>>>>>>
> >>>>>>> -Andrew
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >
> >
>
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Why API? [was Re: Bernd Bohmann's 1.1 concerns with Commons [was: [VOTE] Commons API JSF 1.2 only]]

[Scott O'Bryan <da...@gmail.com>]

Forking this part of the discussion.

:)  I will say that the Configurator's aren't completely isolated from 
the classpath ordering issue.  But I'm hoping that the combination of 
universal processing for common tasks (like multi-part form handling) 
and the ordering system allowed by the service's framework I wrote, 
might help mitigate some of the issues.

One thing I didn't add, that I could later, is the ability to have true 
service "dependencies", but for now the ordinal-based ordering should 
help tremendously...

Scott

Bernd Bohmann wrote:
> +1 :-) i don't like filters and don't like depending on the class-path
> ordering
>
> Scott O'Bryan schrieb:
>   
>> Mike, the reason for the API's I'm proposing is to solve a usecase we
>> can't currently support.  Largely because of file uploads (but also some
>> other things as well), it is impossible for two renderkits to somtimes
>> even exist in the same webapplication as each other.
>>
>> For instance, let's say you use Tobago for one page and Trinidad for
>> another.  If Tobago exists first in your classpath and Trinidad exists
>> second in your classpath, you will only ever be able to us the Tobago
>> multi-part form handling.  By unifying these, it would still be up to
>> the renderkit to have their own file-upload component, it's just the
>> multi-part form handling could be done by the commons.
>>
>> Furthermore, all of the Renderkits today have a filter implementation. 
>> Renderkits like Trinidad and Tobago are getting away from these as much
>> as possible.  Other then being difficult to configure, Filters do not
>> port well over to Portal's.  Both Tobago and Trinidad have come up with
>> their own methods for doing some of this filter logic inside of custom
>> FacesContextFactories, but this work is error prone, non-trivial, and is
>> subject to the class-path ordering issues I explained earlier.  By
>> unifying the mechanism whereby this wrapping happens, we can concentrate
>> on replacing as much of this legacy "filter" functionality as possible.
>>
>> Scott
>>
>> Mike Kienenberger wrote:
>>     
>>> At least in terms of the validators/converters/etc (non-api) parts of
>>> commons, it is not intended that Tobago or any other project depend on
>>> these.   These are additional components made available to the end
>>> users.   So it's true that some small subset of Tobago users won't be
>>> able to use it.   The same is true for Trinidad and Tomahawk users.
>>>
>>> I don't think that's reason enough to require that these projects
>>> support JSF 1.1.
>>>
>>> I still think the conglomeration of developer-targeted utilities/apis
>>> and end-user-targeted components is a mistake, and I was under the
>>> impression that each of these pieces was independent of each other.
>>> If that's the case, there's no reason why the api/utils
>>> developer-targeted projects can't maintain JSF 1.1 support while
>>> leaving the component end-user-targeted projects at JSF 1.2.
>>>
>>> On Dec 5, 2007 5:08 PM, Bernd Bohmann <be...@atanion.com> wrote:
>>>  
>>>       
>>>> The tobago codebase will be 1.1 or 1.2 compatible as much as possible.
>>>> If commons only supports 1.2 we are not able to use it in tobago until
>>>> the 1.1 version is only in maintenance mode.
>>>>
>>>> I think it's ok if some parts of commons are 1.2 only.
>>>> I think jdk 1.4 compatibility is not a requirement.(We can provide a
>>>> retrotranslated version)
>>>>
>>>> As far I know some of the tobago users still using 1.1 jsf and not able
>>>> to switch to 1.2 until end of 2008.
>>>>
>>>> Andrew Robinson schrieb:
>>>>
>>>>    
>>>>         
>>>>> As the vote states, if -1, please provide a reason why 1.1 has to be
>>>>> supported. An argument of why not is not enough.
>>>>>
>>>>> On Dec 5, 2007 2:14 PM, Bernd Bohmann <be...@atanion.com>
>>>>> wrote:
>>>>>      
>>>>>           
>>>>>> -1
>>>>>>
>>>>>> I don't see any reason why a commons fileupload should not support 1.1
>>>>>>
>>>>>> Can someone define what commons API means?
>>>>>>
>>>>>> Is this just a subproject of commons like commons validator or commons
>>>>>> converter?
>>>>>>
>>>>>> Scott O'Bryan schrieb:
>>>>>>
>>>>>>        
>>>>>>             
>>>>>>> +1
>>>>>>>
>>>>>>> Mario Ivankovits wrote:
>>>>>>>          
>>>>>>>               
>>>>>>>> +1
>>>>>>>>            
>>>>>>>>                 
>>>>>>>>> Lets make the myfaces commons JSF API an official vote so we can
>>>>>>>>> have
>>>>>>>>> a fixed time frame on this decision
>>>>>>>>>
>>>>>>>>> +1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces
>>>>>>>>> commons project
>>>>>>>>> +0 [ ] -- you don't mind supporting a 1.1 trunk in addition to a
>>>>>>>>> 1.2
>>>>>>>>> trunk
>>>>>>>>> -1 [ ] -- you feel that 1.1 should be required and why you feel
>>>>>>>>> that
>>>>>>>>> it is needed
>>>>>>>>>
>>>>>>>>> My vote: +1
>>>>>>>>>
>>>>>>>>> -Andrew
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>               
>>>>>>>>>                   
>>>   
>>>       
>>     
>
>   

Re: Bernd Bohmann's 1.1 concerns with Commons [was: [VOTE] Commons API JSF 1.2 only]

[Bernd Bohmann <be...@atanion.com>]

+1 :-) i don't like filters and don't like depending on the class-path
ordering

Scott O'Bryan schrieb:
> Mike, the reason for the API's I'm proposing is to solve a usecase we
> can't currently support.  Largely because of file uploads (but also some
> other things as well), it is impossible for two renderkits to somtimes
> even exist in the same webapplication as each other.
> 
> For instance, let's say you use Tobago for one page and Trinidad for
> another.  If Tobago exists first in your classpath and Trinidad exists
> second in your classpath, you will only ever be able to us the Tobago
> multi-part form handling.  By unifying these, it would still be up to
> the renderkit to have their own file-upload component, it's just the
> multi-part form handling could be done by the commons.
> 
> Furthermore, all of the Renderkits today have a filter implementation. 
> Renderkits like Trinidad and Tobago are getting away from these as much
> as possible.  Other then being difficult to configure, Filters do not
> port well over to Portal's.  Both Tobago and Trinidad have come up with
> their own methods for doing some of this filter logic inside of custom
> FacesContextFactories, but this work is error prone, non-trivial, and is
> subject to the class-path ordering issues I explained earlier.  By
> unifying the mechanism whereby this wrapping happens, we can concentrate
> on replacing as much of this legacy "filter" functionality as possible.
> 
> Scott
> 
> Mike Kienenberger wrote:
>> At least in terms of the validators/converters/etc (non-api) parts of
>> commons, it is not intended that Tobago or any other project depend on
>> these.   These are additional components made available to the end
>> users.   So it's true that some small subset of Tobago users won't be
>> able to use it.   The same is true for Trinidad and Tomahawk users.
>>
>> I don't think that's reason enough to require that these projects
>> support JSF 1.1.
>>
>> I still think the conglomeration of developer-targeted utilities/apis
>> and end-user-targeted components is a mistake, and I was under the
>> impression that each of these pieces was independent of each other.
>> If that's the case, there's no reason why the api/utils
>> developer-targeted projects can't maintain JSF 1.1 support while
>> leaving the component end-user-targeted projects at JSF 1.2.
>>
>> On Dec 5, 2007 5:08 PM, Bernd Bohmann <be...@atanion.com> wrote:
>>  
>>> The tobago codebase will be 1.1 or 1.2 compatible as much as possible.
>>> If commons only supports 1.2 we are not able to use it in tobago until
>>> the 1.1 version is only in maintenance mode.
>>>
>>> I think it's ok if some parts of commons are 1.2 only.
>>> I think jdk 1.4 compatibility is not a requirement.(We can provide a
>>> retrotranslated version)
>>>
>>> As far I know some of the tobago users still using 1.1 jsf and not able
>>> to switch to 1.2 until end of 2008.
>>>
>>> Andrew Robinson schrieb:
>>>
>>>    
>>>> As the vote states, if -1, please provide a reason why 1.1 has to be
>>>> supported. An argument of why not is not enough.
>>>>
>>>> On Dec 5, 2007 2:14 PM, Bernd Bohmann <be...@atanion.com>
>>>> wrote:
>>>>      
>>>>> -1
>>>>>
>>>>> I don't see any reason why a commons fileupload should not support 1.1
>>>>>
>>>>> Can someone define what commons API means?
>>>>>
>>>>> Is this just a subproject of commons like commons validator or commons
>>>>> converter?
>>>>>
>>>>> Scott O'Bryan schrieb:
>>>>>
>>>>>        
>>>>>> +1
>>>>>>
>>>>>> Mario Ivankovits wrote:
>>>>>>          
>>>>>>> +1
>>>>>>>            
>>>>>>>> Lets make the myfaces commons JSF API an official vote so we can
>>>>>>>> have
>>>>>>>> a fixed time frame on this decision
>>>>>>>>
>>>>>>>> +1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces
>>>>>>>> commons project
>>>>>>>> +0 [ ] -- you don't mind supporting a 1.1 trunk in addition to a
>>>>>>>> 1.2
>>>>>>>> trunk
>>>>>>>> -1 [ ] -- you feel that 1.1 should be required and why you feel
>>>>>>>> that
>>>>>>>> it is needed
>>>>>>>>
>>>>>>>> My vote: +1
>>>>>>>>
>>>>>>>> -Andrew
>>>>>>>>
>>>>>>>>
>>>>>>>>               
>>
>>   
> 
> 

Re: Bernd Bohmann's 1.1 concerns with Commons [was: [VOTE] Commons API JSF 1.2 only]

[Scott O'Bryan <da...@gmail.com>]

Mike, the reason for the API's I'm proposing is to solve a usecase we 
can't currently support.  Largely because of file uploads (but also some 
other things as well), it is impossible for two renderkits to somtimes 
even exist in the same webapplication as each other.

For instance, let's say you use Tobago for one page and Trinidad for 
another.  If Tobago exists first in your classpath and Trinidad exists 
second in your classpath, you will only ever be able to us the Tobago 
multi-part form handling.  By unifying these, it would still be up to 
the renderkit to have their own file-upload component, it's just the 
multi-part form handling could be done by the commons.

Furthermore, all of the Renderkits today have a filter implementation.  
Renderkits like Trinidad and Tobago are getting away from these as much 
as possible.  Other then being difficult to configure, Filters do not 
port well over to Portal's.  Both Tobago and Trinidad have come up with 
their own methods for doing some of this filter logic inside of custom 
FacesContextFactories, but this work is error prone, non-trivial, and is 
subject to the class-path ordering issues I explained earlier.  By 
unifying the mechanism whereby this wrapping happens, we can concentrate 
on replacing as much of this legacy "filter" functionality as possible.

Scott

Mike Kienenberger wrote:
> At least in terms of the validators/converters/etc (non-api) parts of
> commons, it is not intended that Tobago or any other project depend on
> these.   These are additional components made available to the end
> users.   So it's true that some small subset of Tobago users won't be
> able to use it.   The same is true for Trinidad and Tomahawk users.
>
> I don't think that's reason enough to require that these projects
> support JSF 1.1.
>
> I still think the conglomeration of developer-targeted utilities/apis
> and end-user-targeted components is a mistake, and I was under the
> impression that each of these pieces was independent of each other.
> If that's the case, there's no reason why the api/utils
> developer-targeted projects can't maintain JSF 1.1 support while
> leaving the component end-user-targeted projects at JSF 1.2.
>
> On Dec 5, 2007 5:08 PM, Bernd Bohmann <be...@atanion.com> wrote:
>   
>> The tobago codebase will be 1.1 or 1.2 compatible as much as possible.
>> If commons only supports 1.2 we are not able to use it in tobago until
>> the 1.1 version is only in maintenance mode.
>>
>> I think it's ok if some parts of commons are 1.2 only.
>> I think jdk 1.4 compatibility is not a requirement.(We can provide a
>> retrotranslated version)
>>
>> As far I know some of the tobago users still using 1.1 jsf and not able
>> to switch to 1.2 until end of 2008.
>>
>> Andrew Robinson schrieb:
>>
>>     
>>> As the vote states, if -1, please provide a reason why 1.1 has to be
>>> supported. An argument of why not is not enough.
>>>
>>> On Dec 5, 2007 2:14 PM, Bernd Bohmann <be...@atanion.com> wrote:
>>>       
>>>> -1
>>>>
>>>> I don't see any reason why a commons fileupload should not support 1.1
>>>>
>>>> Can someone define what commons API means?
>>>>
>>>> Is this just a subproject of commons like commons validator or commons
>>>> converter?
>>>>
>>>> Scott O'Bryan schrieb:
>>>>
>>>>         
>>>>> +1
>>>>>
>>>>> Mario Ivankovits wrote:
>>>>>           
>>>>>> +1
>>>>>>             
>>>>>>> Lets make the myfaces commons JSF API an official vote so we can have
>>>>>>> a fixed time frame on this decision
>>>>>>>
>>>>>>> +1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces
>>>>>>> commons project
>>>>>>> +0 [ ] -- you don't mind supporting a 1.1 trunk in addition to a 1.2
>>>>>>> trunk
>>>>>>> -1 [ ] -- you feel that 1.1 should be required and why you feel that
>>>>>>> it is needed
>>>>>>>
>>>>>>> My vote: +1
>>>>>>>
>>>>>>> -Andrew
>>>>>>>
>>>>>>>
>>>>>>>               
>
>