polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <hedh...@gmail.com>
Subject Re: BeanValidation 2.0 is out...
Date Fri, 11 Aug 2017 20:21:51 GMT
1. BV 2.0 is much more similar to we already have than BV 2.0 is similar to
BV 1.1. So I imagine we could support 2.0 quite easily, compared to the 1.x

2. Good point about getting it out of Core. Could be an interesting
exercise to break out Constraints/Validation as an extension somehow.
Unclear how that would look like though.

Let's discuss further once I have settled down after travel (now in Sweden)

On Aug 11, 2017 5:12 PM, "Kent SĂžlvsten" <kent.soelvsten@gmail.com> wrote:

I think it definitely sounds interesting.

Do you have anything particular in mind regarding the scope of support?

I guess the obvious part would be to allow users to declare usage of the
built-in constraints in the spec and to declare new custom constraints
using the API. That should be solvable by converting/adapting the
constraints and i suspect the built-in constraints would be easier to
reimplement, than to integrate an existing validation implementation.

Some thoughts ...

1) I am not too sure about the version. Maybe we should consider looking
into bean-validation 1.1 instead, since 2.0 will be part of the yet
JEE8 and thus still bleeding edge.

2) We usually want to constrain ourselves to as few external dependencies
in core as possible. Could dependencies on JEE interfaces be an extension
to that rule, or do we need to add the support as a pluggable part,
external to core?


On Thu, Aug 10, 2017 at 10:17 AM, Niclas Hedhman <niclas@hedhman.org> wrote:

> http://beanvalidation.org/2.0/spec/
> I find it amusing that this spec is closer to Polygene Constraints than it
> is to the 1.0 spec, yet our Constraints pre-dates the 2009 release of 1.0.
> Anyway, we should possibly consider supporting this "natively" in
> A brief glance seems to suggest that it is;
>   a. close to what we already have,
>   b. stronger definition on how to build violation messages,
>   c. seemingly easy to integrate.
> WDYT? And is there any volunteer... :-)  ?
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message