improving the experience of using BV with OSGi is still something I'd
like to see moving forward.
Based on a recent discussion about adding OSGi support to Hibernate
ORM , I'm starting to think the right way for dealing with this
would be to have a chapter on BV integration as part of the Enterprise
OSGi spec (which is maintained by the OSGi community). This spec
describes the integration of other Java EE technologies (JTA, JDBC,
JPA etc.) into OSGi, so adding BV there would be quite natural.
Of course BV implementations could still work towards this as long as
there is no standardized approach. AFAICS that has worked quite well
in the JPA area, too (there was some proprietary OSGi support in
EclipseLink which was deprecated/dropped when Enterprise OSGi arrived
with standardized JPA support).
We could facilitate such implementations by adding an OSGi manifest to
the BV spec JAR .
2012/8/23 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 2 juil. 2012, at 19:04, Matt Benson wrote:
> It's certainly a bigger discussion than just JavaFX; doing this right
> might require re-architecting the whole ConstraintValidator/Factory
> structure. The service locator concept puts me in mind of all kinds
> of things.
I was hoping to tackle some of that via the work to be more OSGi friendly
but motivated people lost their motivation en route ;)
I blame modularity for this :D
> Do we have a basic idea of how often we are open to
> creating a new version of the spec? i.e., for anything we table in
> the interest of finishing v1.1, how long must it then wait to be
> reconsidered for the next version?
Being realistic, it will be a while. If we take history as predictor, we
will release Bean Validation 1.1 early 2013 and 1.0 was release (very) late
2009. That's a 2.5 year turnaround.
beanvalidation-dev mailing list