Re: [trinidad] cleanup

Wed, 05 Oct 2011 08:04:20 -0700

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]>
To: [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]>
  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

Reply via email to