Jesse Alexander (KSFD 121) wrote:
> Well removing the commons code or the copied in commons-classes?
>
Both. It's a hassle trying to maintain two different builds, one for
GlassFish which
includes said classes in another JAR, so we have to strip them out
before integrating,
and then the standard build from java.net.
The case of two different JARs with the same implementation version has
caused
confusion in the past.
> 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...
>
Well, I would really hope that an application developer wouldn't make
use of any
com.sun.commons class in favor of the real thing.
That said, the chance of a nuked baby is why I suggested having a 1.2.1
or 1.3 release
where we spell out in bold type that your app my break using this
release if you did
this really silly thing.
The code in 1_2_ROLLING would continue to be as it is today.
> reducing the amount of written formatting characters in the worst case
> could break testcases...
>
Are you using goldenfiles? :)
> 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
>
>