myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott O'Bryan <darkar...@gmail.com>
Subject Re: [VOTE] layout for myfaces-commons project
Date Fri, 20 Jun 2008 17:45:51 GMT
Paul, why do the CF versions have to be different.  This is no different 
(IMO) then what I was talking about except that we could not FORCE 
people to backport everything.

I don't see why libraries for older JSF's HAVE to be functionally 
equivalent.  That is not to say that API's started in 1.2 shouldn't be 
upheld in the 2.0 version, but why should the 2.0 libraries only contain 
functionality relivent to 1.2..  I think the older branches could be 
move back as needed and the only real concern we need to have, 
therefore, is for forward compatibility except by exception.

As for JDK, if we support JSF 1.1, we should build off JDK 1.4.  If we 
support JSF 1.2, then there is no reason NOT to use JDK 1.5.  If we 
support JSF 2.0, then I think 1.6 is the minimum requirement.

Scott

Paul Spencer wrote:
> I am one who is using JSF 1.1 for some applications.  This is because 
> the applications are running software/hardware environments which do 
> not support JSF 1.2.  For applications in environment that will 
> support JSF 1.2, I use JSF 1.2.
>
> Future JSF version are inevitable, thus a solution must not be limited 
> to support for JSF 1.1. At some point a support for a JSF version must 
> be scaled back to bug fixes.  Below is a starting point for a long 
> term solution.
>
> We have several different "customer facing" project ( 
> MyFaces,Tomahawk, Trinidad, Tobago, Orchestra, and Portal Bridge) the 
> must address this JSF version issue.  Most restrict a JSF version to a 
> Major.Minor version of the project.  Tomahawk I know support both JSF 
> versions in the same project version.  If all "customer facing" 
> projects adopt a  "restrict a JSF version to a Major.Minor project 
> version" paradigm, then we can drop support for a JSF version in the 
> "common" projects with out holding back functionality in the "customer 
> facing" project because that functionality can not be implement in the 
> older JSF implementation.
>
> The illustration below is for one "customer facing" project the is 
> dependent on one "common" project.  When the project started, only JSF 
> 1.1 was supported.  When support for JSF 1.2 was added, the "common" 
> project was able to support both JSF versions.  As functionality was 
> added and bug fixed, the "common" project was able to support both JSF 
> versions.  Version 1.1/2.3 of the "customer facing" application are 
> functionally equivalent, but the the "common" project had to be split 
> off JSF 1.1 into a branch, keep JSF 1.2 and JSF 2.0 support together.
>
>
>  JSF 1.1            JSF 1.2          JSF 2.0
> CF Ver    CP Ver  CF Ver  CP Ver  CF Ver  CP Ver
> --------  ------  ------  ------  ------  ------
>  1.1.0     1.0.0
>  1.1.1     1.1.0   1.2.1   1.1.0
>  1.1.2     1.2.0   1.2.2   1.2.0
>  1.1.3     1.2.1   1.2.3   1.3.0   2.0.0   1.3.0
>  1.1.3.1   1.2.2
>                    1.2.4   1.3.1   2.0.1   1.4.0
>
> CF Ver = Version of "customer facing" project
> CP Ver = Version of "common" project
>
> Version 1.1.3 and 1.2.3 and 2.0.0 are functionally equivalent, the 
> older JSF uses a different version of the "common" library.
>
> Version 1.1.3.1 is a bug fix release this has no function equivalent 
> in the other JSF implementations.
>
>
> Paul Spencer
>
> Simon Lessard wrote:
>> Hi all,
>>
>> I have to agree with Andrew here. One year ago, JEE5 server were still
>> scarce or underused, thus supporting the maintained two branches 
>> argument,
>> but now is no longer the case and splitting efforts between two code 
>> bases
>> doesn't sound most efficient.
>>
>>
>> Regards
>>
>> ~ Simon
>>
>> On Fri, Jun 20, 2008 at 11:00 AM, Andrew Robinson <
>> andrew.rw.robinson@gmail.com> wrote:
>>
>>> JSR 252 (JSF 1.2) was finalized on 2006-05-11
>>> Java 1.5 released 2004-09-30
>>>
>>> I don't mind people maintaining JSF 1.1, but I do think that there is
>>> very good cause to have 1.1 moved to branches and the latest JSF
>>> specification as the trunk for each project. Over 2 years is plenty of
>>> time to adopt JSF 1.2. If you choose to stay on an old API, there is
>>> just cause to not have the latest and greatest code available. For
>>> those that wish to stay on and support 1.1 on a branch, that is
>>> perfectly fine, but I think it is time to stop burdening every
>>> developer with supporting legacy code without just cause. Other
>>> technologies support the latest, and I think 2 years is plenty of
>>> notice to users.
>>>
>>> My $2 (gas price inflation from cents to dollars)
>>> -Andrew
>>>
>>> On Fri, Jun 20, 2008 at 3:14 AM, Mario Ivankovits <mario@ops.co.at> 
>>> wrote:
>>>> simon schrieb:
>>>>> In other words, keeping one line of code makes sense (less
>>>>> maintenance) even if we lose some JSF1.2/JSF2.0-specific features or
>>>>> performance boosts.
>>>> While I second the rest of your mail, I wont do so with the sentence
>>> above.
>>>> We are developers, and, at least in your younger years ;-), you'd like
>>>> to keep up with technology
>>>> and use the newest things. And JSF 1.2 is anything else then new 
>>>> today,
>>>> not to speak about JSF 1.1.
>>>> In contrast, we spent alot of time to make our JSF 1.1 development
>>>> upward compatible.
>>>>
>>>> I don't think that we are responsible to provide a vital community
>>>> around a library
>>>> which itself depends on a stone old architecture.
>>>>
>>>> So, yes to one line of code, but I'd like to see the bundle
>>>> Tomahawk+JSF1.1 frozen.
>>>> Anything new should go to a JSF 1.2 native Tomahawk.
>>>> And JSF 2.0 release date + (lets say) half year the same should count
>>>> for Tomhawk JSF 1.2 then.
>>>>
>>>> Ciao,
>>>> Mario
>>>>
>>>>
>>
>


Mime
View raw message