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]> > 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 > >>>>>> > >>> > > >
