Re: MyFaces JSF Commons Project
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > On Dec 5, 2007 6:53 PM, Mike Kienenberger <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > > > > On Dec 5, 2007 6:18 PM, Andrew Robinson <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> wrote: > On Dec 5, 2007 6:53 PM, Mike Kienenberger <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > > On Dec 5, 2007 6:18 PM, Andrew Robinson <[EMAIL PROTECTED]> 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
On Dec 5, 2007 6:53 PM, Mike Kienenberger <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > On Dec 5, 2007 6:18 PM, Andrew Robinson <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> wrote: > > On Dec 5, 2007 6:18 PM, Andrew Robinson <[EMAIL PROTECTED]> 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
On Dec 5, 2007 6:18 PM, Andrew Robinson <[EMAIL PROTECTED]> 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
That looks good. On Dec 5, 2007 6:16 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > Yeah I agree. > > So to summarize here is what I'm understanding from people: > > Common Converters > * JDK 1.5 > * Should work on either JSF 1.1 & JSF 1.2 > > Common Validators > * JDK 1.5 > * Should work on either JSF 1.1 & JSF 1.2 > > Common Utilities > * JDK 1.5 > * Should work on either JSF 1.1 & JSF 1.2 > > Common Utilities 1.2 > * JDK 1.5 > * JSF 1.2+ > > Is that basically what we're looking at? > > Scott > > > Matthias Wessendorf wrote: > > yes, some APIs have changed; > > > > my point was just, that for "trivial" things (like the > > validators/converters), > > the API is same, the generated artifacts are *dependent* to the particular > > Faces version. > > > > -M > > > > On Dec 5, 2007 5:34 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > > > >> I've also noticed that things with the externalContext also do not work > >> properly because the ExternalContext api's have changed. I suspect > >> anything that relies on the new functionality in externalContext or any > >> of the other API's for that matter will have trouble porting back. > >> > >> Scott > >> > >> > >> Matthias Wessendorf wrote: > >> > >>> On Dec 5, 2007 10:40 AM, Volker Weber <[EMAIL PROTECTED]> wrote: > >>> > >>> > Hi, > > why should a jsf1.1 extension library require java1.4 support? > > > >>> +1 > >>> > >>> > tobago requires java1.5. > > > >>> Trinidad is also requiring Java5. > >>> like in Tobago land, we have a retro-weaver profile in the pom. > >>> > >>> > it is totally fine running jsf 1.1 on a java 1.6 environment. > > I don't know the details of jsf 1.2 spec, but it seems to me that the > api for javax.faces.convert.Converter is the same, so why must we > differ between 1.1 and 1.2 in the commons-converter? Same for > > > >>> API is same. > >>> > >>> the "impl" is little different; > >>> ConverterTag is deprecated; > >>> good folks would use ConverterELTag > >>> (same for validator) > >>> > >>> > commons-validator. Also many util classes should be able to work in > jsf1.1 and jsf1.2 without changes. > > > >>> yes "common" helper method, will work > >>> if the are not using things like invokeOnComponet(), for instance > >>> > >>> -M > >>> > >>> > >>> > Note: I'm speaking about the application-developer part of commons, > not of the component/library-developer part. > > > Regards, > Volker > > > 2007/12/5, Scott O'Bryan <[EMAIL PROTECTED]>: > > > > > Right, I totally agree. The point is that, currently, Tomahawk, Tobago, > > and Trinidad 1.1 are NOT currently dependent on commons. And > > introducing support for 1.1 in the commons now would mean that commons > > would have to support Java 1.4 and JSF 1.1 pretty much forever. > > > > My proposal is basically that we leave the current 1.1 compatible > > renderkits as they are, maybe allowing some common filters and > > converters depending on what people think is needed. The other commons > > could then be used as projects tackle 1.2 and the commons could be used > > to ease and unify that development effort. > > > > Scott > > > > Paul Spencer wrote: > > > > > >> Scott, > >> My concern is when components, like Tomahawk, become dependent on JSF > >> Commons, then they will inherit the dependencies of JSF Commons. If a > >> component in JSF Commons is not intended to be used with JSF 1.1, or > >> none of JSF 1.1 components, like Tomahawk, require the commons > >> component, then I have no objection for a non-JSF 1.1. compliant > >> dependency. > >> > >> Paul Spencer > >> > >> Scott O'Bryan wrote: > >> > >> > >>> Cool, I was hoping we had one. :) Paul, you mind if I ask you some > >>> questions about this? > >>> > >>> I can totally understand the want/need for the converters and > >>> validators to be ported to 1.1 (and thus need 1.4 support), but what > >>> about the utilities? Currently Trinidad, Tomahawk, and Tobago > >>> support JDK 1.1 and therefore their adoption of the common utilities > >>> would be slow if not non-existant. I know that the logic I'm trying > >>> to introduce, although it could be used in JSF 1.1 environments, > >>> really becomes most useful when dealing with JSF 1.2 and the portlet > >>> bridge. I also wouldn't think that things like unified multi-part > >>> form processing would be likely to make it into current 1.1 > >>> renderkits since it would require a lot of code to be rewritten and > >>> may not be backward compatible. > >>> > >>> Scott > >>> > >>> Paul Spencer wrote: > >>> > >>> > +1 on JSF 1.2 only > +1 on 1.1 support with JDK 1.5 required on both. > >>
Re: MyFaces JSF Commons Project
> > 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
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 <[EMAIL PROTECTED]> wrote: I've also noticed that things with the externalContext also do not work properly because the ExternalContext api's have changed. I suspect anything that relies on the new functionality in externalContext or any of the other API's for that matter will have trouble porting back. Scott Matthias Wessendorf wrote: On Dec 5, 2007 10:40 AM, Volker Weber <[EMAIL PROTECTED]> wrote: Hi, why should a jsf1.1 extension library require java1.4 support? +1 tobago requires java1.5. Trinidad is also requiring Java5. like in Tobago land, we have a retro-weaver profile in the pom. it is totally fine running jsf 1.1 on a java 1.6 environment. I don't know the details of jsf 1.2 spec, but it seems to me that the api for javax.faces.convert.Converter is the same, so why must we differ between 1.1 and 1.2 in the commons-converter? Same for API is same. the "impl" is little different; ConverterTag is deprecated; good folks would use ConverterELTag (same for validator) commons-validator. Also many util classes should be able to work in jsf1.1 and jsf1.2 without changes. yes "common" helper method, will work if the are not using things like invokeOnComponet(), for instance -M Note: I'm speaking about the application-developer part of commons, not of the component/library-developer part. Regards, Volker 2007/12/5, Scott O'Bryan <[EMAIL PROTECTED]>: Right, I totally agree. The point is that, currently, Tomahawk, Tobago, and Trinidad 1.1 are NOT currently dependent on commons. And introducing support for 1.1 in the commons now would mean that commons would have to support Java 1.4 and JSF 1.1 pretty much forever. My proposal is basically that we leave the current 1.1 compatible renderkits as they are, maybe allowing some common filters and converters depending on what people think is needed. The other commons could then be used as projects tackle 1.2 and the commons could be used to ease and unify that development effort. Scott Paul Spencer wrote: Scott, My concern is when components, like Tomahawk, become dependent on JSF Commons, then they will inherit the dependencies of JSF Commons. If a component in JSF Commons is not intended to be used with JSF 1.1, or none of JSF 1.1 components, like Tomahawk, require the commons component, then I have no objection for a non-JSF 1.1. compliant dependency. Paul Spencer Scott O'Bryan wrote: Cool, I was hoping we had one. :) Paul, you mind if I ask you some questions about this? I can totally understand the want/need for the converters and validators to be ported to 1.1 (and thus need 1.4 support), but what about the utilities? Currently Trinidad, Tomahawk, and Tobago support JDK 1.1 and therefore their adoption of the common utilities would be slow if not non-existant. I know that the logic I'm trying to introduce, although it could be used in JSF 1.1 environments, really becomes most useful when dealing with JSF 1.2 and the portlet bridge. I also wouldn't think that things like unified multi-part form processing would be likely to make it into current 1.1 renderkits since it would require a lot of code to be rewritten and may not be backward compatible. Scott Paul Spencer wrote: +1 on JSF 1.2 only +1 on 1.1 support with JDK 1.5 required on both. +1 on 1.1 w/ 1.4 I have projects I support on HP-UX that are currently running JDK 1.4. Paul Spencer Andrew Robinson wrote: I would go for: +1 on JSF 1.2 only This is open source, so no one is required to use it and embracing 1.2 is only going to help the development community move forward. +0.5 on 1.1 support with JDK 1.5 required on both. Just because the specification supports 1.4 does mean libraries have to. JDK 1.5 has been out plenty long enough for companies to adopt it. If they cannot adopt it, they should be willing to forgo new libraries and functionalit
Re: MyFaces JSF Commons Project
Yeah I agree. So to summarize here is what I'm understanding from people: Common Converters * JDK 1.5 * Should work on either JSF 1.1 & JSF 1.2 Common Validators * JDK 1.5 * Should work on either JSF 1.1 & JSF 1.2 Common Utilities * JDK 1.5 * Should work on either JSF 1.1 & JSF 1.2 Common Utilities 1.2 * JDK 1.5 * JSF 1.2+ Is that basically what we're looking at? Scott Matthias Wessendorf wrote: yes, some APIs have changed; my point was just, that for "trivial" things (like the validators/converters), the API is same, the generated artifacts are *dependent* to the particular Faces version. -M On Dec 5, 2007 5:34 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: I've also noticed that things with the externalContext also do not work properly because the ExternalContext api's have changed. I suspect anything that relies on the new functionality in externalContext or any of the other API's for that matter will have trouble porting back. Scott Matthias Wessendorf wrote: On Dec 5, 2007 10:40 AM, Volker Weber <[EMAIL PROTECTED]> wrote: Hi, why should a jsf1.1 extension library require java1.4 support? +1 tobago requires java1.5. Trinidad is also requiring Java5. like in Tobago land, we have a retro-weaver profile in the pom. it is totally fine running jsf 1.1 on a java 1.6 environment. I don't know the details of jsf 1.2 spec, but it seems to me that the api for javax.faces.convert.Converter is the same, so why must we differ between 1.1 and 1.2 in the commons-converter? Same for API is same. the "impl" is little different; ConverterTag is deprecated; good folks would use ConverterELTag (same for validator) commons-validator. Also many util classes should be able to work in jsf1.1 and jsf1.2 without changes. yes "common" helper method, will work if the are not using things like invokeOnComponet(), for instance -M Note: I'm speaking about the application-developer part of commons, not of the component/library-developer part. Regards, Volker 2007/12/5, Scott O'Bryan <[EMAIL PROTECTED]>: Right, I totally agree. The point is that, currently, Tomahawk, Tobago, and Trinidad 1.1 are NOT currently dependent on commons. And introducing support for 1.1 in the commons now would mean that commons would have to support Java 1.4 and JSF 1.1 pretty much forever. My proposal is basically that we leave the current 1.1 compatible renderkits as they are, maybe allowing some common filters and converters depending on what people think is needed. The other commons could then be used as projects tackle 1.2 and the commons could be used to ease and unify that development effort. Scott Paul Spencer wrote: Scott, My concern is when components, like Tomahawk, become dependent on JSF Commons, then they will inherit the dependencies of JSF Commons. If a component in JSF Commons is not intended to be used with JSF 1.1, or none of JSF 1.1 components, like Tomahawk, require the commons component, then I have no objection for a non-JSF 1.1. compliant dependency. Paul Spencer Scott O'Bryan wrote: Cool, I was hoping we had one. :) Paul, you mind if I ask you some questions about this? I can totally understand the want/need for the converters and validators to be ported to 1.1 (and thus need 1.4 support), but what about the utilities? Currently Trinidad, Tomahawk, and Tobago support JDK 1.1 and therefore their adoption of the common utilities would be slow if not non-existant. I know that the logic I'm trying to introduce, although it could be used in JSF 1.1 environments, really becomes most useful when dealing with JSF 1.2 and the portlet bridge. I also wouldn't think that things like unified multi-part form processing would be likely to make it into current 1.1 renderkits since it would require a lot of code to be rewritten and may not be backward compatible. Scott Paul Spencer wrote: +1 on JSF 1.2 only +1 on 1.1 support with JDK 1.5 required on both. +1 on 1.1 w/ 1.4 I have projects I support on HP-UX that are currently running JDK 1.4. Paul Spencer Andrew Robinson wrote: I would go for: +1 on JSF 1.2 only This is open source, so no one is required to use it and embracing 1.2 is only going to help the development community move forward. +0.5 on 1.1 support with JDK 1.5 required on both. Just because the specification supports 1.4 does mean libraries have to. JDK 1.5 has been out plenty long enough for companies to adopt it. If they cannot adopt it, they should be willing to forgo new libraries and functionality -1 on 1.1 w/ 1.4 This is too much work and will really hold nicer features back (I also would have no interest in developing and testing it personally). Just my $.02 -Andrew On Nov 29, 2007 10:06 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: On Nov 29, 2007
Re: MyFaces JSF Commons Project
yes, some APIs have changed; my point was just, that for "trivial" things (like the validators/converters), the API is same, the generated artifacts are *dependent* to the particular Faces version. -M On Dec 5, 2007 5:34 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > I've also noticed that things with the externalContext also do not work > properly because the ExternalContext api's have changed. I suspect > anything that relies on the new functionality in externalContext or any > of the other API's for that matter will have trouble porting back. > > Scott > > > Matthias Wessendorf wrote: > > On Dec 5, 2007 10:40 AM, Volker Weber <[EMAIL PROTECTED]> wrote: > > > >> Hi, > >> > >> why should a jsf1.1 extension library require java1.4 support? > >> > > > > +1 > > > >> tobago requires java1.5. > >> > > > > Trinidad is also requiring Java5. > > like in Tobago land, we have a retro-weaver profile in the pom. > > > >> it is totally fine running jsf 1.1 on a java 1.6 environment. > >> > >> I don't know the details of jsf 1.2 spec, but it seems to me that the > >> api for javax.faces.convert.Converter is the same, so why must we > >> differ between 1.1 and 1.2 in the commons-converter? Same for > >> > > > > API is same. > > > > the "impl" is little different; > > ConverterTag is deprecated; > > good folks would use ConverterELTag > > (same for validator) > > > >> commons-validator. Also many util classes should be able to work in > >> jsf1.1 and jsf1.2 without changes. > >> > > > > yes "common" helper method, will work > > if the are not using things like invokeOnComponet(), for instance > > > > -M > > > > > >> Note: I'm speaking about the application-developer part of commons, > >> not of the component/library-developer part. > >> > >> > >> Regards, > >> Volker > >> > >> > >> 2007/12/5, Scott O'Bryan <[EMAIL PROTECTED]>: > >> > >> > >>> Right, I totally agree. The point is that, currently, Tomahawk, Tobago, > >>> and Trinidad 1.1 are NOT currently dependent on commons. And > >>> introducing support for 1.1 in the commons now would mean that commons > >>> would have to support Java 1.4 and JSF 1.1 pretty much forever. > >>> > >>> My proposal is basically that we leave the current 1.1 compatible > >>> renderkits as they are, maybe allowing some common filters and > >>> converters depending on what people think is needed. The other commons > >>> could then be used as projects tackle 1.2 and the commons could be used > >>> to ease and unify that development effort. > >>> > >>> Scott > >>> > >>> Paul Spencer wrote: > >>> > Scott, > My concern is when components, like Tomahawk, become dependent on JSF > Commons, then they will inherit the dependencies of JSF Commons. If a > component in JSF Commons is not intended to be used with JSF 1.1, or > none of JSF 1.1 components, like Tomahawk, require the commons > component, then I have no objection for a non-JSF 1.1. compliant > dependency. > > Paul Spencer > > Scott O'Bryan wrote: > > > Cool, I was hoping we had one. :) Paul, you mind if I ask you some > > questions about this? > > > > I can totally understand the want/need for the converters and > > validators to be ported to 1.1 (and thus need 1.4 support), but what > > about the utilities? Currently Trinidad, Tomahawk, and Tobago > > support JDK 1.1 and therefore their adoption of the common utilities > > would be slow if not non-existant. I know that the logic I'm trying > > to introduce, although it could be used in JSF 1.1 environments, > > really becomes most useful when dealing with JSF 1.2 and the portlet > > bridge. I also wouldn't think that things like unified multi-part > > form processing would be likely to make it into current 1.1 > > renderkits since it would require a lot of code to be rewritten and > > may not be backward compatible. > > > > Scott > > > > Paul Spencer wrote: > > > >> +1 on JSF 1.2 only > >> +1 on 1.1 support with JDK 1.5 required on both. > >> +1 on 1.1 w/ 1.4 > >>I have projects I support on HP-UX that are currently running > >>JDK 1.4. > >> > >> Paul Spencer > >> > >> Andrew Robinson wrote: > >> > >>> I would go for: > >>> > >>> +1 on JSF 1.2 only > >>> > >>> This is open source, so no one is required to use it and embracing 1.2 > >>> is only going to help the development community move forward. > >>> > >>> +0.5 on 1.1 support with JDK 1.5 required on both. > >>> > >>> Just because the specification supports 1.4 does mean libraries have > >>> to. JDK 1.5 has been out plenty long enough for companies to adopt it. > >>> If they cannot adopt it, they should be willing to forgo new libraries > >>> and functionality > >>> > >>> -1 on 1.1 w/ 1.4 > >>> > >>> This is too much work and will really hold nicer features back (I also > >>
Re: MyFaces JSF Commons Project
I've also noticed that things with the externalContext also do not work properly because the ExternalContext api's have changed. I suspect anything that relies on the new functionality in externalContext or any of the other API's for that matter will have trouble porting back. Scott Matthias Wessendorf wrote: On Dec 5, 2007 10:40 AM, Volker Weber <[EMAIL PROTECTED]> wrote: Hi, why should a jsf1.1 extension library require java1.4 support? +1 tobago requires java1.5. Trinidad is also requiring Java5. like in Tobago land, we have a retro-weaver profile in the pom. it is totally fine running jsf 1.1 on a java 1.6 environment. I don't know the details of jsf 1.2 spec, but it seems to me that the api for javax.faces.convert.Converter is the same, so why must we differ between 1.1 and 1.2 in the commons-converter? Same for API is same. the "impl" is little different; ConverterTag is deprecated; good folks would use ConverterELTag (same for validator) commons-validator. Also many util classes should be able to work in jsf1.1 and jsf1.2 without changes. yes "common" helper method, will work if the are not using things like invokeOnComponet(), for instance -M Note: I'm speaking about the application-developer part of commons, not of the component/library-developer part. Regards, Volker 2007/12/5, Scott O'Bryan <[EMAIL PROTECTED]>: Right, I totally agree. The point is that, currently, Tomahawk, Tobago, and Trinidad 1.1 are NOT currently dependent on commons. And introducing support for 1.1 in the commons now would mean that commons would have to support Java 1.4 and JSF 1.1 pretty much forever. My proposal is basically that we leave the current 1.1 compatible renderkits as they are, maybe allowing some common filters and converters depending on what people think is needed. The other commons could then be used as projects tackle 1.2 and the commons could be used to ease and unify that development effort. Scott Paul Spencer wrote: Scott, My concern is when components, like Tomahawk, become dependent on JSF Commons, then they will inherit the dependencies of JSF Commons. If a component in JSF Commons is not intended to be used with JSF 1.1, or none of JSF 1.1 components, like Tomahawk, require the commons component, then I have no objection for a non-JSF 1.1. compliant dependency. Paul Spencer Scott O'Bryan wrote: Cool, I was hoping we had one. :) Paul, you mind if I ask you some questions about this? I can totally understand the want/need for the converters and validators to be ported to 1.1 (and thus need 1.4 support), but what about the utilities? Currently Trinidad, Tomahawk, and Tobago support JDK 1.1 and therefore their adoption of the common utilities would be slow if not non-existant. I know that the logic I'm trying to introduce, although it could be used in JSF 1.1 environments, really becomes most useful when dealing with JSF 1.2 and the portlet bridge. I also wouldn't think that things like unified multi-part form processing would be likely to make it into current 1.1 renderkits since it would require a lot of code to be rewritten and may not be backward compatible. Scott Paul Spencer wrote: +1 on JSF 1.2 only +1 on 1.1 support with JDK 1.5 required on both. +1 on 1.1 w/ 1.4 I have projects I support on HP-UX that are currently running JDK 1.4. Paul Spencer Andrew Robinson wrote: I would go for: +1 on JSF 1.2 only This is open source, so no one is required to use it and embracing 1.2 is only going to help the development community move forward. +0.5 on 1.1 support with JDK 1.5 required on both. Just because the specification supports 1.4 does mean libraries have to. JDK 1.5 has been out plenty long enough for companies to adopt it. If they cannot adopt it, they should be willing to forgo new libraries and functionality -1 on 1.1 w/ 1.4 This is too much work and will really hold nicer features back (I also would have no interest in developing and testing it personally). Just my $.02 -Andrew On Nov 29, 2007 10:06 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: On Nov 29, 2007 5:57 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: Hey everyone, I'm going to try to put together a proposal for some items it add to the jsf commons fairly soon for your purusal. First off, however, I'd like some technical information on this project as it may effect how the project is set up. 1. Which version of JSF will be the minimum for this project? One of my proposals involves needing an ExternalContextWrapper and the version of JSF does make a difference. I, personally, would like to see this based off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a 1.1 and a 1.2 branch. here we go; my understanding is, that 1.1 is a must 2. What is the minimum JDK we are going to use for this pro
Re: MyFaces JSF Commons Project
> 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 <[EMAIL PROTECTED]>: > > > > > Right, I totally agree. The point is that, currently, Tomahawk, Tobago, > > > and Trinidad 1.1 are NOT currently dependent on commons. And > > > introducing support for 1.1 in the commons now would mean that commons > > > would have to support Java 1.4 and JSF 1.1 pretty much forever. > > > > > > My proposal is basically that we leave the current 1.1 compatible > > > renderkits as they are, maybe allowing some common filters and > > > converters depending on what people think is needed. The other commons > > > could then be used as projects tackle 1.2 and the commons could be used > > > to ease and unify that development effort. > > > > > > Scott > > > > > > Paul Spencer wrote: > > > > Scott, > > > > My concern is when components, like Tomahawk, become dependent on JSF > > > > Commons, then they will inherit the dependencies of JSF Commons. If a > > > > component in JSF Commons is not intended to be used with JSF 1.1, or > > > > none of JSF 1.1 components, like Tomahawk, require the commons > > > > component, then I have no objection for a non-JSF 1.1. compliant > > > > dependency. > > > > > > > > Paul Spencer > > > > > > > > Scott O'Bryan wrote: > > > >> Cool, I was hoping we had one. :) Paul, you mind if I ask you some > > > >> questions about this? > > > >> > > > >> I can totally understand the want/need for the converters and > > > >> validators to be ported to 1.1 (and thus need 1.4 support), but what > > > >> about the utilities? Currently Trinidad, Tomahawk, and Tobago > > > >> support JDK 1.1 and therefore their adoption of the common utilities > > > >> would be slow if not non-existant. I know that the logic I'm trying > > > >> to introduce, although it could be used in JSF 1.1 environments, > > > >> really becomes most useful when dealing with JSF 1.2 and the portlet > > > >> bridge. I also wouldn't think that things like unified multi-part > > > >> form processing would be likely to make it into current 1.1 > > > >> renderkits since it would require a lot of code to be rewritten and > > > >> may not be backward compatible. > > > >> > > > >> Scott > > > >> > > > >> Paul Spencer wrote: > > > >>> +1 on JSF 1.2 only > > > >>> +1 on 1.1 support with JDK 1.5 required on both. > > > >>> +1 on 1.1 w/ 1.4 > > > >>>I have projects I support on HP-UX that are currently running > > > >>>JDK 1.4. > > > >>> > > > >>> Paul Spencer > > > >>> > > > >>> Andrew Robinson wrote: > > > I would go for: > > > > > > +1 on JSF 1.2 only > > > > > > This is open source, so no one is required to use it and embracing > > > 1.2 > > > is only going to help the development community move forward. > > > > > > +0.5 on 1.1 support with JDK 1.5 required on both. > > > > > > Just because the specification supports 1.4 does mean libraries have > > > to. JDK 1.5 has been out plenty long enough for companies to adopt > > > it. > > > If they cannot adopt it, they should be willing to forgo new > > > libraries > > > and functionality > > > > > > -1 on 1.1 w/ 1.4 > > > > > > This is too much work and will really hold nicer features back (I > > > also > > > would have no interest in developing and testing it personally). > > > > > > Just my $.02 > > > > > > -Andrew > > > > > > On Nov 29, 2007 10:06 AM, Matthias Wessendorf <[EMAIL PROTECTED]> > > > wrote: > > > > On Nov 29, 2007 5:57 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > > > >> Hey everyone, > > > >> > > > >> I'm going to try to put together a proposal for some items it add > > > >> to the > > > >> jsf commons fairly soon for your purusal. First off, however, > > > >> I'd like > > > >> some technical information on this project as it may effect how the > > > >> project is set up. > > > >> > > > >> 1. Which version of JSF will be the minimum for this project? > > > >> One of my > > > >> proposals involves needing an ExternalContextWrapper and the > > > >> version of > > > >> JSF does make a difference. I, personally, would like to see > > > >> this based > > > >> off 1.2 but if we need a 1.1 Faces Commons then I woul
Re: MyFaces JSF Commons Project
On Dec 5, 2007 10:40 AM, Volker Weber <[EMAIL PROTECTED]> wrote: > Hi, > > why should a jsf1.1 extension library require java1.4 support? +1 > > tobago requires java1.5. Trinidad is also requiring Java5. like in Tobago land, we have a retro-weaver profile in the pom. > > it is totally fine running jsf 1.1 on a java 1.6 environment. > > I don't know the details of jsf 1.2 spec, but it seems to me that the > api for javax.faces.convert.Converter is the same, so why must we > differ between 1.1 and 1.2 in the commons-converter? Same for API is same. the "impl" is little different; ConverterTag is deprecated; good folks would use ConverterELTag (same for validator) > commons-validator. Also many util classes should be able to work in > jsf1.1 and jsf1.2 without changes. yes "common" helper method, will work if the are not using things like invokeOnComponet(), for instance -M > > Note: I'm speaking about the application-developer part of commons, > not of the component/library-developer part. > > > Regards, > Volker > > > 2007/12/5, Scott O'Bryan <[EMAIL PROTECTED]>: > > > Right, I totally agree. The point is that, currently, Tomahawk, Tobago, > > and Trinidad 1.1 are NOT currently dependent on commons. And > > introducing support for 1.1 in the commons now would mean that commons > > would have to support Java 1.4 and JSF 1.1 pretty much forever. > > > > My proposal is basically that we leave the current 1.1 compatible > > renderkits as they are, maybe allowing some common filters and > > converters depending on what people think is needed. The other commons > > could then be used as projects tackle 1.2 and the commons could be used > > to ease and unify that development effort. > > > > Scott > > > > Paul Spencer wrote: > > > Scott, > > > My concern is when components, like Tomahawk, become dependent on JSF > > > Commons, then they will inherit the dependencies of JSF Commons. If a > > > component in JSF Commons is not intended to be used with JSF 1.1, or > > > none of JSF 1.1 components, like Tomahawk, require the commons > > > component, then I have no objection for a non-JSF 1.1. compliant > > > dependency. > > > > > > Paul Spencer > > > > > > Scott O'Bryan wrote: > > >> Cool, I was hoping we had one. :) Paul, you mind if I ask you some > > >> questions about this? > > >> > > >> I can totally understand the want/need for the converters and > > >> validators to be ported to 1.1 (and thus need 1.4 support), but what > > >> about the utilities? Currently Trinidad, Tomahawk, and Tobago > > >> support JDK 1.1 and therefore their adoption of the common utilities > > >> would be slow if not non-existant. I know that the logic I'm trying > > >> to introduce, although it could be used in JSF 1.1 environments, > > >> really becomes most useful when dealing with JSF 1.2 and the portlet > > >> bridge. I also wouldn't think that things like unified multi-part > > >> form processing would be likely to make it into current 1.1 > > >> renderkits since it would require a lot of code to be rewritten and > > >> may not be backward compatible. > > >> > > >> Scott > > >> > > >> Paul Spencer wrote: > > >>> +1 on JSF 1.2 only > > >>> +1 on 1.1 support with JDK 1.5 required on both. > > >>> +1 on 1.1 w/ 1.4 > > >>>I have projects I support on HP-UX that are currently running > > >>>JDK 1.4. > > >>> > > >>> Paul Spencer > > >>> > > >>> Andrew Robinson wrote: > > I would go for: > > > > +1 on JSF 1.2 only > > > > This is open source, so no one is required to use it and embracing 1.2 > > is only going to help the development community move forward. > > > > +0.5 on 1.1 support with JDK 1.5 required on both. > > > > Just because the specification supports 1.4 does mean libraries have > > to. JDK 1.5 has been out plenty long enough for companies to adopt it. > > If they cannot adopt it, they should be willing to forgo new libraries > > and functionality > > > > -1 on 1.1 w/ 1.4 > > > > This is too much work and will really hold nicer features back (I also > > would have no interest in developing and testing it personally). > > > > Just my $.02 > > > > -Andrew > > > > On Nov 29, 2007 10:06 AM, Matthias Wessendorf <[EMAIL PROTECTED]> > > wrote: > > > On Nov 29, 2007 5:57 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > > >> Hey everyone, > > >> > > >> I'm going to try to put together a proposal for some items it add > > >> to the > > >> jsf commons fairly soon for your purusal. First off, however, > > >> I'd like > > >> some technical information on this project as it may effect how the > > >> project is set up. > > >> > > >> 1. Which version of JSF will be the minimum for this project? > > >> One of my > > >> proposals involves needing an ExternalContextWrapper and the > > >> version of > > >> JSF does make a difference. I, pers
Re: MyFaces JSF Commons Project
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 <[EMAIL PROTECTED]>: > Right, I totally agree. The point is that, currently, Tomahawk, Tobago, > and Trinidad 1.1 are NOT currently dependent on commons. And > introducing support for 1.1 in the commons now would mean that commons > would have to support Java 1.4 and JSF 1.1 pretty much forever. > > My proposal is basically that we leave the current 1.1 compatible > renderkits as they are, maybe allowing some common filters and > converters depending on what people think is needed. The other commons > could then be used as projects tackle 1.2 and the commons could be used > to ease and unify that development effort. > > Scott > > Paul Spencer wrote: > > Scott, > > My concern is when components, like Tomahawk, become dependent on JSF > > Commons, then they will inherit the dependencies of JSF Commons. If a > > component in JSF Commons is not intended to be used with JSF 1.1, or > > none of JSF 1.1 components, like Tomahawk, require the commons > > component, then I have no objection for a non-JSF 1.1. compliant > > dependency. > > > > Paul Spencer > > > > Scott O'Bryan wrote: > >> Cool, I was hoping we had one. :) Paul, you mind if I ask you some > >> questions about this? > >> > >> I can totally understand the want/need for the converters and > >> validators to be ported to 1.1 (and thus need 1.4 support), but what > >> about the utilities? Currently Trinidad, Tomahawk, and Tobago > >> support JDK 1.1 and therefore their adoption of the common utilities > >> would be slow if not non-existant. I know that the logic I'm trying > >> to introduce, although it could be used in JSF 1.1 environments, > >> really becomes most useful when dealing with JSF 1.2 and the portlet > >> bridge. I also wouldn't think that things like unified multi-part > >> form processing would be likely to make it into current 1.1 > >> renderkits since it would require a lot of code to be rewritten and > >> may not be backward compatible. > >> > >> Scott > >> > >> Paul Spencer wrote: > >>> +1 on JSF 1.2 only > >>> +1 on 1.1 support with JDK 1.5 required on both. > >>> +1 on 1.1 w/ 1.4 > >>>I have projects I support on HP-UX that are currently running > >>>JDK 1.4. > >>> > >>> Paul Spencer > >>> > >>> Andrew Robinson wrote: > I would go for: > > +1 on JSF 1.2 only > > This is open source, so no one is required to use it and embracing 1.2 > is only going to help the development community move forward. > > +0.5 on 1.1 support with JDK 1.5 required on both. > > Just because the specification supports 1.4 does mean libraries have > to. JDK 1.5 has been out plenty long enough for companies to adopt it. > If they cannot adopt it, they should be willing to forgo new libraries > and functionality > > -1 on 1.1 w/ 1.4 > > This is too much work and will really hold nicer features back (I also > would have no interest in developing and testing it personally). > > Just my $.02 > > -Andrew > > On Nov 29, 2007 10:06 AM, Matthias Wessendorf <[EMAIL PROTECTED]> > wrote: > > On Nov 29, 2007 5:57 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > >> Hey everyone, > >> > >> I'm going to try to put together a proposal for some items it add > >> to the > >> jsf commons fairly soon for your purusal. First off, however, > >> I'd like > >> some technical information on this project as it may effect how the > >> project is set up. > >> > >> 1. Which version of JSF will be the minimum for this project? > >> One of my > >> proposals involves needing an ExternalContextWrapper and the > >> version of > >> JSF does make a difference. I, personally, would like to see > >> this based > >> off 1.2 but if we need a 1.1 Faces Commons then I would recommend > >> both a > >> 1.1 and a 1.2 branch. > > here we go; > > my understanding is, that 1.1 is a must > > > >> 2. What is the minimum JDK we are going to use for this project. My > >> preference would be J2SE 5 for the build. I could even live with > >> making > >> sure that code can be compiled with J2SE 5 in 1.4 compatibility > >> mode but > >> I think we need to be able to support generics at the very > >> least. Of > >> course if we're basing the commo
Re: MyFaces JSF Commons Project
Right, I totally agree. The point is that, currently, Tomahawk, Tobago, and Trinidad 1.1 are NOT currently dependent on commons. And introducing support for 1.1 in the commons now would mean that commons would have to support Java 1.4 and JSF 1.1 pretty much forever. My proposal is basically that we leave the current 1.1 compatible renderkits as they are, maybe allowing some common filters and converters depending on what people think is needed. The other commons could then be used as projects tackle 1.2 and the commons could be used to ease and unify that development effort. Scott Paul Spencer wrote: Scott, My concern is when components, like Tomahawk, become dependent on JSF Commons, then they will inherit the dependencies of JSF Commons. If a component in JSF Commons is not intended to be used with JSF 1.1, or none of JSF 1.1 components, like Tomahawk, require the commons component, then I have no objection for a non-JSF 1.1. compliant dependency. Paul Spencer Scott O'Bryan wrote: Cool, I was hoping we had one. :) Paul, you mind if I ask you some questions about this? I can totally understand the want/need for the converters and validators to be ported to 1.1 (and thus need 1.4 support), but what about the utilities? Currently Trinidad, Tomahawk, and Tobago support JDK 1.1 and therefore their adoption of the common utilities would be slow if not non-existant. I know that the logic I'm trying to introduce, although it could be used in JSF 1.1 environments, really becomes most useful when dealing with JSF 1.2 and the portlet bridge. I also wouldn't think that things like unified multi-part form processing would be likely to make it into current 1.1 renderkits since it would require a lot of code to be rewritten and may not be backward compatible. Scott Paul Spencer wrote: +1 on JSF 1.2 only +1 on 1.1 support with JDK 1.5 required on both. +1 on 1.1 w/ 1.4 I have projects I support on HP-UX that are currently running JDK 1.4. Paul Spencer Andrew Robinson wrote: I would go for: +1 on JSF 1.2 only This is open source, so no one is required to use it and embracing 1.2 is only going to help the development community move forward. +0.5 on 1.1 support with JDK 1.5 required on both. Just because the specification supports 1.4 does mean libraries have to. JDK 1.5 has been out plenty long enough for companies to adopt it. If they cannot adopt it, they should be willing to forgo new libraries and functionality -1 on 1.1 w/ 1.4 This is too much work and will really hold nicer features back (I also would have no interest in developing and testing it personally). Just my $.02 -Andrew On Nov 29, 2007 10:06 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: On Nov 29, 2007 5:57 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: Hey everyone, I'm going to try to put together a proposal for some items it add to the jsf commons fairly soon for your purusal. First off, however, I'd like some technical information on this project as it may effect how the project is set up. 1. Which version of JSF will be the minimum for this project? One of my proposals involves needing an ExternalContextWrapper and the version of JSF does make a difference. I, personally, would like to see this based off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a 1.1 and a 1.2 branch. here we go; my understanding is, that 1.1 is a must 2. What is the minimum JDK we are going to use for this project. My preference would be J2SE 5 for the build. I could even live with making sure that code can be compiled with J2SE 5 in 1.4 compatibility mode but I think we need to be able to support generics at the very least. Of course if we're basing the commons project off of JSF 1.2, J2SE5 is a no-brainer. :) JSF 1.1 => java1.4 JSF 1.2 => JDK5 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: MyFaces JSF Commons Project
Scott, My concern is when components, like Tomahawk, become dependent on JSF Commons, then they will inherit the dependencies of JSF Commons. If a component in JSF Commons is not intended to be used with JSF 1.1, or none of JSF 1.1 components, like Tomahawk, require the commons component, then I have no objection for a non-JSF 1.1. compliant dependency. Paul Spencer Scott O'Bryan wrote: Cool, I was hoping we had one. :) Paul, you mind if I ask you some questions about this? I can totally understand the want/need for the converters and validators to be ported to 1.1 (and thus need 1.4 support), but what about the utilities? Currently Trinidad, Tomahawk, and Tobago support JDK 1.1 and therefore their adoption of the common utilities would be slow if not non-existant. I know that the logic I'm trying to introduce, although it could be used in JSF 1.1 environments, really becomes most useful when dealing with JSF 1.2 and the portlet bridge. I also wouldn't think that things like unified multi-part form processing would be likely to make it into current 1.1 renderkits since it would require a lot of code to be rewritten and may not be backward compatible. Scott Paul Spencer wrote: +1 on JSF 1.2 only +1 on 1.1 support with JDK 1.5 required on both. +1 on 1.1 w/ 1.4 I have projects I support on HP-UX that are currently running JDK 1.4. Paul Spencer Andrew Robinson wrote: I would go for: +1 on JSF 1.2 only This is open source, so no one is required to use it and embracing 1.2 is only going to help the development community move forward. +0.5 on 1.1 support with JDK 1.5 required on both. Just because the specification supports 1.4 does mean libraries have to. JDK 1.5 has been out plenty long enough for companies to adopt it. If they cannot adopt it, they should be willing to forgo new libraries and functionality -1 on 1.1 w/ 1.4 This is too much work and will really hold nicer features back (I also would have no interest in developing and testing it personally). Just my $.02 -Andrew On Nov 29, 2007 10:06 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: On Nov 29, 2007 5:57 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: Hey everyone, I'm going to try to put together a proposal for some items it add to the jsf commons fairly soon for your purusal. First off, however, I'd like some technical information on this project as it may effect how the project is set up. 1. Which version of JSF will be the minimum for this project? One of my proposals involves needing an ExternalContextWrapper and the version of JSF does make a difference. I, personally, would like to see this based off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a 1.1 and a 1.2 branch. here we go; my understanding is, that 1.1 is a must 2. What is the minimum JDK we are going to use for this project. My preference would be J2SE 5 for the build. I could even live with making sure that code can be compiled with J2SE 5 in 1.4 compatibility mode but I think we need to be able to support generics at the very least. Of course if we're basing the commons project off of JSF 1.2, J2SE5 is a no-brainer. :) JSF 1.1 => java1.4 JSF 1.2 => JDK5 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: MyFaces JSF Commons Project
Cool, I was hoping we had one. :) Paul, you mind if I ask you some questions about this? I can totally understand the want/need for the converters and validators to be ported to 1.1 (and thus need 1.4 support), but what about the utilities? Currently Trinidad, Tomahawk, and Tobago support JDK 1.1 and therefore their adoption of the common utilities would be slow if not non-existant. I know that the logic I'm trying to introduce, although it could be used in JSF 1.1 environments, really becomes most useful when dealing with JSF 1.2 and the portlet bridge. I also wouldn't think that things like unified multi-part form processing would be likely to make it into current 1.1 renderkits since it would require a lot of code to be rewritten and may not be backward compatible. Scott Paul Spencer wrote: +1 on JSF 1.2 only +1 on 1.1 support with JDK 1.5 required on both. +1 on 1.1 w/ 1.4 I have projects I support on HP-UX that are currently running JDK 1.4. Paul Spencer Andrew Robinson wrote: I would go for: +1 on JSF 1.2 only This is open source, so no one is required to use it and embracing 1.2 is only going to help the development community move forward. +0.5 on 1.1 support with JDK 1.5 required on both. Just because the specification supports 1.4 does mean libraries have to. JDK 1.5 has been out plenty long enough for companies to adopt it. If they cannot adopt it, they should be willing to forgo new libraries and functionality -1 on 1.1 w/ 1.4 This is too much work and will really hold nicer features back (I also would have no interest in developing and testing it personally). Just my $.02 -Andrew On Nov 29, 2007 10:06 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: On Nov 29, 2007 5:57 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: Hey everyone, I'm going to try to put together a proposal for some items it add to the jsf commons fairly soon for your purusal. First off, however, I'd like some technical information on this project as it may effect how the project is set up. 1. Which version of JSF will be the minimum for this project? One of my proposals involves needing an ExternalContextWrapper and the version of JSF does make a difference. I, personally, would like to see this based off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a 1.1 and a 1.2 branch. here we go; my understanding is, that 1.1 is a must 2. What is the minimum JDK we are going to use for this project. My preference would be J2SE 5 for the build. I could even live with making sure that code can be compiled with J2SE 5 in 1.4 compatibility mode but I think we need to be able to support generics at the very least. Of course if we're basing the commons project off of JSF 1.2, J2SE5 is a no-brainer. :) JSF 1.1 => java1.4 JSF 1.2 => JDK5 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: MyFaces JSF Commons Project
+1 on JSF 1.2 only +1 on 1.1 support with JDK 1.5 required on both. +1 on 1.1 w/ 1.4 I have projects I support on HP-UX that are currently running JDK 1.4. Paul Spencer Andrew Robinson wrote: I would go for: +1 on JSF 1.2 only This is open source, so no one is required to use it and embracing 1.2 is only going to help the development community move forward. +0.5 on 1.1 support with JDK 1.5 required on both. Just because the specification supports 1.4 does mean libraries have to. JDK 1.5 has been out plenty long enough for companies to adopt it. If they cannot adopt it, they should be willing to forgo new libraries and functionality -1 on 1.1 w/ 1.4 This is too much work and will really hold nicer features back (I also would have no interest in developing and testing it personally). Just my $.02 -Andrew On Nov 29, 2007 10:06 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: On Nov 29, 2007 5:57 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: Hey everyone, I'm going to try to put together a proposal for some items it add to the jsf commons fairly soon for your purusal. First off, however, I'd like some technical information on this project as it may effect how the project is set up. 1. Which version of JSF will be the minimum for this project? One of my proposals involves needing an ExternalContextWrapper and the version of JSF does make a difference. I, personally, would like to see this based off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a 1.1 and a 1.2 branch. here we go; my understanding is, that 1.1 is a must 2. What is the minimum JDK we are going to use for this project. My preference would be J2SE 5 for the build. I could even live with making sure that code can be compiled with J2SE 5 in 1.4 compatibility mode but I think we need to be able to support generics at the very least. Of course if we're basing the commons project off of JSF 1.2, J2SE5 is a no-brainer. :) JSF 1.1 => java1.4 JSF 1.2 => JDK5 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: MyFaces JSF Commons Project
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> 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
+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
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
I would go for: +1 on JSF 1.2 only This is open source, so no one is required to use it and embracing 1.2 is only going to help the development community move forward. +0.5 on 1.1 support with JDK 1.5 required on both. Just because the specification supports 1.4 does mean libraries have to. JDK 1.5 has been out plenty long enough for companies to adopt it. If they cannot adopt it, they should be willing to forgo new libraries and functionality -1 on 1.1 w/ 1.4 This is too much work and will really hold nicer features back (I also would have no interest in developing and testing it personally). Just my $.02 -Andrew On Nov 29, 2007 10:06 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > On Nov 29, 2007 5:57 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > > Hey everyone, > > > > I'm going to try to put together a proposal for some items it add to the > > jsf commons fairly soon for your purusal. First off, however, I'd like > > some technical information on this project as it may effect how the > > project is set up. > > > > 1. Which version of JSF will be the minimum for this project? One of my > > proposals involves needing an ExternalContextWrapper and the version of > > JSF does make a difference. I, personally, would like to see this based > > off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a > > 1.1 and a 1.2 branch. > > here we go; > my understanding is, that 1.1 is a must > > > > > 2. What is the minimum JDK we are going to use for this project. My > > preference would be J2SE 5 for the build. I could even live with making > > sure that code can be compiled with J2SE 5 in 1.4 compatibility mode but > > I think we need to be able to support generics at the very least. Of > > course if we're basing the commons project off of JSF 1.2, J2SE5 is a > > no-brainer. :) > > JSF 1.1 => java1.4 > JSF 1.2 => JDK5 > > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org >
Re: MyFaces JSF Commons Project
Hazza. It would also allow, possibly, a Tobago 1.2 line to move forward a bit easier.. Scott Simon Kitching wrote: I certainly would be interested in contributing to a tomahawk-1.2 line, but not particularly interested in a tomahawk-1.1 line. It is necessary to test stuff that is added/modified, but compiling then testing against both versions of JSF will be painful. And writing components that work with the broken JSF1.1/JSP combination can be painful. And it would be great to be able to use java1.5 features rather than be stuck with ugly code just to be JSF1.1 compatible. When a new lib is being started, it does seem a good opportunity to make it 1.2-only and leave the old cruft behind.. Matthias Wessendorf <[EMAIL PROTECTED]> schrieb: 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: Hey everyone, I'm going to try to put together a proposal for some items it add to the jsf commons fairly soon for your purusal. First off, however, I'd like some technical information on this project as it may effect how the project is set up. 1. Which version of JSF will be the minimum for this project? One of my proposals involves needing an ExternalContextWrapper and the version of JSF does make a difference. I, personally, would like to see this based off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a 1.1 and a 1.2 branch. here we go; my understanding is, that 1.1 is a must 2. What is the minimum JDK we are going to use for this project. My preference would be J2SE 5 for the build. I could even live with making sure that code can be compiled with J2SE 5 in 1.4 compatibility mode but I think we need to be able to support generics at the very least. Of course if we're basing the commons project off of JSF 1.2, J2SE5 is a no-brainer. :) JSF 1.1 => java1.4 JSF 1.2 => JDK5 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: MyFaces JSF Commons Project
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
I don't think it is a good idea. -M On Nov 29, 2007 6:37 PM, Glauco P. Gomes <[EMAIL PROTECTED]> 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
On Nov 29, 2007 7:08 PM, Simon Kitching <[EMAIL PROTECTED]> wrote: > I certainly would be interested in contributing to a tomahawk-1.2 line, but > not particularly interested in a tomahawk-1.1 line. to be honest, I have no interest in tomahawk 1.1 In 1.2 a bit more... > > It is necessary to test stuff that is added/modified, but compiling then > testing against both versions of JSF will be painful. And writing components > that work with the broken JSF1.1/JSP combination can be painful. > > And it would be great to be able to use java1.5 features rather than be stuck > with ugly code just to be JSF1.1 compatible. yes, java5 would be great. > > When a new lib is being started, it does seem a good opportunity to make it > 1.2-only and leave the old cruft behind.. thanks, I really was hoping for a feedback like that. > > Matthias Wessendorf <[EMAIL PROTECTED]> schrieb: > > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > > > >> Hey everyone, > > > >> > > > >> I'm going to try to put together a proposal for some items it add to > > > >> the > > > >> jsf commons fairly soon for your purusal. First off, however, I'd like > > > >> some technical information on this project as it may effect how the > > > >> project is set up. > > > >> > > > >> 1. Which version of JSF will be the minimum for this project? One of > > > >> my > > > >> proposals involves needing an ExternalContextWrapper and the version of > > > >> JSF does make a difference. I, personally, would like to see this > > > >> based > > > >> off 1.2 but if we need a 1.1 Faces Commons then I would recommend both > > > >> a > > > >> 1.1 and a 1.2 branch. > > > >> > > > > > > > > here we go; > > > > my understanding is, that 1.1 is a must > > > > > > > > > > > >> 2. What is the minimum JDK we are going to use for this project. My > > > >> preference would be J2SE 5 for the build. I could even live with > > > >> making > > > >> sure that code can be compiled with J2SE 5 in 1.4 compatibility mode > > > >> but > > > >> I think we need to be able to support generics at the very least. Of > > > >> course if we're basing the commons project off of JSF 1.2, J2SE5 is a > > > >> no-brainer. :) > > > >> > > > > > > > > JSF 1.1 => java1.4 > > > > JSF 1.2 => JDK5 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Matthias Wessendorf > > > > further stuff: > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > mail: matzew-at-apache-dot-org > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: MyFaces JSF Commons Project
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
I certainly would be interested in contributing to a tomahawk-1.2 line, but not particularly interested in a tomahawk-1.1 line. It is necessary to test stuff that is added/modified, but compiling then testing against both versions of JSF will be painful. And writing components that work with the broken JSF1.1/JSP combination can be painful. And it would be great to be able to use java1.5 features rather than be stuck with ugly code just to be JSF1.1 compatible. When a new lib is being started, it does seem a good opportunity to make it 1.2-only and leave the old cruft behind.. Matthias Wessendorf <[EMAIL PROTECTED]> schrieb: > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > >> Hey everyone, > > >> > > >> I'm going to try to put together a proposal for some items it add to the > > >> jsf commons fairly soon for your purusal. First off, however, I'd like > > >> some technical information on this project as it may effect how the > > >> project is set up. > > >> > > >> 1. Which version of JSF will be the minimum for this project? One of my > > >> proposals involves needing an ExternalContextWrapper and the version of > > >> JSF does make a difference. I, personally, would like to see this based > > >> off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a > > >> 1.1 and a 1.2 branch. > > >> > > > > > > here we go; > > > my understanding is, that 1.1 is a must > > > > > > > > >> 2. What is the minimum JDK we are going to use for this project. My > > >> preference would be J2SE 5 for the build. I could even live with making > > >> sure that code can be compiled with J2SE 5 in 1.4 compatibility mode but > > >> I think we need to be able to support generics at the very least. Of > > >> course if we're basing the commons project off of JSF 1.2, J2SE5 is a > > >> no-brainer. :) > > >> > > > > > > JSF 1.1 => java1.4 > > > JSF 1.2 => JDK5 > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org
Re: MyFaces JSF Commons Project
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > >> Hey everyone, > >> > >> I'm going to try to put together a proposal for some items it add to the > >> jsf commons fairly soon for your purusal. First off, however, I'd like > >> some technical information on this project as it may effect how the > >> project is set up. > >> > >> 1. Which version of JSF will be the minimum for this project? One of my > >> proposals involves needing an ExternalContextWrapper and the version of > >> JSF does make a difference. I, personally, would like to see this based > >> off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a > >> 1.1 and a 1.2 branch. > >> > > > > here we go; > > my understanding is, that 1.1 is a must > > > > > >> 2. What is the minimum JDK we are going to use for this project. My > >> preference would be J2SE 5 for the build. I could even live with making > >> sure that code can be compiled with J2SE 5 in 1.4 compatibility mode but > >> I think we need to be able to support generics at the very least. Of > >> course if we're basing the commons project off of JSF 1.2, J2SE5 is a > >> no-brainer. :) > >> > > > > JSF 1.1 => java1.4 > > JSF 1.2 => JDK5 > > > > > > > > > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: MyFaces JSF Commons Project
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 <[EMAIL PROTECTED]> wrote: Hey everyone, I'm going to try to put together a proposal for some items it add to the jsf commons fairly soon for your purusal. First off, however, I'd like some technical information on this project as it may effect how the project is set up. 1. Which version of JSF will be the minimum for this project? One of my proposals involves needing an ExternalContextWrapper and the version of JSF does make a difference. I, personally, would like to see this based off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a 1.1 and a 1.2 branch. here we go; my understanding is, that 1.1 is a must 2. What is the minimum JDK we are going to use for this project. My preference would be J2SE 5 for the build. I could even live with making sure that code can be compiled with J2SE 5 in 1.4 compatibility mode but I think we need to be able to support generics at the very least. Of course if we're basing the commons project off of JSF 1.2, J2SE5 is a no-brainer. :) JSF 1.1 => java1.4 JSF 1.2 => JDK5
Re: MyFaces JSF Commons Project
On Nov 29, 2007 6:06 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > On Nov 29, 2007 5:57 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > > Hey everyone, > > > > I'm going to try to put together a proposal for some items it add to the > > jsf commons fairly soon for your purusal. First off, however, I'd like > > some technical information on this project as it may effect how the > > project is set up. > > > > 1. Which version of JSF will be the minimum for this project? One of my > > proposals involves needing an ExternalContextWrapper and the version of > > JSF does make a difference. I, personally, would like to see this based > > off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a > > 1.1 and a 1.2 branch. > > here we go; > my understanding is, that 1.1 is a must 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
On Nov 29, 2007 5:57 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > Hey everyone, > > I'm going to try to put together a proposal for some items it add to the > jsf commons fairly soon for your purusal. First off, however, I'd like > some technical information on this project as it may effect how the > project is set up. > > 1. Which version of JSF will be the minimum for this project? One of my > proposals involves needing an ExternalContextWrapper and the version of > JSF does make a difference. I, personally, would like to see this based > off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a > 1.1 and a 1.2 branch. here we go; my understanding is, that 1.1 is a must > > 2. What is the minimum JDK we are going to use for this project. My > preference would be J2SE 5 for the build. I could even live with making > sure that code can be compiled with J2SE 5 in 1.4 compatibility mode but > I think we need to be able to support generics at the very least. Of > course if we're basing the commons project off of JSF 1.2, J2SE5 is a > no-brainer. :) JSF 1.1 => java1.4 JSF 1.2 => JDK5 > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org