You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Scott O'Bryan <da...@gmail.com> on 2007/11/29 17:57:41 UTC
MyFaces JSF Commons Project
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.
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. :)
Re: MyFaces JSF Commons Project
Posted by Matthias Wessendorf <ma...@apache.org>.
On Nov 29, 2007 6:06 PM, 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
on the other hand;
this is a "new" project, so when it is based on JSF 1.2 API, it would be OK,
but I think JSF 1.1 is to much used...
But... two versions/trunks/branches are a PITA :-)
>
> >
> > 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 Matthias Wessendorf <ma...@apache.org>.
I'd vote +0 on supporting JSF 1.1
if that does answer your question.
(and in case some guys do need the converters/validators, they can
always fork it)
-m
On Dec 5, 2007 7:14 PM, Andrew Robinson <an...@gmail.com> wrote:
> Sorry to be frank, but that wasn't an answer to the question.
> Maintaining two code lines far outweighs the work to flip the plug-in
> configuration, and that reason alone should be enough to discourage
> any new 1.1 projects. The question still remains of why we need to
> support 1.1.
>
>
> On Dec 5, 2007 11:10 AM, Matthias Wessendorf <ma...@apache.org> wrote:
> > On Dec 5, 2007 6:53 PM, Mike Kienenberger <mk...@gmail.com> wrote:
> > > Many of us here have said that we don't see the need to support 1.1
> > > for this project.
> >
> > yes.
> >
> > > Is there anyone here who feels that we do need to support 1.1 (and why)?
> > Since some artifacts are generated (like the TAGs for the
> > converters/validators),
> > it is not a big deal to have
> > a) the project independent from a specific API
> > b) run the build with a param=faces11 (or faces12) to get the desired result.
> >
> > -M
> > >
> > >
> > > On Dec 5, 2007 12:33 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> > > >
> > > > On Dec 5, 2007 6:18 PM, Andrew Robinson <an...@gmail.com> wrote:
> > > > > >
> > > > > > here we go;
> > > > > > my understanding is, that 1.1 is a must
> > > > >
> > > > > Why? Is it really necessary for us to create new projects on legacy
> > > > > specifications?
> > > >
> > > > Well "a must" is a bit too much. I think I said that, having Tomahawk
> > > > 1.1.x in mind...
> > > > But... I really don't care that much on Tomahawk 1.1.x;
> > > >
> > > > A lot's of parts are pretty independent form the particular version.
> > > > Those work out of the box for both versions...
> > > >
> > > > The other parts, that aren't (such as utils that uses invokeOnComp(),
> > > > ExtCtx....)
> > > > It is ok to skip faces 1.1
> > > >
> > > > -Matthias
> > > >
> > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 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 Andrew Robinson <an...@gmail.com>.
Sorry to be frank, but that wasn't an answer to the question.
Maintaining two code lines far outweighs the work to flip the plug-in
configuration, and that reason alone should be enough to discourage
any new 1.1 projects. The question still remains of why we need to
support 1.1.
On Dec 5, 2007 11:10 AM, Matthias Wessendorf <ma...@apache.org> wrote:
> On Dec 5, 2007 6:53 PM, Mike Kienenberger <mk...@gmail.com> wrote:
> > Many of us here have said that we don't see the need to support 1.1
> > for this project.
>
> yes.
>
> > Is there anyone here who feels that we do need to support 1.1 (and why)?
> Since some artifacts are generated (like the TAGs for the
> converters/validators),
> it is not a big deal to have
> a) the project independent from a specific API
> b) run the build with a param=faces11 (or faces12) to get the desired result.
>
> -M
> >
> >
> > On Dec 5, 2007 12:33 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> > >
> > > On Dec 5, 2007 6:18 PM, Andrew Robinson <an...@gmail.com> wrote:
> > > > >
> > > > > here we go;
> > > > > my understanding is, that 1.1 is a must
> > > >
> > > > Why? Is it really necessary for us to create new projects on legacy
> > > > specifications?
> > >
> > > Well "a must" is a bit too much. I think I said that, having Tomahawk
> > > 1.1.x in mind...
> > > But... I really don't care that much on Tomahawk 1.1.x;
> > >
> > > A lot's of parts are pretty independent form the particular version.
> > > Those work out of the box for both versions...
> > >
> > > The other parts, that aren't (such as utils that uses invokeOnComp(),
> > > ExtCtx....)
> > > It is ok to skip faces 1.1
> > >
> > > -Matthias
> > >
> > >
> > > >
> > >
> > >
> > >
> > > --
> > > 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>.
On Dec 5, 2007 6:53 PM, Mike Kienenberger <mk...@gmail.com> wrote:
> Many of us here have said that we don't see the need to support 1.1
> for this project.
yes.
> Is there anyone here who feels that we do need to support 1.1 (and why)?
Since some artifacts are generated (like the TAGs for the
converters/validators),
it is not a big deal to have
a) the project independent from a specific API
b) run the build with a param=faces11 (or faces12) to get the desired result.
-M
>
>
> On Dec 5, 2007 12:33 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> >
> > On Dec 5, 2007 6:18 PM, Andrew Robinson <an...@gmail.com> wrote:
> > > >
> > > > here we go;
> > > > my understanding is, that 1.1 is a must
> > >
> > > Why? Is it really necessary for us to create new projects on legacy
> > > specifications?
> >
> > Well "a must" is a bit too much. I think I said that, having Tomahawk
> > 1.1.x in mind...
> > But... I really don't care that much on Tomahawk 1.1.x;
> >
> > A lot's of parts are pretty independent form the particular version.
> > Those work out of the box for both versions...
> >
> > The other parts, that aren't (such as utils that uses invokeOnComp(),
> > ExtCtx....)
> > It is ok to skip faces 1.1
> >
> > -Matthias
> >
> >
> > >
> >
> >
> >
> > --
> > 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 Mike Kienenberger <mk...@gmail.com>.
Many of us here have said that we don't see the need to support 1.1
for this project.
Is there anyone here who feels that we do need to support 1.1 (and why)?
On Dec 5, 2007 12:33 PM, Matthias Wessendorf <ma...@apache.org> wrote:
>
> On Dec 5, 2007 6:18 PM, Andrew Robinson <an...@gmail.com> wrote:
> > >
> > > here we go;
> > > my understanding is, that 1.1 is a must
> >
> > Why? Is it really necessary for us to create new projects on legacy
> > specifications?
>
> Well "a must" is a bit too much. I think I said that, having Tomahawk
> 1.1.x in mind...
> But... I really don't care that much on Tomahawk 1.1.x;
>
> A lot's of parts are pretty independent form the particular version.
> Those work out of the box for both versions...
>
> The other parts, that aren't (such as utils that uses invokeOnComp(),
> ExtCtx....)
> It is ok to skip faces 1.1
>
> -Matthias
>
>
> >
>
>
>
> --
> 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 6:18 PM, Andrew Robinson <an...@gmail.com> wrote:
> >
> > here we go;
> > my understanding is, that 1.1 is a must
>
> Why? Is it really necessary for us to create new projects on legacy
> specifications?
Well "a must" is a bit too much. I think I said that, having Tomahawk
1.1.x in mind...
But... I really don't care that much on Tomahawk 1.1.x;
A lot's of parts are pretty independent form the particular version.
Those work out of the box for both versions...
The other parts, that aren't (such as utils that uses invokeOnComp(),
ExtCtx....)
It is ok to skip faces 1.1
-Matthias
>
--
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 Andrew Robinson <an...@gmail.com>.
>
> here we go;
> my understanding is, that 1.1 is a must
Why? Is it really necessary for us to create new projects on legacy
specifications?
Re: MyFaces JSF Commons Project
Posted by Matthias Wessendorf <ma...@apache.org>.
to make it clear.
I am not saying, that JSF 1.1 API is the ONLY ONE.
Because this is a new project, a JSF 1.2 ONLY *would* make sense...
but... JSF 1.1 is still in use...
Perhaps a second trunk for 1.1-based JSF is a good thing (tm)
-Matthias
On Nov 29, 2007 6:16 PM, Scott O'Bryan <da...@gmail.com> wrote:
> If 1.1 is a must then I don't see any way around having 2 trunks. The
> API's between the two are not the same and when dealing with things like
> decorators (which JSF makes extensive use of), you need to implement
> every method on a class and ONLY those methods.
>
> I know that for Trinidad, although 90% of our code base is the same
> between JSF 1.1 and 1.2, approximately 10% is not. And that 10% is what
> may well force us NOT to use the commons project for things like
> Multi-part form handling. Plus, I would like to make some utilities
> that would allow renderkits to have an easier time of working with a
> JSR-301 portlet environment while allowing the portlet-bridge-api's and
> impls to be optional at runtime. Something that could save a lot of
> time for render kit developers. These will need to be 1.2 only.
>
> Scott
>
>
> Matthias Wessendorf 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>.
We CAN... But the compile time requirements will be different. And the
real concern I have is that this commons project is a slave to another
project which means we are at the mercy of the JSF api's. If they
change, implementations need to change and it may not always be possible
to have both classes exist in the classpath at any given time.
Unfortunately.
The approach we originally took in Trinidad was to commit changes to the
1.1 branch and then upmerge them to the 1.2 branch. The problem is that
this proved cumbersome and error prone so we've taken recently to a
dual-trunk type system. The real issue is this. We are all open source
developers. Our time, as a result, is limited. IMO maintaining two
branches hampers new development and innovation. I know it has in
Trinidad to a large extent because nobody likes making patches to dual
code lines.
Scott
Glauco P. Gomes wrote:
> Scott O'Bryan escreveu:
>> If 1.1 is a must then I don't see any way around having 2 trunks.
> WDYT about use different pakages for different versions (incompatible
> stuff only) like Spring did for Hibernate version 2 and 3?
>
> org.springframework.orm.hibernate => for Hibernate 2.x
>
> and
>
> org.springframework.orm.hibernate3 => for Hibernate 3.x
>
>
> Glauco P. Gomes
>
Re: MyFaces JSF Commons Project
Posted by Matthias Wessendorf <ma...@apache.org>.
I don't think it is a good idea.
-M
On Nov 29, 2007 6:37 PM, Glauco P. Gomes <gl...@yahoo.com.br> wrote:
> Scott O'Bryan escreveu:
> > If 1.1 is a must then I don't see any way around having 2 trunks.
> WDYT about use different pakages for different versions (incompatible
> stuff only) like Spring did for Hibernate version 2 and 3?
>
> org.springframework.orm.hibernate => for Hibernate 2.x
>
> and
>
> org.springframework.orm.hibernate3 => for Hibernate 3.x
>
>
> Glauco P. Gomes
>
--
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 "Glauco P. Gomes" <gl...@yahoo.com.br>.
Scott O'Bryan escreveu:
> If 1.1 is a must then I don't see any way around having 2 trunks.
WDYT about use different pakages for different versions (incompatible
stuff only) like Spring did for Hibernate version 2 and 3?
org.springframework.orm.hibernate => for Hibernate 2.x
and
org.springframework.orm.hibernate3 => for Hibernate 3.x
Glauco P. Gomes
Re: MyFaces JSF Commons Project
Posted by Scott O'Bryan <da...@gmail.com>.
If 1.1 is a must then I don't see any way around having 2 trunks. The
API's between the two are not the same and when dealing with things like
decorators (which JSF makes extensive use of), you need to implement
every method on a class and ONLY those methods.
I know that for Trinidad, although 90% of our code base is the same
between JSF 1.1 and 1.2, approximately 10% is not. And that 10% is what
may well force us NOT to use the commons project for things like
Multi-part form handling. Plus, I would like to make some utilities
that would allow renderkits to have an easier time of working with a
JSR-301 portlet environment while allowing the portlet-bridge-api's and
impls to be optional at runtime. Something that could save a lot of
time for render kit developers. These will need to be 1.2 only.
Scott
Matthias Wessendorf 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
>
>
>
>
>
>
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
>>
>
Re: MyFaces JSF Commons Project
Posted by Andrew Robinson <an...@gmail.com>.
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 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