: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 <[email protected] <mailto:[email protected]>>

    I agree that we want to get rid of the impl stuff first, but even
    more important would be to get rid of the last of the old
    UIX-based renderers and the image generation code that we don't use.

    -- Blake Sullivan


    On 10/5/11 6:18 AM, Scott O'Bryan wrote:

        Yeah, I'm not sure we know what third parties might depend on.
         I can tell you, for instance, which deprications, for
        instance,  ADFFaces depends on.  I can even remove those
        dependencies.  But the nature of Trinidad and client's like
        ADFFaces is that the Trinidad implementations are exposed to
        end-users.

        Further, we've marked things as depricated if there is other
        functionality in JSF2 which replaces it.  There have been some
        refactorings of API's which might provide "safer", "faster",
        or "more correct" implementations of certain functionality.
         That's not to say the old functions are wrong or that
        existing applications which use them cannot get away with
        using the old API's, it just means they SHOULD use the new
        implementations if they want to be "clean" and fully correct.

        I use the Java Date object as an example.  It's an utterly
        ridiculous class, admittedly, but it works and is there for
        backward compatibility.  There are much more "correct"
        implementations which address more issues such as different
        calendars and localization, but that does not make the date
        object.. "wrong".  Trinidad has, in the past, removed or
        changed API's that just plain didn't work, but I'm not sure
        that's what we're talking about here.  And certainly, I'm cool
        with removing the deprecated stuff from impl since nobody
        should be depending on it anyway.  My concern is for end users
        of Trinidad and ADFFaces who may not have a voice or resources
        to monitor changes of this sort in the Trinidad developer
        community.

        I don't know, what do other people think?  This is one of
        those things where I think the more voices the better.

        Scott

        On 10/05/2011 06:46 AM, Mark Struberg wrote:

            My intention is not to break something, and I was ONLY
            talking about the JSF-2 version of Trinidad.
            If there is code which just makes no sense at all in
            JSF-2, then we should in MY opinion kill this code.
            If it doesn't make sense for Trinidad, then it is highly
            likely that it also don't make sense for ADF anymore, right?

            IF some parts are still needed by some known 3rd party
            libs, then those parts can of course remain.


            But at the end of the day maintaining Trinidad will become
            more and more problematic if we don't get rid of long time
            obsolete stuff.

            Again: only my personal opinion and experience.

            I assume that ADF also has a JSF-1 and a separate JSF-2
            branch. All the JSF-1 stuff would of course remain the way
            it is currently!


            LieGrue,
            strub



            ----- Original Message -----

                From: Scott O'Bryan<[email protected]
                <mailto:[email protected]>>
                To: [email protected] <mailto:[email protected]>
                Cc:
                Sent: Wednesday, October 5, 2011 2:20 PM
                Subject: Re: [trinidad] cleanup

                We could, yes.  But we would force people to migrate
                apps which, perhaps
                is not a bad thing but traditionally we've taken a
                full vote before
                changing/removing API's in Trinidad because, doing so,
                incurs additional
                cost on the other frameworks which are using Trinidad
                as a foundation.

                Any company which provides Trinidad as a foundation
                for other framework
                code (like Oracle's ADFFaces) benefits from NOT
                breaking users of the
                framework every release and, frankly, I see a lot of
                value in keeping
                them around 'if possible'.

                Like I say, I'm not opposed to it, but I suppose I
                take more of a Java
                ZEN approach to deprecation of API's.

                Scott

                On 10/05/2011 05:41 AM, Mark Struberg wrote:

                     I'm not sure if I understand this correctly.

                     Trinidad-2 is for JSF-2 upwards exclusively, isn't?

                     If so, then we can easily get rid of all the old
                    dust which just confuses

                people.

                     Furthermore there seems to be a few compat
                    problems with JSF-2 f:ajax which

                can only be resolved by carefully cleaning those areas up.

                     Just leave behind the old stuff.


                     LieGrue,
                     strub

                         ________________________________
                         From: Scott O'Bryan<[email protected]
                        <mailto:[email protected]>>
                         To: MyFaces
                        Development<[email protected]
                        <mailto:[email protected]>>
                         Sent: Wednesday, October 5, 2011 1:06 PM
                         Subject: Re: [trinidad] cleanup


                         Well just because something is depth aged
                        doesn't mean we can

                remove it.  It just means that an alternate means is
                suggested or something may
                not work exactly as expected if used.


                         A Prime example is ExternalContextUtils.
                         That guy has been around

                since JSF 1.1.  It contains lots of functionality that
                wasn't present in
                later versions of JSF, but now is.  Use of the native
                objects should be
                encouraged, but there is also something to be said
                about older code being able
                to migrate easier to a later release.


                         Now I DO agree with removing the JSDoc and
                        possibly the deprecations in

                the impl, but I think it's important to keep any
                deprecations in the API for
                backward compatibility.

                         Sent from my iPhone

                         On Oct 5, 2011, at 4:32 AM, Gerhard

                Petracek<[email protected]
                <mailto:[email protected]>>   wrote:


                         both - there are just two possibilities:
                        those parts are really

                deprecated and we remove them (and refactor the rest)
                or we can't remove
                them and the information (annotation and/or javadoc)
                isn't correct.

                             regards,
                             gerhard
                            http://www.irian.at

                             Your JSF powerhouse -
                             JSF Consulting, Development and
                             Courses in English and German

                             Professional Support for Apache MyFaces




                             2011/10/5 Scott
                            O'Bryan<[email protected]
                            <mailto:[email protected]>>

                             Gerhard, by deprivation hints, I'm
                            assuming you mean the

                javadoc deprecations and not the annotations, right?

                                 Sent from my iPhone

                                 On Oct 5, 2011, at 3:09 AM, Gerhard

                Petracek<[email protected]
                <mailto:[email protected]>>   wrote:


                                 hi @ all,

                                     there are still over 400
                                    deprecations (via @Deprecated) and

                nearly 400 via javadoc (not all of them overlap).

                                     a lot of them are in for a long
                                    time and some of them were

                deprecated even before [1].


                                     however, some parts are still
                                    used and can't be

                removed.


                                     imo we should do a cleanup or
                                    remove the deprecation hints.


                                     regards,
                                     gerhard


                                     [1]
                                    
https://issues.apache.org/jira/browse/INFRA-1229

                                    http://www.irian.at

                                     Your JSF powerhouse -
                                     JSF Consulting, Development and
                                     Courses in English and German

                                     Professional Support for Apache
                                    MyFaces





Reply via email to