myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: [trinidad] cleanup
Date Wed, 05 Oct 2011 15:34:11 GMT
+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 <blake.sullivan@oracle.com>

> 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<darkarena@gmail.com>
>>>> To: dev@myfaces.apache.org
>>>> 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<darkarena@gmail.com>
>>>>>>  To: MyFaces Development<dev@myfaces.**apache.org<dev@myfaces.apache.org>
>>>>>> >
>>>>>>  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<gerhard.petracek@**gmail.com <gerhard.petracek@gmail.com>>
>>>> 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<darkarena@gmail.com>
>>>>>>>
>>>>>>>  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<gerhard.petracek@**gmail.com <gerhard.petracek@gmail.com>>
>>>>   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<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
>>>>>>>>>
>>>>>>>>>
>>
>

Mime
View raw message