Jesse Alexander (KSFD 121) wrote:
> Well removing the commons code or the copied in commons-classes?
>
> the first (usage of the commons-code within the impl should be ok
> the second (remove the copied in commons-classes) could break peoples
> code...
> On the other hand it is always a risky business to use such a
> copied in class from a framework. The naming sort of makes it
> clear NOT to use those classes. But as with the microwave oven, which
> obviously was not made for drying babies... and still people do...
>
I guess worst case, if we decided to keep going with 1.2_0 with the
changes outlined
below, is the developers would have an out in that they could download
these jars
from java.net.
> reducing the amount of written formatting characters in the worst case
> could break testcases...
>
> other than that the ideas seem to make sense
>
> regards
> Alexander
>
> -----Original Message-----
> From: Ryan.Lubke_at_Sun.COM [mailto:Ryan.Lubke_at_Sun.COM]
> Sent: Friday, March 02, 2007 1:35 AM
> To: dev_at_javaserverfaces.dev.java.net
> Subject: Re: High level plans/ideas for _05
>
> Ryan Lubke wrote:
>
>> Hey folks,
>>
>> 1.2_04 will be out the door soon, so I have been giving kicking around
>>
>
>
>> some ideas
>> for _05.
>>
> Thinking more about this, I'm curious if some of these these changes,
> specifically the removal of commons code, qualify for a patch release?
>
> Perhaps it would be best to create a JSF_1_2_ROLLING branches and put
> the 1.2_x into maintenance mode and have the head represent 1.2.1 or
> 1.3?
>
> Thoughts?
>
>
>> - Remove dependencies of commons from the RI (at least the runtime
>> portion)
>> * refactor the config subsystem to use DOM/XPath
>> + standard API in SE 5, no need for additional dependencies
>> + Option to store the parsed DOMs in application scope
>> for those who would like access to the parsed data (perhaps
>> something in an extension element).
>> + reduce JAR size of jsf-impl (no commons classes, no
>> com.sun.faces.beans or rules)
>> * ManagedBeanFactoryImpl has a dependency on
>> BeanUtils - need to come up with equivalent methods
>> for ReflectionUtils
>>
>> - Rewrite the renderers and supporting methods to:
>> * reduce the number of write calls
>> * reduce the amount of formatting characters written?
>> * just generally more effecient
>>
>> - Bug fixing of course
>>
>> Anyone have ideas on some other things to try and tackle?
>> Comments on the above?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>