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 <
[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
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
