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