split to multiple artifacts

[minman]

split to multi module:

'validation-core'
'validation-web' (or if it makes sense 'validation-webmvc', 'validation-webflow')

you can keep artifact 'validation' containing all dependencies to not break current projects.

The point is, that spring validation is independent and could be used in other context than webmvn and webflow (without the need to have these dependencies). This would be great!

[cduplichien]

Very good point.
The functionality that's not validation-specific (e.g. @SuccessView, @ValidationFailureView) should probably also be split out.
This should definitely be done for 0.7.0

[minman]

Awesome!

[cduplichien]

Just to understand, you'd like to separate out the dependency on spring-web, spring-webmvc, and spring-webflow, right?

Looking at the parts where web logic is entangled, it boils down to context rules (e.g. rules that apply to forms) and specific contexts for SPEL. Incoherent thinking-out-loud:
For the prior I can change the existing "form" tags to be "context" tags, and add a hook point for registering some kind of ContextEvaluator thingy that'd be responsible for determining whether or not some specified context name/path matches the current context. MVC and Webflow form contexts would essentially be snap-ins.
For the latter, I can just add a hookpoint to add named context to the SPEL expression evaluator.

The end result is that this would drop the "core" spring dependencies to: spring-core, spring-beans, spring-context, and spring-expression.

[minman]

Exactly. The main issue is to decouple validation from presentation.

In a multi module project (each tier in his own module), you will be able to build cleaner dependencies like validation-core in service tier module and validation-webflow in web tier module. Further, if someone use another presentation framework (ex: jsf, wicket, tapestry, swing...), he still can use validation-core and implement his own presentation (or contribute a implementation for another framework so there could be more snap-ins for different presentation frameworks).

As you wrote: this goes to something like 'forms' to 'context' and ContextEvaluator...