We could, yes. But we would force people to migrate apps which, perhaps
is not a bad thing but traditionally we've taken a full vote before
changing/removing API's in Trinidad because, doing so, incurs additional
cost on the other frameworks which are using Trinidad as a foundation.
Any company which provides Trinidad as a foundation for other framework
code (like Oracle's ADFFaces) benefits from NOT breaking users of the
framework every release and, frankly, I see a lot of value in keeping
them around 'if possible'.
Like I say, I'm not opposed to it, but I suppose I take more of a Java
ZEN approach to deprecation of API's.
Scott
On 10/05/2011 05:41 AM, Mark Struberg wrote:
I'm not sure if I understand this correctly.
Trinidad-2 is for JSF-2 upwards exclusively, isn't?
If so, then we can easily get rid of all the old dust which just confuses
people.
Furthermore there seems to be a few compat problems with JSF-2 f:ajax which can
only be resolved by carefully cleaning those areas up.
Just leave behind the old stuff.
LieGrue,
strub
________________________________
From: Scott O'Bryan<[email protected]>
To: MyFaces Development<[email protected]>
Sent: Wednesday, October 5, 2011 1:06 PM
Subject: Re: [trinidad] cleanup
Well just because something is depth aged doesn't mean we can remove it. It
just means that an alternate means is suggested or something may not work
exactly as expected if used.
A Prime example is ExternalContextUtils. That guy has been around since JSF
1.1. It contains lots of functionality that wasn't present in later versions
of JSF, but now is. Use of the native objects should be encouraged, but there
is also something to be said about older code being able to migrate easier to a
later release.
Now I DO agree with removing the JSDoc and possibly the deprecations in the
impl, but I think it's important to keep any deprecations in the API for
backward compatibility.
Sent from my iPhone
On Oct 5, 2011, at 4:32 AM, Gerhard Petracek<[email protected]> wrote:
both - there are just two possibilities: those parts are really deprecated and
we remove them (and refactor the rest) or we can't remove them and the
information (annotation and/or javadoc) isn't correct.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/5 Scott O'Bryan<[email protected]>
Gerhard, by deprivation hints, I'm assuming you mean the javadoc deprecations
and not the annotations, right?
Sent from my iPhone
On Oct 5, 2011, at 3:09 AM, Gerhard Petracek<[email protected]> wrote:
hi @ all,
there are still over 400 deprecations (via @Deprecated) and nearly 400 via
javadoc (not all of them overlap).
a lot of them are in for a long time and some of them were deprecated even
before [1].
however, some parts are still used and can't be removed.
imo we should do a cleanup or remove the deprecation hints.
regards,
gerhard
[1] https://issues.apache.org/jira/browse/INFRA-1229
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
