Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 87929 invoked from network); 29 Nov 2007 18:33:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Nov 2007 18:33:21 -0000 Received: (qmail 85291 invoked by uid 500); 29 Nov 2007 18:33:08 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 85099 invoked by uid 500); 29 Nov 2007 18:33:07 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 85088 invoked by uid 99); 29 Nov 2007 18:33:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Nov 2007 10:33:07 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: 66.225.253.99 is neither permitted nor denied by domain of darkarena@gmail.com) Received: from [66.225.253.99] (HELO vienna.hostforweb.net) (66.225.253.99) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Nov 2007 18:32:45 +0000 Received: from [24.8.126.164] (port=50216 helo=[0.0.0.0]) by vienna.hostforweb.net with esmtpa (Exim 4.68) (envelope-from ) id 1IxoCX-00087C-Qx; Thu, 29 Nov 2007 12:33:30 -0600 Message-ID: <474F0605.9010302@gmail.com> Date: Thu, 29 Nov 2007 11:33:41 -0700 From: Scott O'Bryan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: MyFaces Development Subject: Re: MyFaces JSF Commons Project References: <14139818.1196359708806.JavaMail.root@viefep18> In-Reply-To: <14139818.1196359708806.JavaMail.root@viefep18> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vienna.hostforweb.net X-AntiAbuse: Original Domain - myfaces.apache.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gmail.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Checked: Checked by ClamAV on apache.org 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 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 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 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 >> > > >