The "backward compatibility" library might be an interesting idea. It
just won't always be possible if an existing class has deprecated
methods on it. I don't know how many Deprecated classes we have.
Scott
On 10/05/2011 07:07 AM, Gerhard Petracek wrote:
basically i agree with mark. at some point we have to get rid of the
old stuff (esp. >pre< jsf stuff).
at least we can move the deprecated parts to the mentioned backward
compatibility module (if needed).
in combination with shade there shouldn't be a problem at all and it
forces us to cleanup and re-visit those old parts.
@scott:
for sure it has to be a community decision.
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 Mark Struberg <[email protected] <mailto:[email protected]>>
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
>>>>>>
>>>
>
