+1 (see my comment about the >pre< jsf stuff)
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 Blake Sullivan <[email protected]
<mailto:[email protected]>>
I agree that we want to get rid of the impl stuff first, but even
more important would be to get rid of the last of the old
UIX-based renderers and the image generation code that we don't use.
-- Blake Sullivan
On 10/5/11 6:18 AM, Scott O'Bryan wrote:
Yeah, I'm not sure we know what third parties might depend on.
I can tell you, for instance, which deprications, for
instance, ADFFaces depends on. I can even remove those
dependencies. But the nature of Trinidad and client's like
ADFFaces is that the Trinidad implementations are exposed to
end-users.
Further, we've marked things as depricated if there is other
functionality in JSF2 which replaces it. There have been some
refactorings of API's which might provide "safer", "faster",
or "more correct" implementations of certain functionality.
That's not to say the old functions are wrong or that
existing applications which use them cannot get away with
using the old API's, it just means they SHOULD use the new
implementations if they want to be "clean" and fully correct.
I use the Java Date object as an example. It's an utterly
ridiculous class, admittedly, but it works and is there for
backward compatibility. There are much more "correct"
implementations which address more issues such as different
calendars and localization, but that does not make the date
object.. "wrong". Trinidad has, in the past, removed or
changed API's that just plain didn't work, but I'm not sure
that's what we're talking about here. And certainly, I'm cool
with removing the deprecated stuff from impl since nobody
should be depending on it anyway. My concern is for end users
of Trinidad and ADFFaces who may not have a voice or resources
to monitor changes of this sort in the Trinidad developer
community.
I don't know, what do other people think? This is one of
those things where I think the more voices the better.
Scott
On 10/05/2011 06:46 AM, Mark Struberg wrote:
My intention is not to break something, and I was ONLY
talking about the JSF-2 version of Trinidad.
If there is code which just makes no sense at all in
JSF-2, then we should in MY opinion kill this code.
If it doesn't make sense for Trinidad, then it is highly
likely that it also don't make sense for ADF anymore, right?
IF some parts are still needed by some known 3rd party
libs, then those parts can of course remain.
But at the end of the day maintaining Trinidad will become
more and more problematic if we don't get rid of long time
obsolete stuff.
Again: only my personal opinion and experience.
I assume that ADF also has a JSF-1 and a separate JSF-2
branch. All the JSF-1 stuff would of course remain the way
it is currently!
LieGrue,
strub
----- Original Message -----
From: Scott O'Bryan<[email protected]
<mailto:[email protected]>>
To: [email protected] <mailto:[email protected]>
Cc:
Sent: Wednesday, October 5, 2011 2:20 PM
Subject: Re: [trinidad] cleanup
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]
<mailto:[email protected]>>
To: MyFaces
Development<[email protected]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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