Well, we try not to change publicly facing APIs - any chance of having
the old filter class still there as a proxy to the new one, so existing
apps continue to work? I'd prefer not to break existing apps with a dot
dot release, even if the fix is a single line of configuration.
Otherwise, no objection.
Jim
On 12/18/09 12:53 PM, Jason Lee wrote:
> In preparation for supporting (hopefully) Scala and other languages like
> we do Groovy, in my local tree, I have moved all of the Groovy classes
> to com.sun.faces.scripting.groovy. I've tested the resulting JARs under
> v2 and v3 (v3, btw, requires that groovy-all.jar be placed in modules/
> due to OSGi) and nothing appears to be broken (the full suite of tests
> is running now). I think the only user-visible change will be in the
> filter config due to the package change:
>
> <filter>
> <filter-name>GroovyFilter</filter-name>
> <filter-class>com.sun.faces.scripting.groovy.GroovySupportFilter</filter-class>
>
> </filter>
>
> Pending successful test suite completion, are there any objections to
> committing this change (the diff is HUGE because SVN shows each line of
> the deleted/added/moved file twice, once for the "delete" and once for
> the "add")?
>