I'd say that there's no reason to deprecate a class clearly packaged as "trinidadinternal".
On 11/14/08, Jeanne Waldman <[EMAIL PROTECTED]> wrote: > Actually, I decided to be on the safe side to deprecate it, even if it is > just for one release. > Jeanne > > Jeanne Waldman wrote, On 11/14/2008 9:03 AM PT: > > > > You know this class best, Prakash, so I will remove it. > > Jeanne > > > > Prakash Udupa wrote, On 11/13/2008 3:46 PM PT: > > > > > I support moving it to public package, but instead of deprecating the > internal copy can we just remove it ?. > > > > > > * NullChangeManager is default ChangeManager when there is none > > > explicitly registered. > > > * The only use is in > > > > org.apache.myfaces.trinidadinternal.context.RequestContextImpl, > > > very very very unlikely there are any external usages. > > > > > > Thanks, > > > Prakash > > > > > > Simon Lessard wrote: > > > > > > > Sounds acceptable to me. > > > > > > > > On Thu, Nov 13, 2008 at 6:03 PM, Jeanne Waldman > <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > > > adding [Trinidad] to the subject for those of you filtering. > > > > > > > > Jeanne > > > > > > > > Jeanne Waldman wrote, On 11/13/2008 2:23 PM PT: > > > > > > > > Hi there, > > > > > > > > I'd like to move the import > > > > > org.apache.myfaces.trinidadinternal.change.NullChangeManager > > > > class from the internal package to the public package. I can > > > > leave the internal copy there and deprecate it, like I see > > > > we've done //FastMessageFormat/./ > > > > > > > > It is a generally useful class and our framework that > > > > includes Trinidad jars uses it. > > > > > > > > Let me know your thoughts. > > > > > > > > Thanks, > > > > Jeanne > > > > > > > > > > > > > > > > > > > >
