You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Gerhard Petracek <ge...@gmail.com> on 2011/10/05 11:09:10 UTC
[trinidad] cleanup
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
Re: [trinidad] cleanup
Posted by Gerhard Petracek <ge...@gmail.com>.
some implementations of old apis are already delegating to the corresponding
jsf2 apis.
however, there are still even >pre< jsf >1.x< classes in the impl. module.
imo we should think about a special backward compatibility module as an
alternative.
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 <da...@gmail.com>
> 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 <ge...@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>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 < <da...@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 <<g...@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>
>> https://issues.apache.org/jira/browse/INFRA-1229
>>
>> <http://www.irian.at> <http://www.irian.at>http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>>
>
Re: [trinidad] cleanup
Posted by Scott O'Bryan <da...@gmail.com>.
Argh.. Now I'm getting iPhone-isms as well.. ;)
Sent from my iPhone
On Oct 5, 2011, at 5:06 AM, Scott O'Bryan <da...@gmail.com> wrote:
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 <ge...@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>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 < <da...@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 <<g...@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>
> https://issues.apache.org/jira/browse/INFRA-1229
>
> <http://www.irian.at> <http://www.irian.at>http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
Re: [trinidad] cleanup
Posted by Scott O'Bryan <da...@gmail.com>.
Yes.. I'm totally +1 for doing this in impl.. :). I think it would greatly
slim down our code. To a large extent, I think we've been a bit lazy in
getting rid of old api's..
Sent from my iPhone
On Oct 5, 2011, at 7:39 AM, Gerhard Petracek <ge...@gmail.com>
wrote:
most of the deprecated stuff is in the impl module. there are a lot of
deprecated classes.
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 <da...@gmail.com>
> **
> 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 <st...@yahoo.de>
>
>> 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 <da...@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<da...@gmail.com>
>> >>> To: MyFaces Development<de...@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<ge...@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<da...@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<ge...@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
>> >>>>>>
>> >>>>>> http://www.irian.at
>> >>>>>>
>> >>>>>> Your JSF powerhouse -
>> >>>>>> JSF Consulting, Development and
>> >>>>>> Courses in English and German
>> >>>>>>
>> >>>>>> Professional Support for Apache MyFaces
>> >>>>>>
>> >>>
>> >
>>
>
>
>
Re: [trinidad] cleanup
Posted by Gerhard Petracek <ge...@gmail.com>.
most of the deprecated stuff is in the impl module. there are a lot of
deprecated classes.
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 <da...@gmail.com>
> **
> 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 <st...@yahoo.de>
>
>> 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 <da...@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<da...@gmail.com>
>> >>> To: MyFaces Development<de...@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<ge...@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<da...@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<ge...@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
>> >>>>>>
>> >>>>>> http://www.irian.at
>> >>>>>>
>> >>>>>> Your JSF powerhouse -
>> >>>>>> JSF Consulting, Development and
>> >>>>>> Courses in English and German
>> >>>>>>
>> >>>>>> Professional Support for Apache MyFaces
>> >>>>>>
>> >>>
>> >
>>
>
>
>
Re: [trinidad] cleanup
Posted by Scott O'Bryan <da...@gmail.com>.
Yes. Cleaning up impl would be an excellent first step..
Sent from my iPhone
On Oct 5, 2011, at 7:50 AM, Gerhard Petracek <ge...@gmail.com>
wrote:
@max: basically +1
as mentioned before most of the stuff is in the impl. module. so we can even
start with the impl. module and announce the cleanup of the api in parallel
-> other libs have enough time to get rid of the old api calls,
implementations,... (or even better: they could join the effort)
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 Max Starets <ma...@oracle.com>
> **
> I think we that for 2.0.x versions of Trinidad, should definitely remove
> stuff that cannot be possibly used/invoked with JSF 2.0. I would not remove
> all deprecated APIs at once though. Perhaps we could could do it 'in waves '
> - start with APIs that were decprected for the longest time, announce that
> they are going to be removed in the next release and give our users
> considerable time to check their code.
>
> Max
>
>
> On 10/5/2011 9:22 AM, Scott O'Bryan wrote:
>
> 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 <st...@yahoo.de>
>
>> 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 <da...@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<da...@gmail.com>
>> >>> To: MyFaces Development<de...@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<ge...@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<da...@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<ge...@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
>> >>>>>>
>> >>>>>> http://www.irian.at
>> >>>>>>
>> >>>>>> Your JSF powerhouse -
>> >>>>>> JSF Consulting, Development and
>> >>>>>> Courses in English and German
>> >>>>>>
>> >>>>>> Professional Support for Apache MyFaces
>> >>>>>>
>> >>>
>> >
>>
>
>
>
Re: [trinidad] cleanup
Posted by Gerhard Petracek <ge...@gmail.com>.
@max: basically +1
as mentioned before most of the stuff is in the impl. module. so we can even
start with the impl. module and announce the cleanup of the api in parallel
-> other libs have enough time to get rid of the old api calls,
implementations,... (or even better: they could join the effort)
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 Max Starets <ma...@oracle.com>
> **
> I think we that for 2.0.x versions of Trinidad, should definitely remove
> stuff that cannot be possibly used/invoked with JSF 2.0. I would not remove
> all deprecated APIs at once though. Perhaps we could could do it 'in waves '
> - start with APIs that were decprected for the longest time, announce that
> they are going to be removed in the next release and give our users
> considerable time to check their code.
>
> Max
>
>
> On 10/5/2011 9:22 AM, Scott O'Bryan wrote:
>
> 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 <st...@yahoo.de>
>
>> 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 <da...@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<da...@gmail.com>
>> >>> To: MyFaces Development<de...@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<ge...@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<da...@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<ge...@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
>> >>>>>>
>> >>>>>> http://www.irian.at
>> >>>>>>
>> >>>>>> Your JSF powerhouse -
>> >>>>>> JSF Consulting, Development and
>> >>>>>> Courses in English and German
>> >>>>>>
>> >>>>>> Professional Support for Apache MyFaces
>> >>>>>>
>> >>>
>> >
>>
>
>
>
Re: [trinidad] cleanup
Posted by Max Starets <ma...@oracle.com>.
I think we that for 2.0.x versions of Trinidad, should definitely remove
stuff that cannot be possibly used/invoked with JSF 2.0. I would not
remove all deprecated APIs at once though. Perhaps we could could do it
'in waves ' - start with APIs that were decprected for the longest time,
announce that they are going to be removed in the next release and give
our users considerable time to check their code.
Max
On 10/5/2011 9:22 AM, Scott O'Bryan wrote:
> 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 <struberg@yahoo.de <ma...@yahoo.de>>
>>
>> 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
>> <ma...@gmail.com>>
>> > To: dev@myfaces.apache.org <ma...@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
>> <ma...@gmail.com>>
>> >>> To: MyFaces Development<dev@myfaces.apache.org
>> <ma...@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
>> <ma...@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
>> <ma...@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
>> <ma...@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
>> >>>>>>
>> >>>>>> http://www.irian.at
>> >>>>>>
>> >>>>>> Your JSF powerhouse -
>> >>>>>> JSF Consulting, Development and
>> >>>>>> Courses in English and German
>> >>>>>>
>> >>>>>> Professional Support for Apache MyFaces
>> >>>>>>
>> >>>
>> >
>>
>>
>
Re: [trinidad] cleanup
Posted by Scott O'Bryan <da...@gmail.com>.
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 <struberg@yahoo.de <ma...@yahoo.de>>
>
> 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
> <ma...@gmail.com>>
> > To: dev@myfaces.apache.org <ma...@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
> <ma...@gmail.com>>
> >>> To: MyFaces Development<dev@myfaces.apache.org
> <ma...@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
> <ma...@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
> <ma...@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
> <ma...@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
> >>>>>>
> >>>>>> http://www.irian.at
> >>>>>>
> >>>>>> Your JSF powerhouse -
> >>>>>> JSF Consulting, Development and
> >>>>>> Courses in English and German
> >>>>>>
> >>>>>> Professional Support for Apache MyFaces
> >>>>>>
> >>>
> >
>
>
Re: [trinidad] cleanup
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <st...@yahoo.de>
> 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 <da...@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<da...@gmail.com>
> >>> To: MyFaces Development<de...@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<ge...@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<da...@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<ge...@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
> >>>>>>
> >>>>>> http://www.irian.at
> >>>>>>
> >>>>>> Your JSF powerhouse -
> >>>>>> JSF Consulting, Development and
> >>>>>> Courses in English and German
> >>>>>>
> >>>>>> Professional Support for Apache MyFaces
> >>>>>>
> >>>
> >
>
Re: [trinidad] cleanup
Posted by Scott O'Bryan <da...@gmail.com>.
:D Okay, I missed the >pre< jsf comment.. ;) Totally good point.
That stuff has been around since incubation and migrating them over has
always been on the list of todo.. so yes again +1..
Scott
On 10/05/2011 09:34 AM, Gerhard Petracek wrote:
> +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
> <ma...@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
> <ma...@gmail.com>>
> To: dev@myfaces.apache.org <ma...@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
> <ma...@gmail.com>>
> To: MyFaces
> Development<dev@myfaces.apache.org
> <ma...@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
> <ma...@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
> <ma...@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
> <ma...@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
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache
> MyFaces
>
>
>
>
Re: [trinidad] cleanup
Posted by Gerhard Petracek <ge...@gmail.com>.
+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 <bl...@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<da...@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<da...@gmail.com>
>>>>>> To: MyFaces Development<de...@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 <ge...@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<da...@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 <ge...@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
>>>>>>>>>
>>>>>>>>>
>>
>
Re: [trinidad] cleanup
Posted by Blake Sullivan <bl...@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<da...@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<da...@gmail.com>
>>>>> To: MyFaces Development<de...@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<ge...@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<da...@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<ge...@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
>>>>>>>>
>>>>>>>> http://www.irian.at
>>>>>>>>
>>>>>>>> Your JSF powerhouse -
>>>>>>>> JSF Consulting, Development and
>>>>>>>> Courses in English and German
>>>>>>>>
>>>>>>>> Professional Support for Apache MyFaces
>>>>>>>>
>
Re: [trinidad] cleanup
Posted by Scott O'Bryan <da...@gmail.com>.
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<da...@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<da...@gmail.com>
>>>> To: MyFaces Development<de...@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<ge...@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<da...@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<ge...@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
>>>>>>>
>>>>>>> http://www.irian.at
>>>>>>>
>>>>>>> Your JSF powerhouse -
>>>>>>> JSF Consulting, Development and
>>>>>>> Courses in English and German
>>>>>>>
>>>>>>> Professional Support for Apache MyFaces
>>>>>>>
Re: [trinidad] cleanup
Posted by Mark Struberg <st...@yahoo.de>.
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 <da...@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<da...@gmail.com>
>>> To: MyFaces Development<de...@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<ge...@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<da...@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<ge...@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
>>>>>>
>>>>>> http://www.irian.at
>>>>>>
>>>>>> Your JSF powerhouse -
>>>>>> JSF Consulting, Development and
>>>>>> Courses in English and German
>>>>>>
>>>>>> Professional Support for Apache MyFaces
>>>>>>
>>>
>
Re: [trinidad] cleanup
Posted by Scott O'Bryan <da...@gmail.com>.
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<da...@gmail.com>
>> To: MyFaces Development<de...@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<ge...@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<da...@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<ge...@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
>>>>>
>>>>> http://www.irian.at
>>>>>
>>>>> Your JSF powerhouse -
>>>>> JSF Consulting, Development and
>>>>> Courses in English and German
>>>>>
>>>>> Professional Support for Apache MyFaces
>>>>>
>>
Re: [trinidad] cleanup
Posted by Mark Struberg <st...@yahoo.de>.
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 <da...@gmail.com>
>To: MyFaces Development <de...@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 <ge...@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 <da...@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 <ge...@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
>>>>
>>>>http://www.irian.at
>>>>
>>>>Your JSF powerhouse -
>>>>JSF Consulting, Development and
>>>>Courses in English and German
>>>>
>>>>Professional Support for Apache MyFaces
>>>>
>>
>
>
Re: [trinidad] cleanup
Posted by Scott O'Bryan <da...@gmail.com>.
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 <ge...@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 <da...@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 <ge...@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>http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
Re: [trinidad] cleanup
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <da...@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 <ge...@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>http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
Re: [trinidad] cleanup
Posted by Adam Furmanczuk <af...@knowtrek.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sorry,
I could not resists to comment on Iphone: deprivation ;)
Greets,
Adam
> 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
> <ge...@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
>
> http://www.irian.at
>
> Your JSF powerhouse - JSF Consulting, Development and Courses in
> English and German
>
> Professional Support for Apache MyFaces
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6MMW0ACgkQefEEI87R1DeqNACgguS4nbCFyahxQXJDP4vcpz9D
QcQAniaUrJly4OtaUoczeaOYvf40mD6N
=9b3h
-----END PGP SIGNATURE-----
Re: [trinidad] cleanup
Posted by Scott O'Bryan <da...@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 <ge...@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
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [trinidad] cleanup
Posted by Scott O'Bryan <da...@gmail.com>.
Yeah, so I got tied up with a demo. I'm thinking of just excluding
the component showcase from the distribution, allowing it to be
manually built, but not distributed as an artifact. WDYT?
Scott
Sent from my iPhone
On Oct 5, 2011, at 3:16 AM, Mark Struberg <st...@yahoo.de> wrote:
> +1, although I like to see a release with the current status upfront and then do a minor version jump?
>
> Scott, is there any update on the LGPL licensed dependency issue? Is this only in the pom or does this get actively used?
>
>
> txs and LieGrue,
> strub
>
>
>
>
>> ________________________________
>> From: Gerhard Petracek <ge...@gmail.com>
>> To: MyFaces Development <de...@myfaces.apache.org>
>> Cc: Scott O'Bryan <da...@gmail.com>
>> Sent: Wednesday, October 5, 2011 11:09 AM
>> Subject: [trinidad] cleanup
>>
>>
>> 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
>>
>>
>>
Re: [trinidad] cleanup
Posted by Mark Struberg <st...@yahoo.de>.
+1, although I like to see a release with the current status upfront and then do a minor version jump?
Scott, is there any update on the LGPL licensed dependency issue? Is this only in the pom or does this get actively used?
txs and LieGrue,
strub
>________________________________
>From: Gerhard Petracek <ge...@gmail.com>
>To: MyFaces Development <de...@myfaces.apache.org>
>Cc: Scott O'Bryan <da...@gmail.com>
>Sent: Wednesday, October 5, 2011 11:09 AM
>Subject: [trinidad] cleanup
>
>
>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
>
>
>